Interesting observation

[elextr]

I had a C++ non-GTK LSP project not connected to any Geany tree open and LSP running.

I opened document.c from a Geany tree that was built with meson (ie had a build/compile_commands.json) and all the GTK and most library types were not recognised, the same as when I opened document.c from a Geany tree built by autotools (no build dir).

But when I also opened document.h from the meson tree all the GTK and STL types were then styled in that trees document.c, but not in the autotools tree document.c, and that did not change when I opened the autotools trees document.h`.

Since the compile_commands.json of the open project does not tell where to find GTK symbols and clangd cannot find them for the files in the autotools tree it seems like clangd may search up the tree for build/compile_commands.json and finds the one in the meson tree that tells it where to find GTK symbols.

Is that documented, or is there another explanation?

[elextr]

Tried again today and as soon as I opened Meson tree document.c it was styled, no need to open the .h. I did some searching and found a build/.cache/clangd directory in that tree. So clearly clangd found that directory :-). Maybe the opening document.h previously was irrelevant, it just caused enough delays that clangd had scanned the build and all I had needed to do was to have patience (which I don't).

[techee]

I've just created #11.

Maybe the opening document.h previously was irrelevant, it just caused enough delays that clangd had scanned the build and all I had needed to do was to have patience (which I don't).

I don't think it's the delay itself, I think it was the switch back to document.c that re-requested symbols for the sidebar and semantic tokens (these are only re-requested when you start typing). After implementing #11, these could be re-requested for the current document automatically after receiving the cancel notification for the progress from the server.

I also tested the plugin on Raspberry Pi and the initial indexing takes really long there so seeing some progress would be really useful. After that, normal editing is pretty responsive. Only semantic token requests seem to cause quite long delays on the server, and, interestingly, also block the GUI in Geany. The only reason why this happens that I can imagine is that clangd creates some lock that avoids sending RPC messages and Geany blocks in the write().

Seems more like clangd problem but could be also something in jsonrpc-glib which is based on gio which behaves in a slightly unexpected way, at least for me:

https://gitlab.gnome.org/GNOME/jsonrpc-glib/-/issues/8

[elextr]

re-requested symbols for the sidebar and semantic tokens (these are only re-requested when you start typing).

Ok, yeah if the user is just reading the newly opened file they want the styling to get corrected in a reasonable time without typing.

seeing some progress would be really useful.

Especially if its going to go index the whole tree every time a file is opened in a new tree that has a build/compile_commands.json but no build/.cache/clangd/indexxxxxxx. What if its the kernel, or chromium you opened a file in on that Rpi ;-P

[techee]

Done. It shows "indexing", number of files indexed and progress bar in the status bar. Not sure if I should be proud of myself - I've just introduced something that was the reason why I switched to Geany from Eclipse...

[techee]

What if its the kernel, or chromium you opened a file in on that Rpi ;-P

People doing that already know they have to start such tasks before going on holiday :-).

[elextr]

Anyway, what it shows is that clangd will search, as its docs say "clangd will look in the parent directories of the files you edit looking for it, and also in subdirectories named build/" so the restriction that the build directory has to be directly below the project base is not needed.

[techee]

Or using the config file:

https://clangd.llvm.org/config#compilationdatabase

[techee]

I opened document.c from a Geany tree that was built with meson (ie had a build/compile_commands.json) and all the GTK and most library types were not recognised, the same as when I opened document.c from a Geany tree built by autotools (no build dir).

I'm thinking about adding some config file option to disable LSP when opening files outside the project directory, what do you think? I think it could be useful because for directories without any compile_commands.json (and this is really specific to clangd, other languages might not have any such file, only the base path), the LSP server will just display many errors in the file and won't be able to parse it properly. So for files outside the project directory normal TM parsing would happen with this config option.

[elextr]

what do you think?

Noooooooooooooooooooooooooooooooooooooooooooo, my loverly features!!!!!!!!!!!!!!!!!!!!!!!!! 😭

As you said its clangd specific, I think other languages have learnt from the C/C++ build debacle and have there own ways of building stuff (crate for rust for eg).

And yes, if a file without compile_commands.json in its ancestors is opened with clangd operating then there are heaps of errors, but open a file with compile_commands.json and it works so much better I would hate to lose it. I think a lot of users commonly open files outside the "project" like looking at files from two versions of Geany.

Is it possible to determine on a file by file basis rather than just reject all outside the project directory?

Edit: or maybe just turn off errors for those files, the parsing seems not to be worse than ctags (at one quick glance anyway).

[techee]

Noooooooooooooooooooooooooooooooooooooooooooo, my loverly features!!!!!!!!!!!!!!!!!!!!!!!!! 😭

Fear not, the keyword here is "configurable" :-). That is, in the config file you'd have a config option like use_lsp_outside_project_dir you could enable or disable based on your preferences. Since it's possible to have the config file on a per-project basis, it would even be possible to have it enabled for some projects and disabled for others.

As you said its clangd specific, I think other languages have learnt from the C/C++ build debacle and have there own ways of building stuff (crate for rust for eg).

But this is the problem. While clangd will work because it will find compile_commands.json for the other project, other languages like go have no such file and will have absolutely no information about what the root directory of the other project is because it's set to the current project. So here to avoid seeing many errors, I thought this config option might be useful.

[elextr]

Configurable is good :-)

And I think the clnagd config can exclude directories from indexing too, havn't investigated in detail yet though.

For go we really need a gopher (no not a gofer, although one of those would be nice too ;-) but my quick reading is that its equivalent of compile_commands.json is a go.mod file that is maintained by the go command, IIUC the whole build and dependencies thing is built-in to the language.

[techee]

For go we really need a gopher (no not a gofer, although one of those would be nice too ;-)

One go gopher lives here, I got him at one go conference:

So we are ready for everything.

but my quick reading is that its equivalent of compile_commands.json is a go.mod file that is maintained by the go command, IIUC the whole build and dependencies thing is built-in to the language.

Yes, but clangd is just nice to you. Despite the fact that the project was configured with a different base path during the initialize request, it finds compile_commands.json from the other project and works. gopls doesn't do anything like that - externally opened files are parsed with errors.