-
-
Notifications
You must be signed in to change notification settings - Fork 588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistent Tags/BTags with query #1572
base: master
Are you sure you want to change the base?
Conversation
The `BTags` command is declared with optional `[QUERY]` while the `Tags` command is declared with optional `[PREFIX]`. The query behavior in `BTags` source generator is less restrictive compared to `Tags` whose source is generated using the `readtags` external command, where tags are only listed if `PREFIX` is an exact match. This commit relaxes the exact prefix match when `readtags` is used to allow for a fuzzy prefix similar to the source generator of `BTags`. The `fzf` fuzzy score ranking in the `s:tags_sink` will still rank the best fuzzy match on top, same as if the match was exact like in the current implementation (although additional second order matches may be produced by this relaxed `Tags [QUERY]` implementation which are excluded by the current `Tags [PREFIX]` implementation). The changes in this commit are useful for tags that contain some scope prefixes like the functions `s:tags_sink` or `fzf#vim#tags` in vim-script code, in combination with a key mapping of the form ```vim nnoremap <silent> <leader>l :execute "Tags '" . expand('<cword>')<CR> nnoremap <silent> <leader>bl :execute "BTags '" . expand('<cword>')<CR> ``` If the cursor is placed on the word "tags" in this example `fzf#vim#tags`, the relaxed `Tags` query call will list the tags entry if `<cword>` expands to "tags", while the current implementation will not. Inconsistently, the `BTags` call will list the tags entry with its current implementation.
The reason we only allow a prefix is to make See #1524 |
Thanks for the referenced issue, I missed that somehow. It would be nice to have a homogeneous interface between |
I don't think it's possible. You can't avoid scanning through the whole list for non-prefix queries. If performance is not a concern for you, you can redefine command! -bang -nargs=* Tags call fzf#vim#tags('', fzf#vim#with_preview({ "options": ['--query', <q-args>], "placeholder": "--tag {2}:{-1}:{3..}" }), <bang>0) Original definition: Line 65 in c5ce790
|
I believe you are correct. Using Here are a few test results (the first test result corresponds to the implementation I use in the commit above): Linux kernel tags file:
Some other large project (tags file one order of magnitude smaller than Linux kernel):
If I understand your suggestion w/r/t redefining the
whereas using
which I could consider as performance trade-off at the benefit of homogeneous From your perspective, is it possible to support a custom |
The
BTags
command is declared with optional[QUERY]
while theTags
command is declared with optional
[PREFIX]
. The query behavior inBTags
source generator is less restrictive compared toTags
whosesource is generated using the
readtags
external command, where tagsare only listed if
PREFIX
is an exact match. This commit relaxes theexact prefix match when
readtags
is used to allow for a fuzzy prefixsimilar to the source generator of
BTags
. Thefzf
fuzzy scoreranking in the
s:tags_sink
will still rank the best fuzzy match ontop, same as if the match was exact like in the current implementation.
The changes in this commit are useful for tags that contain some scope
prefixes like the functions
s:tags_sink
orfzf#vim#tags
invim-script code, in combination with a key mapping of the form
If the cursor is placed on the word "tags" in this example
fzf#vim#tags
, the relaxedTags
query call will list the tags entryif
<cword>
expands to "tags", while the current implementation willnot. Inconsistently, the
BTags
call will list the tags entry with itscurrent implementation.