Pager search shouldn’t trigger when an entry is already selected #2249
Description
Up to db0506c, fish had nice completion behavior. You could type the beginning of an argument, tab until the correct completion is selected, and then immediately start typing the next argument.
Nowadays, fish’s behavior is quite different. Once you have selected the desired completion, typing anything (even a space!) will enter the dreaded “search” mode, an unbelievably jarring mode that makes reverse-history-search look user-friendly in comparison. You then have to backspace, tab shift-tab to reselect the current completion and hit enter before you can start typing the next argument. That’s six wasted keypresses.
As soon as there are at least two completion possibilities, the search mode will jump at you to steal your time, focus and peace of mind. There seems to be only two ways to avoid it:
- After selecting the correct completion, hit Enter. For some unfathomable reason, in this context, hitting Enter doesn’t actually run the command or insert a carriage return or anything, like it always does in every shell I’ve ever used. It just clears the list of possible completions and lets you keep typing in relative sanity. Due to the considerable counter-intuitiveness, I’d rather avoid this option.
- Hit backspace, then space. This actually makes sense, but wastes two keypresses.
Now, I can understand how the search mode could possibly be useful to some people in some situations, so I’m not asking for it to be removed altogether. However, if you really want to search, it stands to reason that you would do so before selecting the desired completion. Therefore, it would be nice if the search mode wasn’t triggered when the user already selected a completion with tab/shift-tab.
Alternatively, I’d be happy with a configuration option that lets me completely disable the search mode. However, I believe such an option would go against fish’s philosophy.