Different behavior in completion between omnicompletion and autocompletion

[clason]

Here's something I've always taken for granted but started wondering about recently: While omnicompletion looks for substrings, the corresponding source for autocomplete plugins such as deoplete or ncm2 only looks at the start of the string.

For example, if there is

\label{sec:examples}

somewhere in the document and I type

\ref{ex<c-x><c-o>

it completes this label. However, both deoplete and ncm2 only complete it on

\ref{se

This is even more extreme for BibTeX completions, where \cite{Ler<c-x><c-o> matches (case insensitive) any substring from the key, author list, and title, while autocomplete only matches the beginning of the key.

Is this by design (e.g., for the sake of performance)? or convenience in implementation? or simply impossible due to the implementation of such source? (Any of these answers would be acceptable, since we still have the omnicompletion fallback for the full matching -- although seeing the list to know how to filter quickly is somewhat helpful.)

[lervag]

This is sort of by design. The omnifunction allows filtering directly, i.e. the base string can be used to filter the matches when you do <c-x><c-o>. However, as far as I understand the autocomplete plugins, they only use the omnicomplete functions to provide the full list of completion candidates, and then have their own mechanisms for filtering. E.g., deoplete and others allow fuzzy filtering of candidates. This is not possible for the omnicompletion unless it is explicitly implemented in the omnicomplete function.

So, the short answer is that this is by design, although I understand the confusion.

[clason]

No confusion, just curiosity 😃 But then I still don't understand the behaviour in the BibTeX completion: omnicomplete can not only match keys but also authors and title -- are these not part of the candidates transmitted to the plugin? If so, how does vimtex extend the match?

[lervag]

Yes, the BibTeX completion is a little bit more "customized" than the other types, in that it allows more complex filtering. The base string is captured by the omnicomplete function and used as a regular expression against a line that contains most of the completion metadata, including author, year, title, etc. It is documented, but I do find it a little bit unintuitive myself as well. However, I sometimes use it and I guess it does not hurt to keep it like this.

[clason]

Ah, now I understand how that works! That makes sense -- and, yes, please leave it in, I love the way the BibTeX completion works 😄

(It should actually be possible to write an ncm2-bibtex source based on the same principle -- which could even be more performant because async, especially for multiple bib files, but that's a different issue for a different person...)

[lervag]

I think you might be right about that, yes. But as you say, this is for a different person. For me, things are working well enough for me to leave them as they are. I think. :)

[clason]

Actually, the pull request https://github.com/ncm2/ncm2/pull/23 already gets me pretty close -- the only difference is that omnicomplete can complete based on the full author list while autocomplete can only match the condensed list put into abbrv. Although if vimtex puts the full bibitem into the info field, it might be possible to match on that (as a bonus, one could then optionally show this in a preview window, which might be useful sometimes). No idea whether this would kill the performance, though. I'd be willing to test it, though ;)

I'll update my pull request for the documentation once it gets merged. (This is already a sufficient improvement over deoplete to make me switch, by the way.)

[lervag]

Thanks! I've noticed that there is some activity from your end. I'll try to look at it as soon as possible.