nvim-lsp with mucomplete breaks the repeat command

[lourenci]

Hi, thanks for the plugin.

I'm using nvim-lsp and I don't know why, but mucomplete breaks the dot command. Nvim-lsp uses the omni function.

You can see here:
https://asciinema.org/a/FDcDscBWOcHUiffzm0mbSGCsP

[cideM]

I had the same issue in Dhall. Did you try adjusting the delay and reopen immediately options?

[ghost]

Facing the same issue.

Pinging @lifepillar for visibility.

[lifepillar]

Can someone provide detailed instructions (plugins, configurations, etc.) to reproduce this?

[ghost]

Here's the config.

filetype indent plugin on
syntax on

call plug#begin('~/.local/share/nvim/plugged')
Plug 'lifepillar/vim-mucomplete'
Plug 'nvim-lua/popup.nvim'
Plug 'nvim-lua/plenary.nvim'
Plug 'neovim/nvim-lspconfig'
call plug#end()

set completeopt-=preview
set completeopt+=menuone,noinsert
set pumheight=4
let g:mucomplete#enable_auto_at_startup=1
let g:mucomplete#minimum_prefix_length=2

lua << EOF
vim.lsp.set_log_level("debug")
local lsp = require("lspconfig")

local on_attach = function(client, bufnr)
    vim.api.nvim_buf_set_option(bufnr, "omnifunc", "v:lua.vim.lsp.omnifunc")
end

lsp["fortls"].setup({
    cmd = {
        "fortls",
        "--incremental_sync",
        "--use_signature_help",
        "--lowercase_intrinsics",
    },
    on_attach = on_attach,
    root_dir = lsp.util.root_pattern(".git"),
    filetypes = { "fortran" },
    settings = { nthreads = 1 },
})
EOF

Here's a fortran file to reproduce the error

module test
    implicit none

    integer, parameter :: N = 128
    integer, parameter :: D = 2

    real(8) :: length(D)

contains

    subroutine tracking_init()
        real(8) :: alpha, beta, delta
        real(8) :: alpha_test, beta_test, delta_test
    end subroutine tracking_init

end module tracking

Steps to reproduce:

• You need to install fortran-language-server, simplest is to do pip install fortran-language-server.
• Start editing this file with the config.
• Jump to alpha, do ciw and start typing alph.., wait for the auto completion to kick in, accept the completion provided by lsp.
• Jump to any other word and use . repeat. Words are completed with missing letters.

Here's an asciinema cast showing the issue (renamed to debug.txt)

debug.txt

[ghost]

Commenting out the line : vim.api.nvim_buf_set_option(bufnr, "omnifunc", "v:lua.vim.lsp.omnifunc") fixes the issue.

[ghost]

@lifepillar Any updates on this?

[lifepillar]

I have tried the config above, but nvim -u config.vim results in E5108: Error executing lua [string ":lua"]:2: module 'lspconfig' not found (Neovim 0.5.1). Is there any other prerequisite?

[navdeeprana]

@lifepillar :PlugInstall ?

[lifepillar]

Yeah, that was it, apparently. Still, when I open a Fortran file, omnifunc is not set. I have installed fortran-language-server, and fortls is in my $PATH (checked from inside Neovim). Any idea how to debug this?

Output of LspInfo:

Language client log: /Users/me/.cache/nvim/lsp.log                                   
Detected filetype:   fortran                                                             
                                                                                         
0 client(s) attached to this buffer:                                                     
                                                                                         
Other clients that match the filetype: fortran                                           
                                                                                         
Config: fortls                                                                           
 filetypes:         fortran                                                              
 root directory:    NA                                                                   
 cmd:               fortls --incremental_sync --use_signature_help --lowercase_intrinsics
 cmd is executable: true                                                                 
 autostart:         true                                                                 
 custom handlers:                                                                        
                                                                                         
Configured servers list: fortls                                                          

The cache contains only pairs of lines like this:

[START][2021-10-10 12:51:48] LSP logging initiated
[INFO][2021-10-10 12:52:32] .../lua/vim/lsp.lua:1226	"exit_handler"	{}

[navdeeprana]

I think the fortran file needs to be in a git repo. I tested it for a sample fortran file, fortls does not attach to the file unless I put it in a git repo.

[lifepillar]

Ok, I can reproduce it. Using your example, after typing al, local keyword completion is triggered, as expected, offering alpha_test as a completion. But if I accept the completion (by typing CTRL-Y), the pop-up menu immediately reopens offering omni-completion. That happens even with g:mucomplete#reopen_immediately=0 (see @cideM's suggestion). That should not happen.

This may be tough to debug.

[lifepillar]

local keyword completion is triggered, as expected

No, wait, that is not expected, because omni-completion comes first in the completion chain. Unfortunately, setting a delay does not seem to help. Having both 'omni' and 'keyn' in the completion chain seems to conflict with nvim-lsp.

A possible workaround is to define a filetype-specific completion chain which enables only the 'omni' method. Can you check if that works for you? You may test it on the fly by setting:

let b:mucomplete_chain=['omni']

in the Fortran buffer.

[navdeeprana]

It works properly with just the omni method.

And yes tweaking the delay and reopen settings as suggested by @cideM does not help.

[lifepillar]

I think I know what is going on: when the completion chain is ['omni', 'keyn'], MUcomplete tries omni-completion first. For some reason, nvim-lsp delays opening the popup menu: MUcomplete tests whether omni-completion triggered the popup menu, and finds that it didn't. So, it tries the next method (keyword completion in this case). So, the popup menu shows the results of keyword completion. But, in the meantime, nvim-lsp has done its job, and when the user dismisses the popup menu Vim reopens it with the results of omni-completion. Breaking the repeat command is a side effect.

The workaround in the documentation (set completion delay and reset mucomplete#reopen_immediately) is an attempt to work around the problem above. I don't know what else could be done.

If you want keyword completion in your completion chain, you should put it before omni-completion. I.e., any of the following should work:

let b:mucomplete_chain = ['omni']
let b:mucomplete_chain = ['keyn', 'omni']

[navdeeprana]

I tested with let b:mucomplete_chain = ['keyn', 'omni'] and it seems to work now. FYI, I have

let g:mucomplete#chains={'default': [ 'ulti', 'file', 'path', 'omni', 'c-n', 'c-p', 'line']}

which also breaks the dot command, most likely a conflict b/w c-n and omni. Again, putting omni after c-n, c-p in the chain works.

[navdeeprana]

@mjlbach Can you please have a look at it? I can reproduce the error with fortran-language-server and pylsp. @lifepillar has summarized the issue in #180 (comment).

Do you think we should open an issue in the neovim repository?

[mjlbach]

I don't use mucomplete (or any autocompletion), so not sure what you are asking. Maybe related, neovim/neovim#12390. We asynchronously populate the omnifunc results after opening pmenu.

The entire implementation is here: https://github.com/mjlbach/neovim/blob/b11e000cec48ce1ea851188b38945fd74ad006e5/runtime/lua/vim/lsp.lua#L1408-L1448

I'm not sure what the issue is (apart from incompatibility with a plugin), as the built-in omnifunc works fine.

[lifepillar]

Thanks for the links. To be clear, I was not implying that there is an issue with nvim-lsp: it's just that MUcomplete is intrinsecally incompatible with certain ways of populating the popup menu, e.g., using complete_add(). Likely, the same limitation of MUcomplete applies to nvim-lsp.

[mjlbach]

To be clear, I was not implying that there is an issue with nvim-lsp: it's just that MUcomplete is intrinsecally incompatible with certain ways of populating the popup menu, e.g., using complete_add(). Likely, the same limitation of MUcomplete applies to nvim-lsp.

Oh totally, sorry, just wanted to clarify our omnifunc does work, it just might not work within the constraints of your plugin.

There's this issue: neovim/neovim#12390 asking for a synchronous omnifunc, which I'm assuming would be compatible with mucomplete