Lets examine the use-case, currently all <ctrl>f does when the dialog is open, is it focuses the search pattern entry and selects its contents, it doesn't do any actions like next or prev. To get next or previous with the current pattern there are specific shortcuts (default bindings <ctrl>g and <ctrl><shift>g). So the only use-case for <ctrl>f now is to enter a new search pattern or to edit the current one.

The new behaviour will be to focus the search pattern entry and paste any current selection and select its contents, so it still provides the use-case of entering a new search pattern, just that the user will be typing over a different contents, so that use-case is still there. If there is no selection to paste the use-case to edit the current search pattern is still there.

So the only use-case to change is if there is a selection and the user wants to manually edit the current search pattern. But any movement key prior to <ctrl>f will remove the selection, and right doesn't even move the caret.

So AFAICT the new functionality is backward compatible with the exception of one sub-use-case which has a one keystroke workaround.

Therefore I agree with @codebrainz that it doesn't need a preference (and thats rare 😁), so we say 3.

Or you could wait and see if anyone else weighs in, might be a while though, given the time of year.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.