search

andymass / vim-matchup

vim match-up: even better % :facepunch: navigate and highlight matching words :facepunch: modern matchit and matchparen. Supports both vim and neovim + tree-sitter.
https://www.vim.org/scripts/script.php?script_id=5624
MIT License
1.68k stars 70 forks source link

Conflict with coc.nvim snippet expansion #67

Open oblitum opened 5 years ago

oblitum commented 5 years ago

  1. What vim version are you using? NVIM v0.4.0-1198-g0dc73b87f

  2. Steps to reproduce

    augroup vimrc | autocmd! | augroup end

if empty(glob('~/.vim/autoload/plug.vim'))
  silent !curl -fLo "$HOME/.vim/autoload/plug.vim" --create-dirs 'https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim'
  autocmd vimrc VimEnter * PlugInstall --sync | source $MYVIMRC
endif

call plug#begin('~/.vim/plugged')
Plug 'tpope/vim-sensible'
call plug#load('vim-sensible')
Plug 'andymass/vim-matchup'
Plug 'neoclide/coc.nvim', {'do': 'yarn install --frozen-lockfile'}
call plug#end()

let g:coc_user_config = {
\   'languageserver': {
\     'rust': {
\       'command': 'ra_lsp_server',
\       'filetypes': ['rust'],
\       'rootPatterns': ['Cargo.toml']
\     }
\   }
\ }

    • cargo init foo && cd foo

    • Start neovim with command: nvim -u mini.vim src/main.rs

    • in main type x.if and expand the suggestion

  3. Expected behavior When coc.nvim expands rust analyzer magic completions, it should put the cursor in the right place after expansion

  4. Observed behavior When vim-matchup is present, cursor lands in bad location after snippet expansion, for example, in the following gif, both x.if and x.box expands badly, when vim-matchup isn't present the cursor is placed inside the if body after expansion, not outside, this happens just for some snippets, for more background please check https://github.com/neoclide/coc.nvim/issues/961 screencast

Sorry for the long list of requirements to reproduce this issue, but it's what I have to cause it. I've only seen this when coding Rust with rust-analyzer, which provides these kind of special snippets. I suppose it can at least give an idea why matchup would conflict with snippets expansion in general, maybe it's not a coc.nvim only issue.

andymass commented 5 years ago

Is there any way you can test this with vim instead of neovim? I wonder if this is a difference in the way CursorMoved is handled between vim/neovim, a bug in neovim maybe.

Additionally, can you see if

:let g:matchup_matchparen_nomode = 'i'

does anything?

oblitum commented 5 years ago

Is there any way you can test this with vim instead of neovim? I wonder if this is a difference in the way CursorMoved is handled between vim/neovim, a bug in neovim maybe.

I just tested and in vim there's no issue, only in NeoVim.

Additionally, can you see if

:let g:matchup_matchparen_nomode = 'i'

does anything?

Yes it does, it fixes the issue on NeoVim.

Any idea where this issue pertains now?

andymass commented 5 years ago

Thanks. I'm not sure yet where the problem is but that helps, I'll have to test shortly. The other thing to try is deferred matching, which uses different code paths. Might help narrow it down more.

oblitum commented 5 years ago

let g:matchup_matchparen_deferred = 1 also avoids the issue.

oblitum commented 5 years ago

Since let g:matchup_matchparen_deferred = 1 is a setting for better cursor stability, it sounds like an actual solution? It looks like I'll adopt it regardless.

andymass commented 5 years ago

Great, thanks! That provides two viable workarounds, however I'd like to keep this issue open so I get a chance to investigate where the problem is to possibly contribute back to neovim.

oblitum commented 5 years ago

Another coc.nvim conflict:

For some reason this happens only with vim (not neovim), and the ccls c++ language server. The presence of vim-matchup makes signatureHelp to fail (e.g. foo( gives no method signature). This is caused by let g:matchup_matchparen_deferred = 1, when disabling that this behavior stops.

oblitum commented 5 years ago

So, seems let g:matchup_matchparen_nomode = 'i' is the best workaround for all the issues reported here.

andymass commented 5 years ago

That's unfortunate. Do you mean when you type literal foo( in vim+coc.nvim+ccls specifically with deferred matching, no signature popups up? Is the occurrence of the ( is important here?

The next testing step would be to set g:matchup_matchparen_deferred_show_delay to something really large. I'm guessing when you type the ( the signature would popup then disappear as soon as match-up's timer comes back. If so my hunch is the two problems are mostly unrelated.

oblitum commented 5 years ago

@andymass yeah, ( causes the signatureHelp floating window to show up. And I indeed think here it's blinking. It showed up but vanished really fast, so it was mostly like it didn't show up at all.

andymass commented 4 years ago

There is also the option g:matchup_matchparen_pumvisible = 0 but whether it would work in these cases likely depends on the plugin's order of operations.

Do you offhand know if there's a way to detect when coc.nvim is displaying a pop-up window? I could just disable matching at that time.

oblitum commented 4 years ago

@andymass :h CocOpenFloat, which was introduced at https://github.com/neoclide/coc.nvim/issues/990.

oblitum commented 4 years ago

Although, I don't see a coc.nvim specific fix as a good solution, as floating windows is general feature that can be used by other plugins anytime.

andymass commented 4 years ago

Thanks, ok so I'd I understand correctly I would have to listen to that autocmd and if it's triggered disable matching temporarily? "Temporary one shot disable" is a generic enough feature.

oblitum commented 4 years ago

Also, the issue reported here may not involve floating windows, it's related only in the last issue mentioned, but the former report doesn't involve them.

oblitum commented 4 years ago

@andymass yes, but... it triggers just after the floating window is shown, so I'm not sure whether there can be a race, and that matchup will be able to disable itself before the window vanishes issue. And it would not help with original issue, just the latter, just with coc.

andymass commented 4 years ago

Unless there is an autocmd for when a snippet is expanded.

andymass commented 4 years ago

Oddly, I don't see CocOpenFloat getting triggered at all (coc.nvim version: 0.0.74).

oblitum commented 4 years ago

It's triggered on floating window only, not to confuse with vim completion popup. Not sure whether you may be hitting that. For me it triggers as I rely on it to implement what I asked on https://github.com/neoclide/coc.nvim/issues/990.

oblitum commented 4 years ago

Maybe just let g:matchup_matchparen_nomode = 'i' by default when coc.nvim is present is already a good enough solution? I don't think adding too much complexity trying to fix actually two issues is worth it.

andymass commented 4 years ago

Wait so is CocOpenFloat neovim only? I can't figure out any way to detect when a popup window is currently open in vim.

I'd prefer not to use 'g:matchup_matchparen_nomode' if there's no active popup because matching in insert mode is pretty important.

oblitum commented 4 years ago

Wait so is CocOpenFloat neovim only?

I never checked that Just recalled this, yes, it is. But:

Is there any way you can test this with vim instead of neovim? I wonder if this is a difference in the way CursorMoved is handled between vim/neovim, a bug in neovim maybe.

I just tested and in vim there's no issue, only in NeoVim.

andymass commented 4 years ago

There are two issues in this issue. I think I fixed the second one under mysterious circumstances. So g:matchup_matchparen_deferred=1 should work in both cases.

oblitum commented 4 years ago

@andymass Yes, that one got fixed ;)