Skip to content
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 · 30 comments
Closed

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

Grimy opened this issue Jul 28, 2015 · 30 comments

Comments

@Grimy
Copy link

@Grimy 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
Copy link
Member

@ridiculousfish 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
Copy link

@dgutov 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
Copy link
Author

@Grimy 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
Copy link
Member

@faho 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
Copy link
Contributor

@krader1961 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
Copy link

@netmute 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
Copy link
Author

@Grimy 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
Copy link
Member

@ridiculousfish 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
Copy link

@netmute 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
Copy link
Contributor

@lunixbochs 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
Copy link

@mpcsh 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
Copy link
Member

@ridiculousfish ridiculousfish commented Jan 22, 2018

I'll try to improve this for 3.0

@faho
Copy link
Member

@faho 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
Copy link
Member

@ridiculousfish 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
Copy link
Member

@floam 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.

@lesderid
Copy link

@lesderid lesderid commented Jan 19, 2019

I really don't like the new behaviour. Is there any way to get the old behaviour back?

@ridiculousfish
Copy link
Member

@ridiculousfish ridiculousfish commented Jan 20, 2019

What parts do you miss? There's no way to have typing in the pager implicitly start a search, like it did in fish 2.7. However you can trigger a search manually with ctrl-S, or you can start with the search field visible via shift-tab (which can also be made the default).

@lesderid
Copy link

@lesderid lesderid commented Jan 21, 2019

I miss the implicit search. :)

I guess I'll just patch it back in for myself if you don't think it would make sense to have it as an option.

@goranmoomin
Copy link

@goranmoomin goranmoomin commented Jan 25, 2019

@ridiculousfish I’m really against this change... I understand that many people get this annoying, but one of my (biggest) reasons that I suggest fish to others is that this search field greatly enhances flags discoverability and makes shell much powerful(unless we are a shell master that memorizes the man page)...
I believe the “right” behavior is to place the cursor at the last place, and successive spacebar press escapes completion while other keys trigger search...

@floam
Copy link
Member

@floam floam commented Jan 25, 2019

What if the search box was always visible before the first item in the pager, or at the bottom of the pager, and you use the arrow keys to "get to it" and focus/select the field?

@ridiculousfish
Copy link
Member

@ridiculousfish ridiculousfish commented Jan 25, 2019

I think having the search field always visible would be too busy.

@lesderid
Copy link

@lesderid lesderid commented Jan 26, 2019

The old behaviour (pre-5c2e673) is the most intuitive and user-friendly imo.

I think fish is going in the wrong direction by removing or altering features because they are unexpected for people switching to fish from a more classic shell (e.g. removing implicit search, adding &&/||); I always assumed fish was trying to be first and foremost a shell that's intuitive for anyone, most importantly for people who are not (very) familiar with command-line interfaces, not for people who simply want a shell that's a little bit different. If compatibility with other shells keeps being a major argument in deciding to alter fish behaviour, especially for interactive usage, isn't fish just going to become a classic shell with some optional cool features?

Back to this issue: GUI drop-downs (e.g. HTML <select>, on Chromium at least) often allow you to search an option by typing and then confirm it by pressing enter. To give an example, when I click a drop-down on a website, type the first characters of the option I want to select, and then press enter to confirm, I don't expect my browser to submit the form. I don't see why fish shouldn't behave similarly.

Sorry for the rant. 😳

@goranmoomin
Copy link

@goranmoomin goranmoomin commented Jan 26, 2019

@cloudrac3r
Copy link

@cloudrac3r cloudrac3r commented Jan 29, 2019

But hiding features(I had to search and read through the GitHub issues to find C-s for search(Which made me come to this issue)) for ease of transition is just plain wrong.

I don't have any amazing ideas for potential solutions, but I absolutely agree with this quote. I spent about 30 minutes searching GitHub issues trying to figure out why I couldn't search completions anymore, and only now found out that it had moved to Ctrl-S.

I'm fine with the current behaviour staying put, but please, make the key combination discoverable.

@netmute
Copy link

@netmute netmute commented Jan 29, 2019

I just want to chime in and say I love the latest changes 👍
Search was annoying the way it was implemented, as it constantly interrupted my workflow by requiring me to confirm a suggestion that I didn't want in the first place.

Oh, and I also absolutely love the addition of && and ||, makes fish so much smoother to use! Why would anyone not want that to be there? Unlike the search feature, you can just ignore && if you don't like it.

@goranmoomin
Copy link

@goranmoomin goranmoomin commented Feb 11, 2019

Tried to stick with C-s for a while, but it’s too painful and frustrating.
At least narrowing will help(This won’t bother current user’s workflow, right?)...

@pioneerskies
Copy link

@pioneerskies pioneerskies commented Mar 4, 2019

In the hope it's useful to give feedback here: initially, I was quite upset about the search "disappearing". Reading this issue gave my joy back thanks to the SHIFT-TAB shortcut.
But I'm still searching this info in the built-in help and actually I can't find it neither now that I'm aware of it...

@ridiculousfish
Copy link
Member

@ridiculousfish ridiculousfish commented Mar 12, 2019

The shift-tab shortcut is nominally documented here. Hopefully the Sphinx transition improves the searchability (by, well, introducing search)

@lwolfsonkin
Copy link

@lwolfsonkin lwolfsonkin commented Mar 13, 2019

It took me quite a while to figure out what was broken with my shell until I realized that my machine had silently upgraded to fish 3.0 which had introduced this change, which was intended as a feature.

You see, I'm very used to, for example, exploring the file system and cding as follows:

  1. Type cd
  2. <TAB>
  3. Presses down a couple times to force expansion if the folder I'm interested in isn't in the top couple
  4. Looks at options
  5. Types a couple characters of the folder I want (an arbitrary substring)
  6. Press Enter to select
  7. Return to 2 if I want to decend further, else stop

With this new change, instead when I try to type letters to search (step 3), an entirely random completion from the list gets selected and I have no clue what just happened.

Now, that workflow, for cd and all completions for that matter is no longer surfaced and really makes fish no longer "friendly" as I always felt it was (as well as being what the 'f' in fish stands for).

These navegable and searchable completions for the file system, flags, and subcommands has been in my opinion the selling feature for and what most impressed everyone I would show fish. Is there any way to have this still available as an option?

@cloudrac3r
Copy link

@cloudrac3r cloudrac3r commented Mar 13, 2019

@lwolfsonkin

As previously mentioned, you can bring up the search by pressing Ctrl-S with the pager visible. Another comment says you can press shift-tab to open the pager and make the search field visible directly, but I haven't tried that myself.

It's unlikely you'll see a configuration option since configurability is directly against fish's design policy.

The final option is to fork the repo and git revert the offending commit.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet