Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@b4n, generally a well reasoned and fair assessment given its a first impression, it took me a while to get used to it, and I have been using Vscode for C++ for a while.
Not good without a proper project setup (expected I guess).
Yes its expected, LSPs are compilers (or interpreters in Pythons case, bless its little cotton socks), they need the compiler info, for C/C++ particularly the -I options. But thats a problem with the language and implementations, not the tool.
But clangd isn't restricted to the tree under the Geany project, so long as it can find compile_commands.json or build/compile_commands.json in the random files parent path it will work just fine. Modern build tools (well meson and cmake that I have tried) make that file by default, so yet another reason for autotools to die.
The issues if compile_commands.json cannot be found may be clangd, opening random C++ files in Vscode1 makes less of a mess of it than clangd. I think the main reason is it turns errors off if it can't find includes. Don't know if clangd can be configured like that or we would have to somehow decide the file is outside any known build and turn errors off in the LSP plugin, or let the plugin be turned off per file2.
Pretty good with it, but I had disappointments of how it plays in real life I didn't expect.
Concentrate on the "pretty good" with it, damn technical people (me included) have too much of a tendency to go for the minor annoyances/its different jugular. Also remember geany-lsp is in development, consider how to improve things and raise them there, not assume any current issue is permanent.
I have been using geany-lsp for C++ a while, and sure, it still has rough edges, but they can be polished. It is so much better than TM/ctags for C++ that I could be persuaded to use Geany again if it weren't for unrelated benefits of Vscode3. The improvement for C is likely to be less, it doesn't have inferred types, or overloaded names, or templates.
I'll have to actually try and use this for real things a bit to get a better impression at what it's actually good at.
One thing to bear in mind is that some things need to be used differently, see my previous explanations for details, but to summarise, "use the symbol in the code", not the sidebar. That way you get the benefit of clangd's knowledge of scope and visibility and inferred types and overloaded names etc.
And you should try it with C++ not C, maybe while adding the "Colomban inset™️"4 to Scintilla.
Without clangd installed
Probably the choice of LSP vs TM/ctags should be improved, at the moment its pretty much all or nothing, it needs to fallback to TM/ctags more effectively per language when the server isn't available, or when it can't handle missing information, and possibly by user choice as I said above.
For me, this means that it's not fit for general use (yet?) outside a proper project configuration
Indeed it may never be fit for that (at least with C/C++ where build info is needed), but thats clangd really not the plugin, just needs better control as above. And as I said, remember how much better it is when the project is done in a suitable way.
Very slow at start, but well, I'm waiting.
Yes, clangd has to index the whole project, thats the point, there is a note on geany-lsp to show the progress bar during it. But it is only first time. After that its incremental.
not being able to get completion for a function because it's not ordered right (e.g. only declared below in the file)
Simple, don't do that, you have no compiler checking ability. And surely its not allowed with --b4n-pedantic.
a tad annoying when refactoring things I imagine.
Refactoring support is in development IIUC. But yes, code has to compile for LSP to help, so turn on autoclose ()[]{} too, you will get used to it 😉.
the symbol trees after opening scintilla/gtk/ScintillaGTK*.cxx took very long to show up
Similar to the time it takes to compile that file maybe? 😉 IIUC clangd scans and indexes all files but only compiles files when queries need it (or they are a dependency of a file that is compiled).
it's of no use in ScintillaGTK.h because that header lacks a lot of includes. I don't support this style of programming, but the program itself is valid because that header is included properly… I get there is not much to be done here as standalone it's indeed invalid, and it could mean different things depending on what is included before, but Scintilla isn't the only project having "bad practices" like that.
Well discuss it with clangd, its nothing Geany can do, unless we can use the Vscode LSP instead, Vscode opens that file just fine.
if you can bear to read the geany-lsp repo comments you will see I use Vscode as reference, because I use it, and because it's LSP use has had lots more time to mature. But its still not perfect, so its unrealistic to expect Nirvana from an in-development tool 😛. ↩
using user knowledge, or wire in chatGPT 😁 ↩
proper working multiple windows/panes, see both the .hpp and the .cpp at the same time, or see two places in the same .cpp file (the class declaration and the member function implementation I'm writing) ↩
see Geany-lsp discussion for details 😁 ↩
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.