Fuzzy matching with vimgrep

[Yegappan Lakshmanan]

Hi all,

The support for searching for fuzzy matches with the
vimgrep command was recently added (8.2.2813).

In the current implementation, each line in a specified file(s)
is compared against the supplied search string (fuzzy match)
and if there is a match, then the line is added to the
quickfix list.

The matches are not sorted by the fuzzy match score. So the
line that has the best match for the supplied string may be
present later in the quickfix list.

Should we order the matches by the fuzzy match score so that
the best matches show up earlier in the quickfix list? One
downside to this approach is that the entries in the quickfix
list will not be sorted by the file name and the line number
and they will be mixed across files.

- Yegappan

[Bram Moolenaar]

:vimgrep was made to find matches and skip non-matches, it hasn't been
used for using a match score. Thus I think that's how it should keep
working by default.

In some cases the sorting by score could be useful. Can we sort after
:vimgrep has finished? Or would it need to be another flag or extra
flag?

--
hundred-and-one symptoms of being an internet addict:
191. You rate eating establishments not by the quality of the food,
but by the availability of electrical outlets for your PowerBook.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Dominique Pellé]

It's not so clear to me in which cases I will use fuzzy :vimgrep.
The results are often unclear as to why they match.

I did this for example in Vim:

:cd vim/src
:vimgrep /message/f *.c

I get results like this:

arglist.c|20 col 38| // This flag is set whenever the argument list is
being changed and calling a

At first I expected to find a word that looked like "message"
but that's not the case. I think this line matches because it
matches /m.*e.*s.*s.*a.*g.*e/

This kind of fuzzy matching makes more sense to me when:
- it's sorted by score (as you suggest)
- and there is some visual feedback (highlighting of what matches)
to help understand why it matches, as done e.g by
https://github.com/junegunn/fzf
https://github.com/junegunn/fzf.vim

Regards

Dominique

[Yegappan Lakshmanan]

Hi Bram,

On Thu, Apr 29, 2021 at 3:31 AM Bram Moolenaar <Br...@moolenaar.net> wrote:
>
>
> Yegappan wrote:
>
> > The support for searching for fuzzy matches with the
> > vimgrep command was recently added (8.2.2813).
> >
> > In the current implementation, each line in a specified file(s)
> > is compared against the supplied search string (fuzzy match)
> > and if there is a match, then the line is added to the
> > quickfix list.
> >
> > The matches are not sorted by the fuzzy match score. So the
> > line that has the best match for the supplied string may be
> > present later in the quickfix list.
> >
> > Should we order the matches by the fuzzy match score so that
> > the best matches show up earlier in the quickfix list? One
> > downside to this approach is that the entries in the quickfix
> > list will not be sorted by the file name and the line number
> > and they will be mixed across files.
>
> :vimgrep was made to find matches and skip non-matches, it hasn't been
> used for using a match score. Thus I think that's how it should keep
> working by default.
>
> In some cases the sorting by score could be useful. Can we sort after
> :vimgrep has finished? Or would it need to be another flag or extra
> flag?
>

We will need to add another flag to sort the fuzzy matches by score.
What about using the flag 's' for sort?

Regards,
Yegappan

[Yegappan Lakshmanan]

Hi,

On Thu, Apr 29, 2021 at 4:44 AM Dominique Pellé
<dominiq...@gmail.com> wrote:
>
> Yegappan Lakshmanan <yega...@gmail.com> wrote:
>
> > Hi all,
> >
> > The support for searching for fuzzy matches with the
> > vimgrep command was recently added (8.2.2813).
> >
> > In the current implementation, each line in a specified file(s)
> > is compared against the supplied search string (fuzzy match)
> > and if there is a match, then the line is added to the
> > quickfix list.
> >
> > The matches are not sorted by the fuzzy match score. So the
> > line that has the best match for the supplied string may be
> > present later in the quickfix list.
> >
> > Should we order the matches by the fuzzy match score so that
> > the best matches show up earlier in the quickfix list? One
> > downside to this approach is that the entries in the quickfix
> > list will not be sorted by the file name and the line number
> > and they will be mixed across files.
> >
> > - Yegappan
>
> It's not so clear to me in which cases I will use fuzzy :vimgrep.
> The results are often unclear as to why they match.
>

Fuzzy matching using vimgrep is useful, when you are searching
for multiple partial words which can occur in any order. But I agree
that it will be more useful to sort the matches by score so that
the best matches will be listed first.

>
> I did this for example in Vim:
>
> :cd vim/src
> :vimgrep /message/f *.c
>
> I get results like this:
>
> arglist.c|20 col 38| // This flag is set whenever the argument list is
> being changed and calling a
>
> At first I expected to find a word that looked like "message"
> but that's not the case. I think this line matches because it
> matches /m.*e.*s.*s.*a.*g.*e/
>

Yes. But note that the best match within a line is used and the
column is set to the first matching character.

>
> This kind of fuzzy matching makes more sense to me when:
> - it's sorted by score (as you suggest)
> - and there is some visual feedback (highlighting of what matches)
> to help understand why it matches, as done e.g by
> https://github.com/junegunn/fzf
> https://github.com/junegunn/fzf.vim
>
> Regards
> Dominique
>

Thanks,
Yegappan

[Bram Moolenaar]

Yes, that can work. When using both 'f' and 's' it would be the same.

I was thinking of perhaps using 'F', but using 's' makes more sense.

--
hundred-and-one symptoms of being an internet addict:

196. Your computer costs more than your car.