| Age | Commit message (Collapse) | Author |
|---|
|
When --nth is used with a custom --delimiter, the last delimiter was
included in the search scope, forcing you to write the delimiter in
a suffix-match query. This commit removes the last delimiter from the
search scope.
# No need to write 'bar,$'
echo foo,bar,baz | fzf --delimiter , --nth 2 --filter 'bar$'
This can be seen as a breaking change, but I'm gonna say it's a bug fix.
Fix #3983
|
|
(#4231)
Close #4185
|
|
This option can be used to replace a sed or awk in the post-processing step.
ps -ef | fzf --multi --header-lines 1 | awk '{print $2}'
ps -ef | fzf --multi --header-lines 1 --accept-nth 2
This may not be a very "Unix-y" thing to do, so I've always felt that fzf
shouldn't have such an option, but I've finally changed my mind because:
* fzf can be configured with a custom delimiter that is a fixed string
or a regular expression.
* In such cases, you'd need to repeat the delimiter again in the
post-processing step.
* Also, tools like awk or sed may interpret a regular expression
differently, causing mismatches.
You can still use sed, cut, or awk if you prefer.
Close #3987
Close #1323
|
|
Fix #4222
|
|
|
|
* Proper clean-up of caches
* Force rerender list after the action
|
|
Only requiring '-suffix in --exact mode is confusing and not
straightforward. Requiring '-prefix in --exact mode means that
the users can experience unintended mode switches while typing.
e.g.
'it -> fuzzy (many results)
'it' -> boundary (few results)
'it's -> fuzzy (many results)
However, user who intends to input a boundary query should not be
interested in the intermediate results, and the number of matches
decreases as she types, so it should be okay.
On the other hand, user who does intend to type "it's" will be surprised
by the sudden decrease of the match count, but eventually get the right
result.
|
|
Close #3963
|
|
|
|
|
|
|
|
|
|
|
|
Fix #1618
|
|
Fix #1458
|
|
Add String() methods to types, so they can be printed with %s. Change
some %s format specifiers to %v, when the default string representation
is good enough. In Go 1.10, `go test` triggers a parallel `go vet`. So
this also makes fzf pass `go test`.
Close #1236
Close #1219
|
|
|
|
|
|
https://github.com/junegunn/fzf/issues/444#issuecomment-321719604
|
|
|
|
When $ is the leading character in a query, it's probably not meant to
be an anchor.
|
|
|
|
https://github.com/junegunn/fzf/issues/444#issuecomment-321432803
|
|
Close #444
|
|
One can escape meta characters in extended-search mode with backslashes.
Prefixes:
\'
\!
\^
Suffix:
\$
Term separator:
\<SPACE>
To keep things simple, we are not going to support escaping of escaped
sequences (e.g. \\') for matching them literally.
Since this is a breaking change, we will bump the minor version.
Close #444
|
|
|
|
Manually inline function calls in a tight loop as Go compiler does not
inline non-leaf functions. It is observed that this unpleasant code
change resulted up to 10% performance improvement.
|
|
When --with-nth is used, fzf used to preprocess each line and store the
result as rune array, which was wasteful if the line only contains ascii
characters.
|
|
By not storing item index twice, we can cut down the size of Result
struct and now it makes more sense to store and pass Results by values.
Benchmarks show no degradation of performance by additional pointer
indirection for looking up index.
|
|
|
|
- Remove multiple mutex locks in partial cache lookup
- Simplify return values
|
|
|
|
Make sure to consistently calculate tiebreak scores based on the
original line.
This change may not be preferable if you filter aligned tabular input on
a subset of columns using --nth. However, if we calculate length
tiebreak only on the matched components instead of the entire line, the
result can be very confusing when multiple --nth components are
specified, so let's keep it simple and consistent.
Close #926
|
|
|
|
|
|
Close #790
|
|
This is a breaking change, but I believe it makes much more sense. It is
almost impossible to predict which entries will be filtered out due to
a fuzzy inverse term. You can still perform inverse-fuzzy-match by
prepending `!'` to the term.
| Token | Match type | Description |
| -------- | -------------------------- | --------------------------------- |
| `sbtrkt` | fuzzy-match | Items that match `sbtrkt` |
| `^music` | prefix-exact-match | Items that start with `music` |
| `.mp3$` | suffix-exact-match | Items that end with `.mp3` |
| `'wild` | exact-match (quoted) | Items that include `wild` |
| `!fire` | inverse-exact-match | Items that do not include `fire` |
| `!.mp3$` | inverse-suffix-exact-match | Items that do not end with `.mp3` |
|
|
|
|
|
|
|
|
- Make structs smaller
- Introduce Result struct and use it to represent matched items instead of
reusing Item struct for that purpose
- Avoid unnecessary memory allocation
- Avoid growing slice from the initial capacity
- Code cleanup
|
|
|
|
In the best case (all ascii), this reduces the memory footprint by 60%
and the response time by 15% to 20%. In the worst case (every line has
non-ascii characters), 3 to 4% overhead is observed.
|
|
When we prepend a single quote to our query in --exact mode, we are not
supposed to limit the scope of the new search to the previous
exact-match result.
|
|
Based on the patch by Matt Westcott (@mjwestcott).
But with a more conservative approach:
- Does not use linearly increasing penalties; It is agreed upon that we
should prefer matching characters at the beginnings of the words, but
it's not always clear that the relevance is inversely proportional to
the distance from the beginning.
- The approach here is more conservative in that the bonus is never
large enough to override the matchlen, so it can be thought of as the
first implicit tiebreak criterion.
- One may argue the change breaks the contract of --tiebreak, but the
judgement depends on the definition of "tie".
|
|
This commit compensates for the performance overhead from the
extended tiebreak option.
|
|
|
|
|
|
Close #412
|
|
Close #400
|
