A suggestion for f/t

[yyy33]

In the case of using the default configuration, when using f to find characters,
For example, if you look for the character a, you will be in wait mode for 1 second and highlight all the a's after the first a found in this 1 second, during this 1 second, the cursor is at the bottom of the screen and not on top of the first a found, which will give a sense the delay when you use it. So I avoid this by letting exit_after_idle_msecs.unlabeled = 0, but at this point all the a after the first a found will not be highlighted, is it possible to set the two functions to wait for input to be highlighted separately?

I also think the highlighting is not simply highlighted, but displayed as a number is not more intuitive, so that after the cursor jumps to the first a, if you want to jump to the back of the other a, you only need to enter the number plus a semicolon can be

Translated with www.DeepL.com/Translator (free version)

[ggandor]

Set exit_after_idle_msecs.unlabeled = nil (not 0). 0 means "exit after 0 seconds (= immediately)", that is why you don't see the following matches highlighted.

I also think the highlighting is not simply highlighted, but displayed as a number is not more intuitive, so that after the cursor jumps to the first a, if you want to jump to the back of the other a, you only need to enter the number plus a semicolon can be

#116

[yyy33]

Reference in new issue

When exit_after_idle_msecs.unlabeled = nil is set, the plugin will never exit. What I mean is that after I type f<char>, I want the cursor to be displayed immediately above the first char, not above the cmdline at the bottom of the screen, which I can achieve by exit_after_idle_msecs.unlabeled = 0, but then the char after the first char will not are highlighted, I want them to be highlighted

[ggandor]

I want the cursor to be displayed immediately above the first char

A (virtual/fake) cursor should be displayed above the first char. (If you don't see it, then check #17.)

...not above the cmdline at the bottom of the screen

This is a technical limitation. We should wait for the next input with vim.fn.getchar, and that will move the cursor to the command line, we cannot avoid that. (See also the above referenced issue.)