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
Make edit:command-history easier, and faster, to use with tools like fzf #1053
Comments
See also #568 which asked for a way to access a deduplicated command history more than two years ago. |
A recent question on IRC reminded me that I, like @zzamboni, had added some functions to my rc.elv several months ago to use the On my primary MacPro server
A pure Elvish solution takes 2849 ms (~3.7 and ~51.8 times longer than the perl and unmodified history solutions respectively):
Implementing a couple of the proposed enhancements should dramatically improve the experience of using |
I have a proof-of-concept change that adds a
It's certain to be even faster if we can replace the P.S., Note that outputting all commands takes 511.519 ms on my system. Which is 3.4 times slower than outputting just the non-duplicates:
Which, again, leads to the question of whether Elvish should even be recording each non-unique instance of a command since doing so isn't particularly useful and bloats the command history for little benefit. |
This implements `&dedup` and `&newest-first` options for `edit:command-history`. This makes it noticably cheaper to feed unique command history into external commands like `fzf`. Related elves#1053 Fixes elves#568
This implements `&dedup` and `&newest-first` options for `edit:command-history`. This makes it noticably cheaper to feed unique command history into external commands like `fzf`. Related elves#1053 Fixes elves#568
This implements `&dedup` and `&newest-first` options for `edit:command-history`. This makes it noticably cheaper to feed unique command history into external commands like `fzf`. Related elves#1053 Fixes elves#568
This implements `&dedup` and `&newest-first` options for `edit:command-history`. This makes it noticably cheaper to feed unique command history into external commands like `fzf`. Related elves#1053 Fixes elves#568
This implements `&dedup` and `&newest-first` options for `edit:command-history`. This makes it noticably cheaper to feed unique command history into external commands like `fzf`. Related elves#1053 Fixes elves#568
Also, it's important to note the solution using perl is wrong as it does not correctly preserve the order of the commands. Whereas the |
Implementing |
This change, combined with other changes to `edit:command-history`, makes feeding its output into `fzf` extremely fast. Which makes it a practical alternative to using the builtin Ctrl-R binding for searching command history. It's also just generally useful to have efficient ways to process "lines" that are null terminated rather than newline (or cr-nl on Windows). Resolves elves#1070 Related elves#1053
This is useful when piping the output into a program like `fzf` and more efficient than dealing with the map. This takes 180.32 ms on my system (best of five runs): ``` time { edit:command-history &dedup &newest-first | each [hist-entry]{ print $hist-entry[cmd]"\000" } >/dev/null } ``` This option reduces the time to 156.12 ms: ``` time { edit:command-history &dedup &newest-first &cmd-only | each [cmd]{ print $cmd"\000" } >/dev/null } ``` It's not a huge difference but is 13% faster, and should be considerably faster when combined with a hypothetical `to-lines &null` option I intend to implement. Related elves#1053
Using both PR #1307 and PR #1308 allows a very efficient Ctrl-R binding that uses the
|
This is useful when piping the output into a program like `fzf` and more efficient than dealing with the map. This takes 180.32 ms on my system (best of five runs): ``` time { edit:command-history &dedup &newest-first | each [hist-entry]{ print $hist-entry[cmd]"\000" } >/dev/null } ``` This option reduces the time to 156.12 ms: ``` time { edit:command-history &dedup &newest-first &cmd-only | each [cmd]{ print $cmd"\000" } >/dev/null } ``` It's not a huge difference but is 13% faster, and should be considerably faster when combined with a hypothetical `to-lines &null` option I intend to implement. Related elves#1053
This change, combined with other changes to `edit:command-history`, makes feeding its output into `fzf` extremely fast. Which makes it a practical alternative to using the builtin Ctrl-R binding for searching command history. It's also just generally useful to have efficient ways to process "lines" that are null terminated rather than newline (or cr-nl on Windows). Resolves elves#1070 Related elves#1053
This is useful when piping the output into a program like `fzf` and more efficient than dealing with the map. This takes 180.32 ms on my system (best of five runs): ``` time { edit:command-history &dedup &newest-first | each [hist-entry]{ print $hist-entry[cmd]"\000" } >/dev/null } ``` This option reduces the time to 156.12 ms: ``` time { edit:command-history &dedup &newest-first &cmd-only | each [cmd]{ print $cmd"\000" } >/dev/null } ``` It's not a huge difference but is 13% faster, and should be considerably faster when combined with a hypothetical `to-lines &null` option I intend to implement. Related #1053
This change makes feeding output to commands which handle NUL terminated "lines" (e.g., `fzf -read0` or `xargs -0`) extremely fast compared to using an explicit Elvish loop that does `print $val"\x00"`. Similarly for handling input from commands that produce NUL terminated "lines" (e.g., `find . -print0`) compared to an Elvish loop using `read-upto "\x00"`. Resolves elves#1070 Related elves#1053
This change makes feeding output to commands which handle NUL terminated "lines" (e.g., `fzf -read0` or `xargs -0`) extremely fast compared to using an explicit Elvish loop that does `print $val"\x00"`. Similarly for handling input from commands that produce NUL terminated "lines" (e.g., `find . -print0`) compared to an Elvish loop using `read-upto "\x00"`. Resolves #1070 Related #1053
For anyone who stumbles upon this issue in the future.... When writing the necessary code and responding to review feedback some of the details of this proposal were changed. This is the code I now have in my ~/.elvish/rc.elv init script:
|
Everything needed to make binding Ctrl-R to |
for 0.17, slight improvement.
|
Taken/modified from elves/elvish#1053 (comment).
Note. @aca Solution is great, but cursor jumps to the next line. Fix And for those who like to select history, simply press enter:
|
For anyone who comes across this, note that 11c11
< } except {
---
> } catch { |
See #1051 for what prompted me to open this issue.
At least one common use-case of the
edit:command-history
command would be easier and faster (i.e., more efficient) with some enhancements to that command:An option to output the commands in newest-to-oldest order (keeping the default oldest-to-newest).
An option to eliminate duplicate commands regardless of the output order. "Duplicate" here means comparing just the "cmd" member of the default map output.
An option to request just the "cmd" string be emitted rather than a map of all command attributes.
Maybe: An option to limit the output to the N newest commands; without regard to the order of the output. Note that the
take
command only works as a substitute for this option if the option to output the commands in newest-to-oldest order is used. On the other hand this option may not make much sense when coupled with oldest-to-newest order (the default). Regardless of whether or not it is treated as the first or last N commands. Thus the "maybe" prefix since it may be better to omit this option.Using the first three options makes it easy to do command selection using the popular
fzf
utility. It should also improve the time to produce afzf
menu by at least an order of magnitude.The duplicate command elimination option might warrant more discussion. Specifically, whether elvish should always do duplicate elimination when updating the command data store. In all my years using ksh and zsh as my day-to-day interactive shells I can't ever recall a situation where retaining each individual use of a command in the history was useful. As opposed to being an annoyance when I listed the N most recent commands I ran or was stepping backward through my command history; e.g., via [up-arrow]. Note that fish always does duplicate elimination. I can't recall ever hearing anyone complain about the deduplication.
The text was updated successfully, but these errors were encountered: