mirror of
https://github.com/Llewellynvdm/fzf.git
synced 2024-11-19 19:45:12 +00:00
61 lines
1.6 KiB
Markdown
61 lines
1.6 KiB
Markdown
CHANGELOG
|
|
=========
|
|
|
|
0.9.4
|
|
-----
|
|
|
|
### New features
|
|
|
|
#### Added `--tac` option to reverse the order of the input.
|
|
|
|
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.
|
|
|
|
### *Backward incompatible changes*
|
|
|
|
#### Changed behavior on `--no-sort`
|
|
|
|
`--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
|
|
```
|
|
|
|
### Improvements
|
|
|
|
#### `--filter` will not block when sort is disabled
|
|
|
|
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.
|
|
|
|
0.9.3
|
|
-----
|
|
|
|
### New features
|
|
- Added `--sync` option for multi-staged filtering
|
|
|
|
### Improvements
|
|
- `--select-1` and `--exit-0` will start finder immediately when the condition
|
|
cannot be met
|
|
|