- Color customization with the extended
--color
option
- Fixed premature termination of Reader in the presence of a long line which is longer than 64KB
- Added
--bind
option for custom key bindings
- Fixed to update "inline-info" immediately after terminal resize
- Fixed ANSI code offset calculation
- Added
--inline-info
option for saving screen estate (#202)- Useful inside Neovim
- e.g.
let $FZF_DEFAULT_OPTS = $FZF_DEFAULT_OPTS.' --inline-info'
- Invalid mutation of input on case conversion (#209)
- Smart-case for each term in extended-search mode (#208)
- Fixed double-click result when scroll offset is positive
- Performance optimization
- Less aggressive memoization to limit memory usage
- Added color scheme for light background:
--color=light
- Added
--tiebreak
option (#191) - Added
--no-hscroll
option (#193) - Visual indication of
--toggle-sort
(#194)
- Fixed Unicode case handling (#186)
- Fixed to terminate on RuneError (#185)
- Added
--toggle-sort
option (#173)--toggle-sort=ctrl-r
is applied toCTRL-R
shell extension
- Fixed to print empty line if
--expect
is set and fzf is completed by--select-1
or--exit-0
(#172) - Fixed to allow comma character as an argument to
--expect
option
If you provide a comma-separated list of keys with --expect
option, fzf will
allow you to select the match and complete the finder when any of the keys is
pressed. Additionally, fzf will print the name of the key pressed as the first
line of the output so that your script can decide what to do next based on the
information.
fzf --expect=ctrl-v,ctrl-t,alt-s,f1,f2,~,@
The updated vim plugin uses this option to implement ctrlp-compatible key bindings.
- Fixed to ignore ANSI escape code
\e[K
(#162)
If you give --ansi
option to fzf, fzf will interpret ANSI color codes from
the input, display the item with the ANSI colors (true colors are not
supported), and strips the codes from the output. This option is off by
default as it entails some overhead.
By removing unnecessary copy of pointers, fzf will use significantly smaller
amount of memory when it's started. The difference is hugely noticeable when
the input is extremely large. (e.g. locate / | fzf
)
- Fixed panic on
--no-sort --filter ''
(#149)
One might argue that this option is unnecessary since we can already put tac
or tail -r
in the command pipeline to achieve the same result. However, the
advantage of --tac
is that it does not block until the input is complete.
--no-sort
option will no longer reverse the display order within finder. You
may want to use the new --tac
option with --no-sort
.
history | fzf +s --tac
When fzf works in filtering mode (--filter
) and sort is disabled
(--no-sort
), there's no need to block until input is complete. The new
version of fzf will print the matches on-the-fly when the following condition
is met:
--filter TERM --no-sort [--no-tac --no-sync]
or simply:
-f TERM +s
This change removes unnecessary delay in the use cases like the following:
fzf -f xxx +s | head -5
However, in this case, fzf processes the lines sequentially, so it cannot
utilize multiple cores, and fzf will run slightly slower than the previous
mode of execution where filtering is done in parallel after the entire input
is loaded. If the user is concerned about this performance problem, one can
add --sync
option to re-enable buffering.
- Added
--sync
option for multi-staged filtering
--select-1
and--exit-0
will start finder immediately when the condition cannot be met