Add history reverse-isearch #602
Comments
|
I'm interested in suggestions for what the UI ought to be. Currently typing a character during history search just appends it, which seems not very useful, so we have an opportunity to do something better. |
|
I'm imagining it working exactly like zsh. And since there is no C-r right now in fish, it could even have the same key-binding, and be considered a new feature, instead of a change of existing functionality. |
|
|
|
Then how about a mix of fish's |
|
As a slight addendum to my UI proposal, instead of being exactly like zsh's UI, the match and the currently-typed-string can be switched, so that what you're typing stays on your current line, but the suggested match appears on the line below. |
|
Just wanted to chime in, I recently switched to fish and am really missing this. |
|
This feature would be a great addition to fish. |
|
How about make it behave mostly like the current behavior rather than like CTRL-R, but don't move the cursor and only "exit" search mode with CTRL-F and friends?
|
|
This would really be a great addition to fish. Recently started using it and only thing I miss at the moment (apart from setting inline environment variables) |
|
Just wanted to chip in and say that |
|
👍 C-r from bash. I looked at fish extensively yesterday. Lack of C-r, something I use not just with the shell, but MANY CLI (mysql, REPL's etc) is problematic. I'm glad I found https://github.com/sjl/z-fish which made things a lot better for me, but I would really like to just see a regular C-r implementation. They work the same across the board. For bash, I've also remapped C-f to do a forward search by adding |
|
Two problems we should avoid with bash and zsh style reverse history search are the undiscoverable key combination, and the "weird modal state" it puts you in. By that I mean that pressing ctrl-R drops the user into this confusing modal state that changes your prompt, changes what certain keys do, and doesn't provide an obvious way out. Here's one UI proposal:
This might produce a weird "jumping around" effect as you type. I'm not sure how common or bad that would be in practice. |
|
Even though the interface to i-reverse-search may be confusing it is orthodox and a very standard model. There are two ways you make successful design: by convention or by intuition. I'd say i-reverse-search present in both bash and zsh is convention based on having coming across it on a large number of CLI's. So if the choice is to go against convention, then it should be intuitive. I'm not sure what was described is intuitive enough to challenge convention. That's my take on it anyway. |
|
@ridiculousfish 👍 that sounds quite similar and idiomatic fish as well. |
|
@ridiculousfish 👍 its great. its similar to up/down without text to search in history. to avoid weird "jumping around" it can be an option just switch it to similar to i-reverse-serch UI: |
|
I'm using fish for a few days now and lack of ctrl-r (or equivalent) is the only show stopper for me. |
|
Just to add a "me-too", I stopped using fish because of lack of ctrl-r. Fantastic shell in almost every other respect. |
|
me too. this is what made me stop using it eventually. |
|
I think there's a number of things, but the sad, true part is probably just habit. :\ It's true that the key combo is not discoverable, but once you've discovered it, it's an awfully hard habit to break. Up arrow history search works fine, but as it is now once you hit the up arrow you can no longer modify your search query. Maybe what you've described above improves on that. If you'll let me be a dumb user and just say "habit" for now though, I think that's the truest answer. |
|
@ridiculousfish Nothing, really. I had no idea it exists. I searched for "history search" and such in the documentation and haven't found it. Maybe you should create a FAQ question - "what about ctrl-r?" :) |
|
I guess it was ignorance on my part. I think the only thing I don't like about it is that I have to use the arrow keys to page through the results. ctrl-r is more accessible. Can I remap ctrl-r to do that? |
|
You could write |
|
While it's a vast improvement over not having anything at all, I'll maintain my earlier position in that there's value in the convention that reverse-search has since it's uniform over so many programs. It's a common readline deal. Tools such as rlwrap do it this way too. |
|
In the meantime, I've gotten quite used to using up-arrow for the history search. Consider my comment from 7 months ago revoked. If we can get a nice solution that would allow modifying the search term, great, if not, c'est la vie. |
|
I think the many people saying that this is mostly a matter of habit are right; the fish reverse search is not intrisically less intuitive or less powerful that the bash equivalent. I do think that the choice of the up arrow as the only shortcut for accessing it may make it less accessible though. Not in the sense of discoverability, but with regard to speed of access. As mentioned above, it is a simple matter to bind it to something like |
|
Would love to see this in fish. It's the one and only feature I miss from other shells. I've taken @ridiculousfish's advice and remapped A drawback of remapping So big 👍 to see this in fish. I doubt I would end up being very successful, but @ridiculousfish I wonder if you could mention a starting point for someone like me who wouldn't mind giving the implementation a shot? |
|
@brentd: The starting point would be reader.cpp where most of keys are implemented. |
|
I thought fish's autosuggestion as one step further than other shell's interactive search. It was more discoverable and helpful. But we are so missing about C-r's search keyword editing feature. I'm think about stack like input status history.
If you need clean prompt, hit C-c twice. One more thing popped up in my head. If you know In previous example, we reached 'open Downloads/pdf' at some moment then dropped it. But if we need those previous moments again, we should edit again. If we saved previous abandoned state history, we can go back through our editing history. And some key could be binded for this history look around feature. According to previous example, we have three input history.
It could be quite helpful if we can 'backword-input-state-search'. You can think this as template for some frequently used command pattern. |
|
@krobelus you are making fish 3.2.0 look very tasty, keep up the good work. |
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). This also adds a system test using tmux' scripting capabilities. It's not ideal since we have to use sleep all over the place. Closes fish-shell#602
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). This also adds a system test using tmux' scripting capabilities. It's not ideal since we have to use sleep all over the place. Closes fish-shell#602
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). Closes fish-shell#602
|
This one did the job! |
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). Closes fish-shell#602
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). Closes fish-shell#602
|
Will the "new" incremental search feature also support wildcards, and will it be possible to switch search direction? Like with ZSH's Funny that I started trying Fish yesterday, and this is the feature I need, and it's been controversial since 2013. Also sad. |
|
Interesting to see how the Fish team is staying focus on its philosophy. That's the second topic where I meet it, after the one on bang. While I understand the point of discoverability, I don't see how using C-p as a alternative of C-r is any better. On the same level C-f to complete the current line with the suggestion is not more discoverable, you have to read the documentation. I had to check, and it seems that in the defaults, right arrow do the same completion. But it's so less convenient to my habits that I almost forgot it and had to check to see if it works that way. My point is, for many user the right arrow is more discoverable, and that's fine for them. The existence of C-f doesn't hurt this kind of user profile. On the other hand, those who prefer something less distant from base position on the keyboard will be better served with C-f and can forget about the right arrow binding. Now, sure there are surely way to work around with custom plugins and so on, but given that the C-r is so common in other CLI (not only shells), I don't find especially friendly to have to configure external tools to obtain this basic expectation. Those who don't know C-r wouldn't be hurt by it's existence as a default, and those who are already accustomed with such a feature in CLI would be better served with its default support. All that said, I must say I appreciate the team philosophy and hope this comment doesn't feel to harsh. Thanks for this wonderful tool. |
|
Okay, I've locked this issue as it's going in circles. Please direct your constructive comments regarding the implementation towards #6686 instead |
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). Closes fish-shell#602
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). Closes fish-shell#602
When pressing Control-R, fish will start a new incremental search, (if a search is already active it will be turned into an incremental one). Incremental search means that whenever you change the search term and it does not match the current history entry anymore, then fish will continue the search (in the same direction as the previous search command). Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. We use the current token as initial query. This makes it more consistent with up-arrow search, though I wonder if this is actually useful? 3. We only replace the current token, not the entire commandline. (Does this make sense?) 4. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. 5. In other shells, pressing Return immediately runs the command. 6. We add a space after an accepted completion. This is trivial to change but the space is harmless since it's trimmed before adding the command to history. The pager shows at most 10 history items at a time. This keeps everything snappy even with huge histories, though I'm sure there are other solutions for that. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. We use the current token as initial query. This makes it more consistent with up-arrow search, though I wonder if this is actually useful? 3. We only replace the current token, not the entire commandline. (Does this make sense?) 4. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. 5. In other shells, pressing Return immediately runs the command. 6. We add a space after an accepted completion. This is trivial to change but the space is harmless since it's trimmed before adding the command to history. The pager shows at most 10 history items at a time. This keeps everything snappy even with huge histories, though I'm sure there are other solutions for that. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. We use the current token as initial query. This makes it more consistent with up-arrow search, though I wonder if this is actually useful? 3. We only replace the current token, not the entire commandline. (Does this make sense?) 4. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. 5. In other shells, pressing Return immediately runs the command. 6. We add a space after an accepted completion. This is trivial to change but the space is harmless since it's trimmed before adding the command to history. The pager shows at most 10 history items at a time. This keeps everything snappy even with huge histories, though I'm sure there are other solutions for that. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. We use the current token as initial query. This makes it more consistent with up-arrow search, though I wonder if this is actually useful? 3. We only replace the current token, not the entire commandline. (Does this make sense?) 4. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. 5. In other shells, pressing Return immediately runs the command. 6. We add a space after an accepted completion. This is trivial to change but the space is harmless since it's trimmed before adding the command to history. The pager shows at most 10 history items at a time. This keeps everything snappy even with huge histories, though I'm sure there are other solutions for that. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. The pager shows at most 10 history items at a time. This keeps everything snappy even with huge histories, though I'm sure there are other solutions for that. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. The pager shows at most 10 history items at a time. This keeps everything snappy even with huge histories, though I'm sure there are other solutions for that. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. The pager shows only a small number of history items at a time. This is because the history pager does not support subsequence matching, so navigating it does not scale well. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. On the surface, this works just like in other shells. A few differences: 1. Our pager can show multiple results at a time. 2. Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but it might confuse users. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however for simplicity it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fzf does), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. The pager shows only a small number of history items at a time. This is because the history pager does not support subsequence matching, so navigating it does not scale well. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than fish-shell#6686. Pressing Control+R shows history in our pager and allows to search filter commands with the pager search field. On the surface, this works just like in other shells; though there are some differences. - Our pager shows multiple results at a time. - Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but the hidden state might confuse users and it doesn't play well with up-or-search, so this is left out. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however due to the history pager design it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fuzzy finders do), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. The pager shows only a small number of history items at a time. This is because, as explained above, the history pager does not support subsequence matching, so navigating it does not scale well. Closes fish-shell#602
This reimplements ridiculousfish/control_r which is a more future-proof approach than #6686. Pressing Control+R shows history in our pager and allows to search filter commands with the pager search field. On the surface, this works just like in other shells; though there are some differences. - Our pager shows multiple results at a time. - Other shells allow to use up arrow/down arrow to select adjacent entries in history. Shouldn't be hard to implement but the hidden state might confuse users and it doesn't play well with up-or-search, so this is left out. Users might expect the history pager to use subsequence matching (fuzzy matching) like the completion pager, however due to the history pager design it uses substring matching. We could change this in future, however that means we would also want to change the ordering from "reverse-chronological" to "longest common subsequence" (e.g. what fuzzy finders do), because otherwise a query "fis" might give this ordering: fsck /dev/disk/by-partlabel/Linux\x20filesystem fish which is probably not what the user wants. The pager shows only a small number of history items at a time. This is because, as explained above, the history pager does not support subsequence matching, so navigating it does not scale well. Closes #602
and others
While I love most things about fish, I had to switch back to zsh because C-r in zsh (or even bash) is more efficient than fish's reverse-search functionality.
In zsh you can type-to-complete substring-matches in history. With fish, you can cycle to see what in your history matches your substring, but you can't easily modify your substring while searching to narrow down the match.
For example if I type "git re" and go up a few times, I may find that I'm only finding a bunch of "git reset"-ish commands, but I know I want a command like "git rebase", so in zsh or bash I would just type a "b" to narrow that down. But in fish I have to restart my search with C-c and try again with "git reb". Otherwise I'm just adding a "b" to the end of whatever the last match was, which isn't what I meant to do.
This may appear trivial, but I rely heavily on C-r for all my commands (which is one reason I like fish, because it predicted that correctly about me), but I rely on it for substring-matches, not just prefix-string matches like fish does with auto-suggestions.
I'm proposing that in addition to the existing reverse-search feature, a zsh-like C-r be implemented as well.
The text was updated successfully, but these errors were encountered: