New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pager search shouldn’t trigger when an entry is already selected #2249

Closed
Grimy opened this Issue Jul 28, 2015 · 15 comments

Comments

Projects
None yet
10 participants
@Grimy
Copy link

Grimy commented Jul 28, 2015

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.

@ridiculousfish ridiculousfish added this to the next-2.x milestone Jul 28, 2015

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jul 28, 2015

I often invoke the search feature by accident too. I think that changing the behavior on typing to accept the tab completion and append the typed text (instead of showing the search field) would do what I mean more often.

On the other hand the search mode is very powerful and I don't use it enough. There should be an easy way to invoke it.

As you found, return accepts the item but does not execute it; this behavior is borrowed from zsh (with the "menu select" feature). I think this is good: it's very powerful for drilling through deep directory hierarchies.

@dgutov

This comment has been minimized.

Copy link

dgutov commented Jul 31, 2015

I think this behavior is confusing because fish can't decide whether the selected completion is already inserted or not. If navigating the menu didn't immediately update the input, pressing return to accept the completion would be a lot less confusing. Even better if navigating the menu made the cursor invisible. I'm not necessarily suggesting that, but it would be more self-consistent.

Another current inconsistency: while typing a letter doesn't automatically select the current compeltion, pressing backspace does.

The search mode should probably only be entered manually, for instance, after pressing Ctrl-s.

@Grimy

This comment has been minimized.

Copy link

Grimy commented Aug 3, 2015

Having a shortcut to manually enable search mode is a good idea, but Ctrl-S is traditionally used for flow control.

@faho

This comment has been minimized.

Copy link
Member

faho commented Aug 4, 2015

Flow control was disabled in 7ce5f34 (fish 2.1.0), the release notes even mention:

Flow control is now disabled, freeing up ctrl-S and ctrl-Q for other uses.

Given that emacs uses Ctrl-s ("C-s" in emacs terms) for searching it sounds like the keychord to use for a search function in emacs mode.

@krader1961 krader1961 modified the milestones: next-2.x, 2.3.0 Mar 22, 2016

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Mar 22, 2016

Fish no longer disables flow-control (the change that disabled it was misguided). I mention it only to make sure everyone understands binding [ctrl-S] is no longer a viable binding.

It doesn't seem like this is going to be fixed in the next couple of weeks and I don't see any reason it should hold up the 2.3.0 release milestone. So I'm bumping this back to the next-2.x milestone.

@netmute

This comment has been minimized.

Copy link

netmute commented Nov 7, 2016

I'm hit by this issue multiple times a day. I landed here while searching for a way to completely disable search.
What's the status on this?

@Grimy

This comment has been minimized.

Copy link

Grimy commented Nov 7, 2016

@netmute, you have three options:

  • Live forever with the search “feature”
  • Clone this repo, checkout db0506c (last sane commit), compile, and use that
  • Switch to another shell (say, zsh)
@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Nov 8, 2016

@netmute thank you for your feedback, it's very valuable.

Is there a particular use case when you run into this? Perhaps when cding into a deep directory hierarchy? Or is it a general thing?

I agree the search interface is too easy to trigger accidentally and too hard to discover deliberately. Do have ideas/suggestions for a better way to expose it?

@netmute

This comment has been minimized.

Copy link

netmute commented Nov 10, 2016

I run into this pretty much every time I use the autocomplete pager.

I type something, hit tab to select the option I want, then continue typing the command. At this point I'm confused for a few seconds, realize I'm in some kind of search mode, spend a few seconds to figure out how to exit it, and then remember I have to hit Return to accept the autocomplete selection.

I have to double check every time that hitting Return is safe in this case, because I'm afraid it will accidentally execute the unfinished command, possibly deleting the wrong file or do other unintended things.

Personally, I wouldn't mind losing this feature. But not automatically activating search mode when I type would solve this issue for me as well. Every keypress, except the arrow keys and tab, should accept the selection.

Fish is my everyday shell, and this is one of very few minor annoyances. I'm grateful for all the love and hard work you put into this, and I'm sure this will be resolved soon :)

@zanchey zanchey modified the milestones: fish-future, fish 2.5.0 Jan 9, 2017

@lunixbochs

This comment has been minimized.

Copy link
Contributor

lunixbochs commented May 3, 2017

I'm still super annoyed by this. I trigger it all the time when diving into deeply nested directories, and I ended up switching back to bash on one machine.

  • It doesn't always trigger when I'm navigating, so I usually don't expect it when it happens.
  • I never use search, and am unlikely to start.
  • It triggers after I can already see the full path I want, if I start typing the next path component.

Personally, I wouldn't mind losing this feature. But not automatically activating search mode when I type would solve this issue for me as well. Every keypress, except the arrow keys and tab, should accept the selection.

I would be completely okay with this behavior, and a hotkey to actually perform search. I'm not okay with the current "sometimes implicitly enter search" behavior.

@mpcsh

This comment has been minimized.

Copy link

mpcsh commented Jan 15, 2018

Sorry for necrobumping but this is super annoying for me too. At least a flag to disable the pager would be very much appreciated

@ridiculousfish ridiculousfish modified the milestones: fish-future, fish-3.0 Jan 22, 2018

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jan 22, 2018

I'll try to improve this for 3.0

@faho

This comment has been minimized.

Copy link
Member

faho commented Jan 23, 2018

As a weird idea: Would it be alright if this just allowed space to skip the search?

I.e. you type a command, tab-complete, select an entry. You press space, which

  • Accepts the selected element

  • Closes the pager

  • Enters a space in the commandline

This would mean that once you start a search, pressing space would enter a space in the search string (since we also search descriptions, this is often quite useful), so you'd still have to press enter to accept or escape to abort, but it would fix the common case of "I just want to continue editing my command".

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Jan 30, 2018

The search field is I think "occasionally useful," but it's almost always surprising with the current design. I'd rather just go all the way.

The new world I'm about to commit:

  1. If the pager is shown and search field is hidden, typing normal characters or space will append to the command line and end paging.
  2. If the pager is shown, Control-S can be used to toggle the search field (on or off), via a new input function pager-toggle-search
  3. Shift-tab continues to show the pager with the search field immediately shown (this isn't changed but isn't widely known).
@floam

This comment has been minimized.

Copy link
Member

floam commented Dec 14, 2018

I actually had thought the search feature was just removed, I didn't know that I could use ^S to get the search field. So I think the feature is not discoverable enough. I wonder if we could give a hint in the pager status line. e.g.

rows 1 to 24 of 63                          (Ctrl-S to search)

AFAIK we don't have any code outside the Python web app that formats a binding to be understandable by a human, so that part would be a little annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment