Apparently it makes it so characters or words that are matched can make the result with the match be prioritized differently according to the word boundaries.
Then, 26 days later on Aug 28, 2022 version 0.33.0 added a parameter --scheme that lets the user use two other scoring algorithms, one of them being the pre 0.32.0 that they seem to have called history (I imagine because it's more intuitive for command history search).
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 48dfb69e0a..f84735af76 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,8 +1,18 @@
CHANGELOG
=========
-0.32.2
-------
+0.33.0
+------
+- Added `--scheme=[default|path|history]` option to choose scoring scheme
+ - (Experimental)
+ - We updated the scoring algorithm in 0.32.0, however we have learned that
+ this new scheme (`default`) is not always giving the optimal result
+ - `path`: Additional bonus point is only given the the characters after
+ path separator. You might want to choose this scheme if you have many
+ files with spaces in their paths.
+ - `history`: No additional bonus points are given so that we give more
+ weight to the chronological ordering. This is equivalent to the scoring
+ scheme before 0.32.0. This also sets `--tiebreak=index`.
- ANSI color sequences with colon delimiters are now supported.
```sh
printf "\e[38;5;208mOption 1\e[m\nOption 2" | fzf --ansi
This basically means that using PSFzf with fzf 0.32.0 or newer will sort the results differently and, imo, in a worse way when searching for command history.
The behavior can easily be brought to what it was using previous versions of fzf just by adding --scheme=history in the list of arguments passed to fzf.
I thought about creating a Pull Request that simply added this option in the Invoke-Fzf function and used that parameter in the call inside Invoke-FuzzyHistory and Invoke-FzfPsReadlineHandlerHistory, but that would break compatibility with fzf versions prior to 0.33.0.
So before going any further, thought I'd add this issue here. I can see the following ways going forward (and for any of them I'd be willing to open a PR contributing the necessary changes):
Offering the option to append the argument in Invoke-Fzf through a new function parameter and using that parameter in the calls inside Invoke-FuzzyHistory and Invoke-FzfPsReadlineHandlerHistory
Do that but only if a version check for fzf inside Invoke-Fzf succeeds (It seems something similar is already done for an option for appending --height=40%)
Keep it as it is and add some kind of note in the README alluding to that change in fzf and proposing the use of the FZF_DEFAULT_OPTS env var as a solution for the end user
Keep it as it is and consider this a non-issue because it conforms with the defaults of fzf and the user should know that PSFzf is just a shortcut for fzf and that any behavior different than the default should be configured through the FZF_DEFAULT_OPTS
Of course these solutions were what initially came to my head. If there's any better way, I'm all ears.
Hello!
A new version of fzf (0.32.0) was released on Aug 2, 2022 and updated the scoring algorithm.
Apparently it makes it so characters or words that are matched can make the result with the match be prioritized differently according to the word boundaries.
Then, 26 days later on Aug 28, 2022 version 0.33.0 added a parameter
--schemethat lets the user use two other scoring algorithms, one of them being the pre 0.32.0 that they seem to have calledhistory(I imagine because it's more intuitive for command history search).This basically means that using PSFzf with fzf 0.32.0 or newer will sort the results differently and, imo, in a worse way when searching for command history.
The behavior can easily be brought to what it was using previous versions of fzf just by adding
--scheme=historyin the list of arguments passed to fzf.I thought about creating a Pull Request that simply added this option in the
Invoke-Fzffunction and used that parameter in the call insideInvoke-FuzzyHistoryandInvoke-FzfPsReadlineHandlerHistory, but that would break compatibility with fzf versions prior to 0.33.0.So before going any further, thought I'd add this issue here. I can see the following ways going forward (and for any of them I'd be willing to open a PR contributing the necessary changes):
Invoke-Fzfthrough a new function parameter and using that parameter in the calls insideInvoke-FuzzyHistoryandInvoke-FzfPsReadlineHandlerHistoryInvoke-Fzfsucceeds (It seems something similar is already done for an option for appending--height=40%)FZF_DEFAULT_OPTSenv var as a solution for the end userFZF_DEFAULT_OPTSOf course these solutions were what initially came to my head. If there's any better way, I'm all ears.