Allow find-next without pressing enter

[Timmmm]

Currently the find behaviour is:

1. Type ctrl-F
2. Type your search string
3. Press enter to find the first match
4. Press Ctrl-N to find the next match.

Modern text editors (VSCode, etc.) use Ctrl-G for find-next so you can just do:

1. Type ctrl-F
2. Type your search string.
3. Press ctrl-G to find the first match, and subsequent matches.

This is quite a bit nicer. It would be good if micro worked the same way.

Edit: Apparently the default bindings are now fixed in stone so as a compromise the plan is to bind ctrl-F to find and find-next, i.e.

1. Press ctrl-F
2. Type your search string.
3. Press ctrl-F to find the first match and subsequent matches.

[ensilon]

You can bind CtrlG to FindNext in bindings.json, but I think the real benefit would be eliminating "step 3" in the current behavior.

My ideal solution would be CtrlF to start searching, then CtrlF again to find the next match (so 2 steps). I've got it working in my copy, but I had to butcher HandleSearchEvent() to make it work.

[supbish]

Totally agree with the above.

One of the best features of micro, in my opinion, is that it doesn't rely on modes... a mode for writing, another mode for reading / moving around, another mode for selecting stuff, etc, etc.

This is in line with most other modern editors, except for those that run in a terminal. This is what really sets micro apart. In that spirit, I think suggestions like this and #941 -- anything that eliminates mode-like behavior -- should be given serious consideration.

Ideally, "find next" should work at any time, including in the middle of a search as suggested above, or while not searching at all.

[ensilon]

This line could be skipped with a config option. When disabled, you can search up/down on the previous term without starting search mode, retyping your serarch term and hitting enter

https://github.com/zyedidia/micro/blob/master/cmd/micro/search.go#L49

[supbish]

I'm not even sure why it would need to be a config option... if someone doesn't want the behavior, they can just not hit the search next key, right?

I'll play with it later today and see about adding it to #1159.

@Timmmm, zyedidia has explicitly stated (elsewhere on issue tracker) that the default keys will remain the defaults. Can we change the title and wording of this ticket to just address the behavior change, and take out the part about the keybind?

[supbish]

Added this to the search-goodies branch of my fork.
Please try it out and let me know if you find any issues.
👍

[ensilon]

This is great. It's still intuitive, but can be much more efficient. Haven't seen any issues.

[ensilon]

An additional thought for search-goodies:

It's pretty easy to have this message (search.go:43) linger indefinitely, since you can stop searching without calling ExitSearch(). It's also an incorrect message for anyone who has re-bound next/previous search.
My only thought is removing it altogether, but that's not great for first-time users. Any ideas?

[supbish]

Yeah, not sure what to do with that. It might be nice if it appeared where that "show binding, open help" message appears. Looks like there's a major refactor going on now in another branch, gonna wait on that before moving on any PRs.

[AlexWayfer]

I was searching for a shortcut how to jump to next find result and found this stale issue. 🙃

I agree that hitting Enter is more intuitive for such fresh editor. Esc can be used to exit from find functionality.

Anyway, thank you for Ctrl N.

[alexdelorenzo]

Ran into this issue and agree with others about a different solution to skip through search results.

[brndd]

I just want to thank the issue creator for describing the current behaviour. This issue is the first result on Google for "micro editor find" and I end up coming back to it every now and then to remind myself how to actually get to the next result when pressing Enter does nothing.

[jonas-frey]

I'm confused by the claim in the original report that "Modern text editors (VSCode, etc.) use Ctrl-G". Don't they use F3 and Shift-F3? At least my VSCode does that and looking at settings.json that doesn't seem to be a custom configuration.

Wouldn't it make sense to add F3 and Shift-F3 as shortcuts for find next/previous?

In any case I agree that the present behaviour is unintuitive.

[Timmmm]

Traditionally Ctrl-G is the shortcut on Mac (and Linux maybe?) and F3 is the shortcut on Windows, but Ctrl-G is clearly better so lots of Windows programs have started using it instead of F3 (e.g. Chrome).

[jonas-frey]

Just as a data point: gnome programs on linux seem to use ctrl+g, kde programs use f3 (they use ctrl+g for "goto line").

[ensilon]

@zyedidia if this were to change, would you prefer it to be hidden behind a settings flag? IE searchmode: traditional / modal / ??

[jayarmstrong]

Just as a data point: gnome programs on linux seem to use ctrl+g, kde programs use f3 (they use ctrl+g for "goto line").

I believe F3 has also been the standard "find next" in all browsers and all Microsoft apps for like 20 years. At least, I've been using it that long. Libreoffice (on KDE) has F3 bound to an autotext feature but after launching the CTRL+F search function, F3 repeats the search.

In terms of improved function, thoughts:

1. In any browser, I can hit F3 on a tab I've never searched on (never launched the search function with CTRL + F) and it will conveniently, instantly repeat my last search query, with the text highlighted and ready to be replaced if I start typing a new query. So that's nice.
2. Firefox offers the "search as you type" function described above as a config option. I believe it was on by default for years. This can be an awesome time saver but probably gets in the way of some workflows.
3. A SHIFTed version of the shortcut to search for previous, as suggested above, would be excellent!