builtin functions aren't completed if a part of it is already typed

[nycex]

As I already said in discord, I added zls as lsp and it get's called but I have neither completion for builtin functions nor for global variables. This might just as well be a misconfiguration on my side, but it could also be a zls bug. Here is my full vim config, and those are the significant parts:

let lsp_filetypes = [ 'rust', 'zig', 'c', 'cpp', 'go', 'java', 'kotlin', 'sh', 'zsh', 'vim', 'javascript', 'typescript', 'python' ]

Plug 'dense-analysis/ale', { 'for': lsp_filetypes }
Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins', 'for': lsp_filetypes }

let g:ale_linters = {
			\ 'rust': ['analyzer', 'clippy', 'rustfmt'],
			\ 'zig': ['zls'],
			\ 'python': ['pyls'],
			\ 'go': ['gopls'],
			\ 'javascript': ['tsserver', 'flow', 'eslint'],
			\ 'typescript': ['tsserver', 'eslint'],
			\ }

function! GetCommand(buffer) abort
	return '%e'
endfunction

function! GetZigProjectRoot(buffer) abort
	let l:cargo_file = ale#path#FindNearestFile(a:buffer, 'build.zig')

	return !empty(l:cargo_file) ? fnamemodify(l:cargo_file, ':h') : getcwd()
endfunction

call ale#linter#Define('zig', {
			\   'name': 'zls',
			\   'lsp': 'stdio',
			\   'executable': '/usr/bin/zls',
			\   'command': function('GetCommand'),
			\   'project_root': function('GetZigProjectRoot'),
			\})

[SuperAuguste]

Hey nycex, in all honesty, I have never used Vim before. I don't see any apparent problems in your config, but again, I don't really use ale and deoplete. Could you somehow output an error log and check for any Vim runtime errors?

[nycex]

I don't have any runtime errors, but I can say that errors (zig syntax errors e.g.) in the file are shown, just the completion doesn't work for me. I'll look into ale and deoplete, maybe there is a mode that shows some debug info.

[nycex]

So I tried a few things and wasn't able to get any debug output that has something to do with zls besides the execution of zls itself. When trying with latest master though, I was able to get global variable and function completion, though builtins still don't work.

[alexnask]

Weird, the builtin completion code sends the same kind of message as the global function completion code.

[SuperAuguste]

Weird, the builtin completion code sends the same kind of message as the global function completion code.

That's correct - both send a completion event, they just have different content.

[SuperAuguste]

Maybe it's due to lack of snippet syntax support in ale/deoplete?

[SuperAuguste]

This seems to indeed be the issue: dense-analysis/ale#1821. This seems to be a problem with ale itself. It seems that other language servers like elixir-ls have the same issue as us with ale snippet support being blocking.

[nycex]

Yeah, that seems to be the case. I'll close this then.

[SuperAuguste]

Very sorry about that @nycex! I'm gonna add a build option to disable snippets and render the plain versions of the builtins later, so you'll be able to use the language server. 😊

[nycex]

You don't have to be sorry, it makes sense to add this as a snippet feature; it's not your fault my client doesn't support that 🙂. It'd be great if you could add it, as you already said, though 👍.

[SuperAuguste]

Nycex, you can now zig build -Dno_snippets to enable no_snippets mode, which as its name indicates, disables all snippets! Thanks for bringing this issue to our attention! This should fix everything, and if it doesn't please, please reopen this issue!

[nycex]

It still doesn't work, though that might have to do with the @ in front of the completion, deoplete seems to split that, e.g. typing @s gives me a completion list with std in it. Maybe this behaviour is changable, I'll look into it.

Edit: this doesn't seem to be the problem, changing @breakpoint() to breakpoint() in the data files doesn't solve the issue.

[alexnask]

Edit: this doesn't seem to be the problem, changing @breakpoint() to breakpoint() in the data files doesn't solve the issue.

The server still only sends the completion if the current character is '@' so I wouldn't expect simply changing the builtin name would fix this if the issue is deoplete's handling of '@'.

Anyway, I will try to test this in some other LSP clients to see if this is a common issue or just deoplete's, I believe @SuperAuguste uses vscode like me so we should test on more clients anyway.

[nycex]

If it helps, here I have the output and input of zls I can intercept when trying it first with a global function in the file and then with builtin functions: https://bpaste.net/DAOA (the first one is input, the second one output)

[nycex]

I'm pretty sure it is a problem with the main.zig:413 check, because if I add or true to it, it works, but now only builtin functions work and they are also getting completed if no @ is in front of them (which is obvious of course). I'm not entirely sure if this is a zls problem or a problem with the way deoplete handles those separators.

Edit: After further investigation it seems to be deoplete's fault, because when I add or document.text[pos_index-1] == '@', it actually works, when I type @b<Tab> e.g.. It seems like deoplete doesn't complete deoplete-source (here: ale) specific completion when it is after such a separator.

Edit2: I think char == '@' might not be the best check here, since the completion should also work when you already typed part of the builtin function's name. (this might get fixed by the analysis engine?)

[SuperAuguste]

Yep! This will def. be fixed by the analysis engine! char == '@' is a superhacky placeholder. If you just type @ and then press tab, it should work with the current setup.

[nycex]

I know, but for some reason deoplete expects at least one character after an @ to do completion. I guess I'll leave this open until the analysis is done as far as fixing this?

[SuperAuguste]

Fixed! It should work now nycex!

[nycex]

It does work now! 👍
Also with snippets enabled though - so I don't know if you want to keep the ability to disable them in 🤷.