vim-mucomplete icon indicating copy to clipboard operation
vim-mucomplete copied to clipboard

Latest upstream insert completion patches

Open Konfekt opened this issue 3 months ago • 16 comments

Hello @lifepillar , this plug-in has been serving very well. Just wondering if any adaptions to the insert completion patches and ongoing work are due? For example, @habamax 's post shows how to replicate some features of this plug-in

Konfekt avatar Sep 25 '25 06:09 Konfekt

Good question. I haven't followed the recent developments too closely, so I should probably catch up. But I have other commitments at the moment, so I'm not sure when that could happen. Thanks for the links, btw.

Regarding possible updates, do you have anything specific in mind? Any issue? On a cursory look, what @habamax is proposing there looks very similar to a “proto-MUcomplete”.

Looking at that code, one enhancement might be supporting command-line autocompletion, which now seems possible (it was requested in the past: https://github.com/lifepillar/vim-mucomplete/issues/187).

lifepillar avatar Sep 25 '25 09:09 lifepillar

So @habamax 's post seems like it implements context-aware chained (fallback) completion, which for me covers mucomplete's main utility. I think the most important practical question is how to pair mucomplete best with Yeggapan's lsp omnicompletion, to which @habamax just gave a related answer here https://github.com/girishji/vimcomplete/issues/101#issuecomment-3332443392

Konfekt avatar Sep 25 '25 11:09 Konfekt

how to pair mucomplete best with Yeggapan's lsp omnicompletion

As long as LSP is made available via omnifunc, it should work with MUcomplete as any other omnicompletion. But the discussion you link mentions asynchronous completion, and that is another pair of shoes as MUcomplete was never meant for async processing. Anyway, thanks for your feedback. I will try to set up some time to review all the new stuff in Vim and try LSP as well.

lifepillar avatar Sep 25 '25 11:09 lifepillar

I have extended the Readme to account for some recent changes in Vim's completion functionality. As far as I can see, such changes cover two aspects:

  1. extended options in 'complete'—in particular, an F option to call an arbitrary completion function.
  2. support for autocompletion via 'autocomplete' and related options.

I think that nothing needs to be updated in MUcomplete. For (1), you may simply configure 'complete' as you like, and add a 'c-n' or ``'c-p'` method to your completion chains.

Vim's 'autocomplete' should be essentially equivalent (but possibly more performant) to MUcomplete with autocompletion on and with a completion chain containing equal to ['c-n']—except that MUcomplete allows you to customize the patterns that trigger the completion. So, Vim's built-in autocompletion and MUcomplete autocompletion are mutually exclusive.

lifepillar avatar Sep 28 '25 12:09 lifepillar

MUcomplete allows you to customize the patterns that trigger the completion

Since autocompletion always fires, and for fine-grained control one has to revert to @habamax 's initial setup

# When autocompletion should be triggered per each filetype
# specified
var instrigger = {
    vim: '\v%(\k|\k-\>|[gvbls]:)$',
    c: '\v%(\k|\k\.|\k-\>)$',
    python: '\v%(\k|\k\.)$',
    gdscript: '\v%(\k|\k\.)$',
    ruby: '\v%(\k|\k\.)$',
    javascript: '\v%(\k|\k\.)$',
}
def InsComplete()
    var trigger = get(instrigger, &ft, '\k$')
    if getcharstr(1) == '' && getline('.')->strpart(0, col('.') - 1) =~ trigger
        SkipTextChangedI()
        feedkeys("\<c-n>", "n")
    endif
enddef

augroup inscomplete
    au!
    autocmd TextChangedI * InsComplete()
augroup END

@habamax , maybe worth an entry in :help ins-autocompletion ?

Konfekt avatar Sep 28 '25 13:09 Konfekt

extended options in 'complete'—in particular, an F option to call an arbitrary completion function.

Is this, or would have been, in principle of interest for custom completions like this plug-in's path completion ? I wonder to what good use this can be put besides those examples given in Vim's help (no that strikingly useful yet).

Konfekt avatar Sep 28 '25 13:09 Konfekt

Yes, that seems like an interesting idea to explore. Also interesting to investigate the performance trade-offs.

lifepillar avatar Sep 28 '25 20:09 lifepillar

One example you may already try is the 'list' completion method. Instead of adding 'list' to a completion chain, you may just add the completion function to 'complete':

set complete^=Fmucomplete#list#completefunc
let b:mucomplete_wordlist=['shark', 'sheer', 'sport', 'sherpa']

Other MUcomplete methods such as 'path' and 'uspl' do not have a compatible interface, but it should be fairly easy to add one.

lifepillar avatar Sep 28 '25 20:09 lifepillar

@Konfekt each completion function can and should decide what triggers completion, so that code should be redundant now. (it was created pre ac)

habamax avatar Sep 28 '25 23:09 habamax

@lifepillar Just discovered the list option, which seems similar to Vim's complete+=k<path>. Might have been a Vim tip somewhere, and maybe needs to be known more

Other MUcomplete methods such as 'path' and 'uspl' do not have a compatible interface, but it should be fairly easy to add one.

I'd like to have a look

Konfekt avatar Sep 29 '25 06:09 Konfekt

the list option, which seems similar to https://github.com/girishji/vimcomplete/pull/86#issuecomment-2522534145

Several MUcomplete methods have a more or less equivalent option in 'complete'. The rationale for having a separate completion method in MUcomplete is explained in :help mucomplete-tips:

The "c-n", "c-p" and "line" methods allow you to aggregate completion suggestions from several sources (see 'complete'), including dictionaries and tags. While this is handy, it may have a couple of drawbacks: first, you may get too many suggestions, making completion less useful; second, you may incur an efficiency penalty, especially if you have big tag files or dictionaries or many included files.

That was written long time ago: now, 'complete' supports limiting the number of reported entries. Also the argument about the performance needs to be double-checked as there has been improvements in that department, too, I think.

Nowadays, you may go a long way just by configuring Vim options. That's very good news: kudos to Vim's developers and contributors!

lifepillar avatar Sep 29 '25 06:09 lifepillar

@lifepillar It seems as if cmd in :help mucomplete-methods is superseded by omni with setlocal omnifunc=vimcomplete#Complete in https://github.com/vim/vim/pull/18568

Konfekt avatar Oct 15 '25 05:10 Konfekt

Thanks. Now the current master uses 'omni' in Vim filetypes instead of 'cmd' if Vim is recent enough.

lifepillar avatar Oct 15 '25 18:10 lifepillar

extended options in 'complete'—in particular, an F option to call an arbitrary completion function.

Is this, or would have been, in principle of interest for custom completions like this plug-in's path completion ? I wonder to what good use this can be put besides those examples given in Vim's help (no that strikingly useful yet).

I have just came up with path completion to be used with autocomplete: https://github.com/habamax/.vim/blob/master/autoload/completor.vim#L68-L119

https://asciinema.org/a/2hFPVE3nq5GofBNdvDLaQ22XV

PS, doesn't properly handle path with spaces.

habamax avatar Oct 28 '25 09:10 habamax

@habamax Have you checked autoload/mucomplete/path.vim? That handles paths with spaces. It is not meant to be used with set complete, but it should be fairly easy to adapt to that.

lifepillar avatar Oct 28 '25 12:10 lifepillar

@habamax Have you checked autoload/mucomplete/path.vim? That handles paths with spaces. It is not meant to be used with set complete, but it should be fairly easy to adapt to that.

I haven't yet. Will check once I am ready to continue with path completion enhancements :)

habamax avatar Oct 29 '25 10:10 habamax