"magic" completions not working

[oblitum]

Result from CocInfo

versions

vim version: NVIM v0.4.0-1198-g0dc73b87f
node version: v11.15.0
coc.nvim version: 0.0.72
term: tmux-256color
platform: linux

Messages

Output channel: watchman

[Info - 5:50:17 AM] watchman watching project: /home/francisco/Projects/samples/rust
[Info - 5:50:17 AM] subscribing "/.eslintr{c.js,c.yaml,c.yml,c,c.json}" in /home/francisco/Projects/samples/rust
[Info - 5:50:17 AM] subscribing "/.eslintignore" in /home/francisco/Projects/samples/rust
[Info - 5:50:17 AM] subscribing "/package.json" in /home/francisco/Projects/samples/rust
[Info - 5:50:17 AM] subscribing "/{.prettierrc,.prettierrc.json,.prettierrc.yaml,.prettierrc.yml,.prettierrc.js,package.json,prettier.config.js}" in /home/francisco/Projects/samples/rust

Output channel: snippets

[Info - 5:50:17 AM] watchman watching project: /home/francisco/.config/coc/ultisnips
[Info - 5:50:17 AM] subscribing "**/*.snippets" in /home/francisco/.config/coc/ultisnips

Output channel: prettier

Describe the bug

I just came to learn of "magic" completions supported by rust-analyzer that don't work with coc.nvim, but works on VSCode. What they are is explained here and how they should behave can be viewed in this video.

Reproduce the bug

• Follow the wiki to install rust-analyzer

• Create file mini.vim with：

  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 '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 (neo)vim with command: nvim -u mini.vim src/main.rs

• in main type x.if and expand the suggestion

[chemzqm]

Please provide output so I could understand how it works.

[oblitum]

I've linked video and explanation in "Describe the bug". For example, x.if<confirm> should expand to if x {<cursor here>}, but coc doesn't do that, like it's shown in the video in VSCode, it expands by appending the expansion after x., so it becomes x.if x {<cursor here>}, like normal completion.

[chemzqm]

Looks like that feature use custom command which requires extension support to work.

[oblitum]

OK. If you conclude that's the case you can close the issue as I don't have the inner knowledge whether it should be part of coc or not.

[oblitum]

Current behavior is bad though, since coc provides a behavior for these snippets, but it provides incorrect expansions. It would be ideal if they weren't at all provided, or provided but working.

[chemzqm]

The language server should provide an option to disable feature, or check if it can be done with the client.

[oblitum]

OK. I'll report it back there.

[matklad]

@chemzqm that’s not a custom command, that is snippet completion (see insertTextFormt in https://microsoft.github.io/language-server-protocol/specification#textDocument_completion).

It’s true that the server should only send snippets if the client explicitly advertised support for them, but it should also be cool if coc.nvim supported snippets, they are a powerful feature! Though, IIRC, all vim plugins have trouble with non-trivial completions, so this might be a won’t fix due to some vim internal limitation.

[chemzqm]

coc.nvim has full support for snippet of LSP, need verbose output from language server to understand why it's not work as expected.

[matklad]

If this is helpful, here are the logs I get from VS Code:

https://gist.github.com/matklad/d12ae81f18766c80f56727f2d848fc0a

A specific CompletionItem looks like this:

{
        "additionalTextEdits": [
            {
                "newText": "",
                "range": {
                    "end": { "character": 7, "line": 1 },
                    "start": { "character": 4, "line": 1 }
                }
            }
        ],
        "detail": "match expr {}",
        "filterText": "match",
        "insertTextFormat": 2,
        "label": "match",
        "textEdit": {
            "newText": "match 92 {\n    ${1:_} => {$0\\},\n}",
            "range": {
                "end": { "character": 10, "line": 1 },
                "start": { "character": 7, "line": 1 }
            }
        }
}

[oblitum]

This is the full output from coc.nvim.

[chemzqm]

Should be bug of overlap range check for additionalTextEdits and textEdit

[oblitum]

OK looks fixed on b24601e, thx :)

[oblitum]

Just noticed that some expansions are not putting the cursor in the right place, for example, x.match expands snippets and puts the cursor correctly in the middle of the expression, but x.if expansion is not doing that, it's putting the cursor after the expression, not inside the if's body (if x {} <cursor here> but if x {<it should be here>}), x.while puts cursor in valid location but lacking indentation, x.box expands with extra ending whitespace. Behavior is varying widely.

[chemzqm]

Position need fix for plain text snippet https://github.com/neoclide/coc.nvim/blob/master/src/languages.ts#L609

[chemzqm]

Fixed

[oblitum]

@chemzqm behavior is still the same for me, though I ignore whether positions are in fact correct coming from rust-analyzer snippets when using VS Code (cc @matklad):

[oblitum]

I suspect repositioning is wrong when the snippet is single line, and text edits that remove text while expanding, happens on that line. Maybe that's why x.match expansion position is correct, but x.if and x.box are not, it gets lost positioning on the line where text is removed and added.

[oblitum]

Reopening as it doesn't seem fixed.

[chemzqm]

Please paste output from language server.

[oblitum]

@chemzqm my bad, it's expanding correctly in minimal .vimrc, there should be now some bad interaction with another plugin. I'll check which one is this.

[oblitum]

The plugin conflicting with coc.nvim expansion is vim-matchup. For some reason having it cause bad expansion like in the gif above.