This can be used to avoid parse errors that can happen when the command
contains the closing character. Since the command does not finish at
a certain character, the key binding should be the last one in the
group. Suggested by @tiziano88. (#265)
e.g. fzf --bind "ctrl-m:execute=COMMAND..." --bind ctrl-j:accept
This change does have positive effect on startup time of fzf when many
number of options are provided.
time fzf --query=____ --filter=____ --delimiter=q --prompt=________ \
--nth=1,2,3,4 --with-nth=1,2,3,4 --toggle-sort=ctrl-r \
--expect=ctrl-x --tiebreak=index --color=light --bind=ctrl-t:accept \
--history=/tmp/xxx --history-max=1000 --help
0m0.013s -> 0m0.008s
- Add `--history` option (e.g. fzf --history ~/.fzf.history)
- Add `--history-max` option for limiting the size of the file (default 1000)
- Add `previous-history` and `next-history` actions for `--bind`
- CTRL-P and CTRL-N are automatically remapped to these actions when
`--history` is used
Closes#249, #251
- dark: the current default for 256-color terminal
- light: color scheme for 256-color terminal with light background
- 16: the default color scheme for 16-color terminal (`+2`)
- bw: no colors (`+c`)
I profiled fzf and it turned out that it was spending significant amount
of time repeatedly converting character arrays into Unicode codepoints.
This commit greatly improves search performance after the initial scan
by memoizing the converted results.
This commit also addresses the problem of unbounded memory usage of fzf.
fzf is a short-lived process that usually processes small input, so it
was implemented to cache the intermediate results very aggressively with
no notion of cache expiration/eviction. I still think a proper
implementation of caching scheme is definitely an overkill. Instead this
commit introduces limits to the maximum size (or minimum selectivity) of
the intermediate results that can be cached.
