microsoft
CTRL+F3 to search next occurrence of "current selection" and SHIFT..
Hello! o)
Let me quickly ask for some more "Find" related keyboard shortcuts to make life even more easy. I already like the standard CTRL-.. hotkeys so much in "edit", I think the world needs more of these, so.. o)
-
Find-Next with F3 Already done, thank you, very nice! o)
-
Find-Previous with SHIFT-F3 Still missing, would love to see this, even Notepad does it. o)
-
Find-Next-Occurrence CTRL+F3 This is another standard shortcut we need (I guess). CTRL+F3 is used to search for the next occurrence of what is currently selected in a lot of editors (Editplus, VSCode e.g.). Would be nice to see this implemented as well.
-
Find-Previous-Occurrence SHIFT+CTRL+F3 Same as above, just search current selection backward, also standard in a lot of editors.
Being able to "find next" or "find previous" occurrence of currently highlighted / selected text is immensely helpful when editing source code or configuration files.
Added 2025-06-21: Two more issues I noticed:
-
CTRL+F with already selected text, needs "double ENTER" needs you to press ENTER and ENTER again to start searching, expected only 1 ENTER.
-
CTRL+F panel does not allow to search reverse Using ENTER searches forward (expected) using SHIFT+ENTER does not search reverse, also searches forward (unexpected).
Thank you! o)
Very important. But what this feature requests highlights is the need for key/shortcut configurability, because I would like Ctrl-G to find Next.
Hey, I'm the contributor that added find-next with F3 and I'll start working on a pull request to fulfill some of these other requests. Keybind handling in msedit is a bit messy so it might take a while before it's ready in a release build, though.
Something I'd like you to clarify is exactly what behaviour you want from the CTRL + F3 keybind. Currently, selecting text then hitting CTRL + F will automatically fill the search query with your selection. Do you want the same behaviour just with a different keybind? Seems a bit redundant. If I'm misinterpreting your request, feel free to correct me.
Hello keircn,
thank you! o)
- CTRL+F3 is some kind of "quick find", just use the current find settings with the selected text without opening the find panel. It is basically the same, as using CTRL+F with selected text, which sets the search text in the find, then close the find with ESCAPE and use F3 to search the text which is currently in (the hidden) find panel.
- CTRL+SHIFT+F3 the same thing, just search in reverse. You can try VSCode to see how these two shortcuts work by default in classic Microsoft applications.
Two more issues I noticed (added in first post as well, to easily get the "full picture" o)
-
CTRL+F with already selected text, needs "double ENTER" needs you to press ENTER and ENTER again to start searching, expected only 1 ENTER.
-
CTRL+F panel does not allow to search reverse Using ENTER searches forward (expected) using SHIFT+ENTER does not search reverse, also searches forward (unexpected).
@pepa65 Is probably worth another issue(?), this one seems already kind of "stretched". o) But yes, changing the bindings is surely useful for the oldschool Linux users, which are used to whatever standard there was on Unix/Linux. I question though, if these users would use "edit" in the first place, but there are more reasons why you'd like to change the key bindings of course. It is an accessibility feature after all, useful for people who have medical, physical or technical problems using the default key bindings e.g..
I will look into closing this PR for you. About the customisable keybinds, that is a much broader endeavour that I don't think the maintainers are ready for yet. That doesnt mean it won't happen, I just doubt it will be merged into the repo in the near future.
The main reason that there is zero reverse search functionality at the moment is because there is not yet any implementation of it that I can see so its just as simple as patching that in
None of these keys work on my Arch linux system. It's pretty unbelievable that an editor would be released with a half-working find feature like this. I would suggest that this should not have been released at all until it achieved parity with the 30 year old MS DOS text editor.
Nah, release early and release often! o) If all features are not implemented in a v1.x, yet.. that's ok! o) The editor is already very useful and nice to use, even if some hotkeys are not available yet.