Incorrect ranges from coc-funcobj-a/i

glandir commented 4 years ago

Result from CocInfo

## versions

vim version: NVIM v0.4.3
node version: v13.13.0
coc.nvim version: 0.0.78-fc983ce6dd
term: rxvt-unicode-256color
platform: linux

## Output channel: clangd log

I[05:03:40.186] clangd version 10.0.0 
I[05:03:40.186] PID: 274389
I[05:03:40.186] Working directory: /tmp/coc-test
I[05:03:40.186] argv[0]: /usr/bin/clangd
I[05:03:40.186] Starting LSP over stdin/stdout
I[05:03:40.187] <-- initialize(0)
I[05:03:40.187] --> reply:initialize(0) 0 ms
I[05:03:40.190] <-- initialized
I[05:03:40.190] unhandled notification initialized
I[05:03:40.191] <-- textDocument/didOpen
I[05:03:40.191] Failed to find compilation database for /tmp/coc-test/main.cpp
I[05:03:40.191] --> textDocument/clangd.fileStatus
I[05:03:40.191] Updating file /tmp/coc-test/main.cpp with command clangd fallback
[/tmp/coc-test]
/usr/bin/clang /tmp/coc-test/main.cpp -fsyntax-only -resource-dir=/usr/lib/clang/10.0.0
I[05:03:40.201] --> textDocument/publishDiagnostics
I[05:03:40.201] --> textDocument/clangd.fileStatus
I[05:03:42.004] <-- textDocument/documentSymbol(1)
I[05:03:42.004] --> reply:textDocument/documentSymbol(1) 0 ms
I[05:03:42.004] --> textDocument/clangd.fileStatus

Describe the bug

The text objects coc-funcobj-a and coc-funcobj-i give incorrect ranges for some language servers. I observed this with coc-clangd and coc-rls.

For the coc-funcobj-i text object, this code just takes the range for the complete function and removes the first and last line, which doesn't work for function signatures spanning multiple lines: https://github.com/neoclide/coc.nvim/blob/d6dd56bba8992aae3ade4034f1bc8d1148c3780f/src/handler/index.ts#L817-L822 It's probably not possible to do this more accurately without LSP support, but some documentation about it would be helpful. I was initially unsure whether this was an issue with coc or with clangd.

I have no idea why coc-funcobj-a doesn't work, though. Reading the code, it seems to just use the range reported by the server, but the end position is always one line too high.

Reproduce the bug

Create file mini.vim with:

set nocompatible
set runtimepath^=/path/to/coc.nvim
filetype plugin indent on
syntax on
set hidden
xmap if <Plug>(coc-funcobj-i)
omap if <Plug>(coc-funcobj-i)
xmap af <Plug>(coc-funcobj-a)
omap af <Plug>(coc-funcobj-a)

Create file main.cpp with:

void f()
{
// body (1)
}
auto g()
-> void
{
// body (2)
}

Start (neo)vim with command: nvim -u mini.vim main.cpp
With the cursor on (1), hit vaf. The selection spans from the beginning of the first line until the first slash; we would expect the selection to end one line later.
With the cursor on (1), hit vif. The selection spans from the brace in the second line until the first slash on line 3.
With the cursor on (2), hit vif. This time the selection includes the return type (-> void) and the entire line before the closing brace.

Screenshots (optional)

coc-test coc-test2

chemzqm commented 4 years ago

It simply return firstline -1 for inner function, PR welcome.

ferdinandyb commented 3 years ago

I have a similar issue with pyright, also done with a similar mini vimrc:

pressing vaf here results in the following:

and vifin this:

I'm not sure if it is related or not.

cr4ftx commented 3 years ago

Same problem for coc-classobj-i and coc-classobj-a

fannheyward commented 3 years ago

@ferdinandyb Pyright has fixed this, https://github.com/microsoft/pylance-release/issues/1014

ferdinandyb commented 3 years ago

I'll check soonish, thanks for the heads-up!

fannheyward commented 3 years ago

@ferdinandyb the fixes has not been released yet.

fannheyward commented 3 years ago

For clangd issue, I think it's hard to solve in coc. coc just returns start.line - 1 for inner function, but if the code is not well formatted, coc doesn't know how to handle it.

void f() {
    // body (1)
}

vif on (1) on works as expected.

neoclide / coc.nvim