feat(api): allow lua complete fn to return a string

[faergeek]

Makes it possible to provide completion options without having to also implement filtering logic.

Fixes #25565

This implementation involves one more copy-paste of the same code to create a new function. But as I understand currently that's how customlist was implemented for lua before as well (ExpandUserLua is almost identical to ExpandUserList, see #16752).

Is this still an ok way to do it?

[faergeek]

Not sure if this should be included in news.txt

[faergeek]

Hey @bfredl @famiu, could you please take a look at this pull request?

[famiu]

Hey @bfredl @famiu, could you please take a look at this pull request?

I'm not the right person to look at this. Bfredl, Lewis and Zeertz would be much more suited for this PR.

[faergeek]

Hey @lewis6991 @zeertzjq could you take a look please?

[lewis6991]

I'm not convinced this a good idea. What is the problem with just returning a table? In the testcase you just need to wrap the result with vim.split(x, '\n').

[faergeek]

@lewis6991 returning a string allows you to simply return all possible options and utilize builtin filtering of options. On the other hand, when returning a table you're expected to filter options yourself inside that function and only return options that match as neovim won't do that for you in that case.

I've gone that route because I thought it would be really easy to implement, since there are "complete" and "completelist" options which have the same difference in behavior. But may be it should be done in a different way to make that difference in behavior more explicit.

[lewis6991]

Thanks for the explanation, the filtering difference between custom and customlist wasn't obvious to me.

I'm not really sure why this difference even exists. Usually it's because one is supposed to be replaced by the other. I'd assume complete came first and then replaced by customlist. Either the lack of filtering is intetional or just a mistake.

Maybe worth checking with vim what the correct behaviour should be and whether customlist is supposed to supersede custom.

[faergeek]

Either the lack of filtering is intetional or just a mistake.

Not sure if that says something in that regard, but at least that difference is documented at :help :command-completion-custom / help :command-completion-customlist.

Maybe worth checking with vim what the correct behaviour should be and whether customlist is supposed to supersede custom.

Maybe it is supposed to supersede it, but having an ability to make neovim do the filtering for you seems to be quite useful anyway, don't you agree?

[justinmk]

This implementation involves one more copy-paste of the same code to create a new function

No.

Here's the diff of the new way vs the existing way:

This is pointless. What problem is being solved here?

[justinmk]

I'm not really sure why this difference even exists. Usually it's because one is supposed to be replaced by the other. I'd assume complete came first and then replaced by customlist. Either the lack of filtering is intetional or just a mistake.

Maybe worth checking with vim what the correct behaviour should be and whether customlist is supposed to supersede custom.

Yes, exactly. custom should be deprecated, not proliferated.

These kinds of localized, minor conveniences are not worth the extra code + docs + tests + explanation + bugs.

[justinmk]

having an ability to make neovim do the filtering for you seems to be quite useful anyway, don't you agree?

That could be a util function. It should not be achieved by adding extra interfaces.