Bug fix in omnifunc

[girishji]

1. LspOmniFunc() causes inserted text (when selecting from a popup) to
   appear in the wrong column. This happens only when using this
   function separately (through complete() function) in combination
   with other completion functions. When findstart=1, this function
   returns column width of 1 for tab (if tabstop is set to 8), instead
   of 8. To fix the problem I replaced use of charcol() with
   col(). :h complete-functions recommends using col().
   Normal users of omnifunc () should not notice any
   difference.

2. Added a function to check if omnifunc is waiting for LSP response.
   This is helpful for writing adapters for external completion
   plugins out there.

Since LspOmniFunc() works correctly when used with
this PR is not essential. I leave it to the discretion of Yegappan to
decide whether to include or not.

I use this omnifunc in conjunction with other omnifunc's. I call
them first with findstart=1 and then again with findstart=0, then
combine the returned items and show them using complete().
I use them in async manner. The advantage of this change is that
now you can adapt this LSP to any external completion plugin
using few lines of stub code.

Here is how the bug shifts popup window (and inserts in wrong column):

M autoload/lsp/completion.vim

[yegappan]

Thanks for the patch. Do you have a minimal script that reproduces this issue? Are you referring to the popup window showing up in column 1 instead of column 8 in your picture?

Note that the completion function should return a column number (byte index) and not a virtual column number. So a tab character is counted as one byte and the index will be 1 for a tab character.

[yegappan]

Can you update the doc with a description and use of this function?

[girishji]

Thanks for the patch. Do you have a minimal script that reproduces this issue? Are you referring to the popup window showing up in column 1 instead of column 8 in your picture?

Note that the completion function should return a column number (byte index) and not a virtual column number. So a tab character is counted as one byte and the index will be 1 for a tab character.

I made a mistake. I did not realize that startcol argument of complete() and column number returned by calling LspOmniFunc(1, '') differ by 1. When calling complete() you have to add +1 to the output of omnifunc to get the popup and inserted text aligned correctly. Initially I did not add +1 and it lead to some confusion (this PR is unnecessary). Here is the minimal script I used to debug this problem.

vim9script
setbufvar(bufnr(), '&completeopt', 'menuone,popup,noinsert,noselect')
setbufvar(bufnr(), '&completepopup', 'width:80,highlight:Pmenu,align:item')

def Completor()
    var startcol = g:LspOmniFunc(1, '') + 1 # +1 is important
    if startcol < 0
	return
    endif
    var line = getline('.')->strpart(0, col('.') - 1)
    var base = line->slice(startcol - 1)
    var items = g:LspOmniFunc(0, base)
    if !items->empty()
	items->complete(startcol)
    endif
enddef
autocmd TextChangedI <buffer> call Completor()

Turn off the autocomplete in .vimrc:

autocmd VimEnter * call LspOptionsSet({ autoComplete: false })

GIven what I discovered, there is no need to make changes to g:LspOmniFunc(). It is still nice to add g:LspOmniCompletePending() to know the waiting state of LSP. Maybe I should submit a new PR.

[yegappan]

For optimization reasons, it makes sense to include your changes. The current code does a regular expression comparison for each character. With your change, only a single regular expression comparison will be used. Can you reopen the PR?

[girishji]

I cannot reopen this PR. The button is grayed out. Maybe because I deleted the branch. But I will submit a new PR with same changes.

[mfbayraktar]

you could push the branch to the server than try to reopen it