What's changed in fzf 0.9.4
2015. 03. 05.

I recently released a new version of fzf, 0.9.4. There's usually not much to talk about these minor updates, but this time, there's a backward incompatible change, and I want to explain the implications of it and the reasoning behind the decision.

In short: --no-sort option will not reverse the order of the items displayed inside the finder.

Why?

The reason I came up with --no-sort (or +s) option in the first place was to use fzf with command history. In that context, more recent commands should have higher priority than the older ones, so fzf should not sort the result using its own ranking algorithm. (This also holds true when integrating fzf with tools that have their own sort criteria. A notable example is z.) And since fzf by default prefers the items that came earlier, I needed a way to reverse the order of how they appear inside the finder, but tac (or tail -r on OS X) would block until the input stream is complete and lead to suboptimal user experiences. Without enough consideration, I decided to make fzf do just that when --no-sort is given, so I could just write:

history | fzf +s

However, it has become obvious that it was not a good idea. 1. Not sorting the result, and 2. reversing the display order are two orthogonal concerns that should have been handled independently. Doing both using one option flag made fzf less flexible in different scenarios and made users confused.

So?

Although I really hate breaking backward compatibility, I decided to make it right before it's too late (like, when fzf hits 1.0?). So from 0.9.4, --no-sort will not reverse the display order, and simply do what it's supposed to do: not sorting the result.

The limitation of additional tac in the command pipeline as described above still applies, so I added --tac option to 0.9.4. You can use it as a non-blocking alternative to tac.

So if you've been using scripts like follows:

history | fzf +s

you probably should add --tac option to fzf.

history | fzf +s --tac

As you might have guessed, this particular piece of code constitutes the implementation of the supplied CTRL-R key binding. The code was updated accordingly, and you'll be fine once you rerun the install script which updates ~/.fzf.{bash,zsh}.

Notice that --tac +s is not equivalent to the overloaded +s of the previous version. --tac will actually reverse the order of the items as if tac was applied before fzf, while the latter just affected how they were displayed inside the finder.

seq 1 10 | fzf -f '' --tac
  # 10
  # 9
  # 8
  # ...

Sorry for any confusion that this change might cause, but I'm sure that it makes fzf more flexible and understandable. I hope you enjoy the new version.

» capture | close