Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
My biggest disappointment was the lack of good servers or at least servers not being worked on by a single guy. I expected to be able to use some vscode servers but this isn't possible.
Servers are going to be best when they are supported by the language community like gopls. AFAIK newer languages like Rust, Julia etc provide them and generally try to keep them in sync with the language, but they may require a lot of the language infrastructure, eg rust analyser needs the whole standard library source IIUC, maybe that will change over time.
It should be possible to use the same servers as vscode, except the MS ones that use proprietary code, IIUC cpptools-srv is MIT but it isn't a compiler and uses MS stuff from Visual Studio that is proprietary and only licensed for vscode use. Also there can be intelligence in the client since each language in vscode has its own plugin that talks to the server. So a generic client may not work as well with any specific server.
We were already talking with @elextr that there should be a config option to disable LSP for files outside the project directory.
Yeah, clangd works if it can find the info it needs, but it should be possible for the user to turn LSP off for the file if they feel that it isn't helping. Again new languages with built in build systems (like go, rust/crate) should also work if they can navigate from a file to the build information they have stored for the "project" the file appears in, but I have no idea if they do.
So my preferred hierarchy is per language to automatically use TM if the server isn't running, per language settings for "LSP off" (just comment out the section in the conf file?), "in tree only"1, and a UI available per file setting to switch LSP or TM, save that in the project for open files.
Just a small note - we are all, me including, a bit influenced by how clangd works but other servers may work differently. LSP is just the protocol and how exactly the server implements it is up to the server. So there may be a full parser behind it, but there may also be a set of simple regular expressions. Or the whole server may be just a code formatter and not to implement any other functionality.
Indeed, and it is why TM/ctags could be packaged as an LSP, and why (as I said above) more configurability is needed to switch individual files/projects/other to/from LSP.
"in tree" isn't necessarily the best, "in project including imported local modules" would be better, but "in tree" is easy to define and implement independent of language peculiarities. ↩
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.