orbitalquark / textadept-lsp

Language server protocol client module for Textadept.
MIT License
28 stars 9 forks source link

Config flag to ignore `allCommitCharacters`? #17

Closed rodrigo-dc closed 9 months ago

rodrigo-dc commented 9 months ago

Hi, When using textadept-lsp/clangd in a C project, the autocomplete does not work as expected.

Let's say I want to create a comment //. I go to the beginning of a line and type /. ta1

The autocomplete will be triggered because / is part of triggerCharacters (sent by clangd). Not a big issue.

But when I try to type the second /, the following happens. image

The selected option is inserted because clangd includes / in the allCommitCharacters list.

I know this looks like a problem in clangd.

If you think that creating a flag to ignore allCommitCharacters is the way to go, I can submit a patch. The flag could be tested here or here.

By the way, thanks for the amazing job on the editor and plugins.

This is my environment: Ubuntu 22.04 textadept 12.2 textadept-lsp 12.2 (modules package) clangd 14.0.0

orbitalquark commented 9 months ago

It is indeed a clangd issue. I have the exact same environment as you and am using the following in my ~/.textadept/init.lua as a workaround until Ubuntu gets a new clangd:

local lsp = require('lsp')
lsp.server_commands.ansi_c = 'clangd'
lsp.server_commands.cpp = 'clangd'
events.connect(events.LSP_INITIALIZED, function(lang, server)
    if lang == 'ansi_c' or lang == 'cpp' then
        server.auto_c_triggers[string.byte('/')] = false
        server.auto_c_fill_ups = '' -- removed upstream
    end
end)

Since allCommitCharacters is part of the LSP specification, I am reluctant to maintain a flag to switch it on or off just because a server is buggy or misconfigured. At the same time, I do realize that it's quite difficult to get up-to-date version of some servers when an issue like this is fixed.

Regardless, this undocumented workaround is sufficient for the time being. Hopefully Ubuntu 24.04 will fix this issue for us in 3 months :)

rodrigo-dc commented 9 months ago

Right, it's already fixed in clangd 15.0.0. Then it doesn't make sense to create a flag here. I'm happy with the workaround for now. Thank you!