helix
helix copied to clipboard
Add "partial" history to the prompt
This makes it possible to look through the command history based on a prefix, which can make it much faster to find what we want when we know what it starts with!
To use it, simply type the prefix before looking through command history with Up/Down arrow keys. The non-prefixed history works just like before, although now the state resets when the prompt is modified.
Didn't look at the code yet, but the idea could be extended to search for a substring instead of requiring it to be a prefix. Fish shell does it this way for example, and it is quite useful.
Good idea @sudormrfbin! :smile:
I have made the change to using substring instead of prefix. I have also added some visual feedback (the substring in a match has a different colour), to give a bit more context about what is happening/why a specific history item is selected.
I am honestly not sure how I feel about this. I liked that history was purely historical. I do kind of see the usecase of searching trough history quickly but I generally prefer fuzzy matching to substring/prefix search (I use fzf for my my shell history for example).
Many uses of prompt (like the / regex prompt ) already set auto completions to look trough history. In that case this feels unnecessary (in fact I prefer the completions since they are fuzzy).
To be fair not all uses of prompt do this. Most notably the command prompt. I think I would rather see this solved with somekind of alternative completion/history key (it's too bad c-r is already taken since that is the shell muscle memory, I would love to have a mini picker like fzf shell integration does where you can both scroll and filter)
I liked that history was purely historical
This is still the case with this implementation for what I assume is the most common way to use the history: start going through history from an empty prompt.
it's too bad c-r is already taken
Yes, I agree this would make it more similar to a shell prompt to start actively searching through history by using fancier methods like FZF.
To me, filtering from a start prompt is a simple solution to not require adding new keybindings as well as making the feature easily discoverable: you start typing a command, then remember you typed it recently/can't quite remember how you wrote it and then start going through history. Once you know about the feature, you can start relying on it for quickly entering commands you don't want to setup an alias/binding for.
I also think this type of filtering from an initial prompt is not incompatible with later on adding another feature with a dedicated mode (with a keybinding) to use some interactive fuzzy finding filtering method. This is exactly how some shells work (I encountered it in ZSH, but apparently Fish does that as well): filter history based on what is entered before browsing history, but also have Ctrl-R for fancier searching methods.
This is still the case with this implementation for what I assume is the most common way to use the history: start going through history from an empty prompt.
I guess what I meant with that is that I sometimes type foo and I like that it doesn't affect when I type bar. I may remember that a different search works better and just like to quickly scroll trough history without any filter.
I also think this type of filtering from an initial prompt is not incompatible with later on adding another feature with a dedicated mode (with a keybinding) to use some interactive fuzzy finding filtering method. This is exactly how some shells work (I encountered it in ZSH, but apparently Fish does that as well): filter history based on what is entered before browsing history, but also have Ctrl-R for fancier searching methods.
I guess I would rather just have one way to filter the prompt. Having too many ways to do the same thing is confusing, takes up keybindings and makes the codebase hard to maintain over time.
@the-mikedavis what are your thoughts on this one? I am not super set my opinion but would lean towards keeping the history unfiltered.
I'm a big fan of fish's history behavior when I'm in the shell but I'm also interested in a more robust history finder as you say. I will think about this some more and maybe try some prototypes locally