clktmr / vim-gdscript3

Syntax highlighting and completion for GDScript 3
MIT License
13 stars 3 forks source link

Support for vim-lsp #7

Closed Rubonnek closed 4 years ago

Rubonnek commented 4 years ago

Vim-lsp is an Async Language Server Protocol plugin for vim8 and neovim

clktmr commented 4 years ago

I'm using vim-lsp myself. I couldn't get it work with the Godot Language Server because vim-lsp only supports communication over stdin/stdout, while Godot only provides TCP based communication. I thought of using socat to pipe the TCP connection to stdin/stdout, but haven't tried yet. If someone gets this to work, I would be interested in this too.

Rubonnek commented 4 years ago

Hmm... yeah, we should be able to connect with some like:

if executable('godot_server')
    augroup lsp_godot
        autocmd!
        autocmd User lsp_setup call lsp#register_server({
                    \ 'name': 'godot_server',
                    \ 'cmd': {server_info->['nc', '127.0.0.1', '6008']},
                    \ 'whitelist': ['gd'],
                    \ 'initialization_options': {
                    \   'vimruntime': $VIMRUNTIME,
                    \   'runtimepath': &rtp,
                    \ }})
    augroup end
    autocmd FileType gd setlocal omnifunc=lsp#complete
endif

But I don't see any packet going through the loopback device nor any connection "taken" shown in the editor. I'm gonna ask around and see what's up with that.

Rubonnek commented 4 years ago

Welp, nevermind. I got it to work:

if executable('godot_server')
    augroup lsp_godot
        autocmd!
        autocmd User lsp_setup call lsp#register_server({
                    \ 'name': 'godot_server',
                    \ 'cmd': {server_info->['nc', '127.0.0.1', '6008']},
                    \ 'whitelist': ['gd', 'gdscript3'],
                    \ })
    augroup end
endif

Thank you so much for supporting vim!

I also packaged this repo for Arch Linux: https://aur.archlinux.org/packages/vim-gdscript-git/

Rubonnek commented 4 years ago

Forgot to mention, you have to merge a couple of commits and rebuild the engine to connect to the LSP server with netcat:

git checkout 3.2 #inside the godot repository
for i in 24b27043fec7ef9a4baf2c5ecab67fc20563b586 ed482f6167276bebd4132b82a6683392ac41f97a 06bce137e38ecf0e3c024ddff8356c8cfd9c4d5b 2f08f4ef4e6f7112c1c06f9f6b6f7e782e66adaf; do
    git cherry-pick $i --strategy-option theirs
done

This bit of shell script was taken from here

clktmr commented 4 years ago

I just tried this and it works for me, thanks! But vim will often be unresponsive for seconds when the pum is loading. I suspect this is because netcat/socat are blocking on stdin? Because completion is actually supposed to be async. Did you experience similar?

Rubonnek commented 4 years ago

I did experience that.

I looked a bit into this and I don't think netcat nor socat are blocking on stdin/stdout -- otherwise I would expect to see the same issues with clangd blocking them on much bigger codebases.

Godot's LSP server just spits out a ton of information instead.

Try this before you register godot as an LSP server:

let g:lsp_diagnostics_enabled=0
let g:lsp_log_file = $HOME . "/lsp_log.txt"

Have vim become unresponsive a few times and take a look at the size of the log -- I just tried it for a sec and my log is about 3 MBs which is insane since I only tried to auto complete InputMap a couple of times.

Even one of the responses I got from the LSP server was at around 804000 characters long with a ton of information I didn't need for completing the InputMap string.

I suppose vim-lsp is just processing all that data on the background and since it's so much it still affects vim somehow.

I think our solutions are either to cache all the auto completion data somehow and refresh it later on the background (which is clunky), or attempt to optimize the LSP server somehow.