@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.
### Jumping to the conclusion
> 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 Vscode[^1] 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 file[^2].
> 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 Vscode[^3]. 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:tm:"[^4] to Scintilla.
### A few specific points
> 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 :wink:.
> 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? :wink: 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](https://github.com/clangd/clangd/issues), its
nothing Geany can do, unless we can use the Vscode LSP instead, Vscode opens
that file just fine.
[^1]: 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 :stuck_out_tongue:.
[^2]: using user knowledge, or wire in chatGPT :grin:
[^3]: 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)
[^4]: see [Geany-lsp
discussion](https://github.com/techee/geany-lsp/issues/21#issue-1989722527) for
details :grin:
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3571#issuecomment-1817307198
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3571/[email protected]>
