Use returned symbol types from LSP

[elextr]

Can you patch in showing the symbol type in the sidebar instead of just the symbol name as we discussed somewhere I now can't find. It would be good to see what it actually shows and if, as I suggested as a possibility, inferred information is included where "languages that are not C" allow it.

Edit: I read your last answer to Kugel after making this, so take it as "Yes please" :-)

[techee]

Can you patch in showing the symbol type in the sidebar instead of just the symbol name as we discussed somewhere I now can't find. It would be good to see what it actually shows and if, as I suggested as a possibility, inferred information is included where "languages that are not C" allow it.

It should more or less be shown in the tooltip, isn't it? This is the detail returned by LSP which is specific server to server and hard to parse in a generic way as mentioned in the LSP API thread. For C it's something like e.g. void (int, gchar *), i.e., the function returns void and has (int, gchar *) arguments. But LSP doesn't return type or the signature separately - one would have to parse this string and it is specific language to language.

Edit: I read your last answer to Kugel after making this, so take it as "Yes please" :-)

Really, I have no problem when someone asks me to do something and I don't need (and in fact, don't want) "please"'s everywhere. I just dislike shitty argumentation where someone insists on one way of doing things not taking into account other people's arguments, not really knowing what he's talking about despite claiming so (so one has to constantly explain it), inventing some artificial reasons and finally stopping to respond or rejecting people's PRs. It's just not fun, time consuming to respond, mentally exhausting, and completely unnecessary IMO.

Bug reports like "do something" are completely fine - I just can't guarantee I'll do that :-).

[elextr]

It should more or less be shown in the tooltip, isn't it?

Yep thats the idea, where the "signature" from ctags used to be shown.

This is the detail returned by LSP which is specific server to server and hard to parse in a generic way as mentioned in the LSP API thread.

Not sure what you need to parse it for, anyway the point of this (and the please) is that its an experiment to see what string we get and might not be worth keeping, but without being able to see it, its hard to tell.

[elextr]

Not sure what you need to parse it for, anyway the point of this (and the please) is that its an experiment to see what string we get and might not be worth keeping, but without being able to see it, its hard to tell.

Just to expand, we had a conversation before where you said you had dismissed showing the details returned by the LSP servers, and you quoted two examples, one C and one Go which seemed to me to be perfectly good function types, so that made me unsure that dismissing showing them is the best thing. So all I am asking at this point is for the details to be made visible, not parsed or modified, just the return from the server be visible if the server provides it. That way it can be evaluated against a range of cases to decide if/how to use the information.

[techee]

It should more or less be shown in the tooltip, isn't it?

Yep thats the idea, where the "signature" from ctags used to be shown.

Oh, but you don't see them? Because they show on my machine.

[techee]

Couldn't it be a clangd version problem? Mine is

Debian clangd version 14.0.6

When you enable rpc_log to some file in the config file, you can check if the detail field is present in the responses. It's optional so it's possible it wasn't implemented in older clangd versions.

[elextr]

Ok, I downloaded the clangd 16.0.2 zipfile, now I see them.

A quick comparison for the line auto it = foo.begin(); where std::vector<Foo> foo;

Geany 2.0: Symbol pane shows it[12], symbol tooltip auto it, tooltip on the source nothing Geany-lsp: Symbol pane shows it[12], symbol tooltip iterator, tooltip on the source nothing Vscode: Symbol pane shows it, tooltip it (variable), tooltip on the source std::vector<Foo>::iterator

So the Geany 2.0 symbol tooltip is pretty useless, the Geany-lsp one is accurate (but not very detailed) and Vscode has put all the information on the tooltip from hovering on the name in the code. The Vscode approach makes sense, by selecting a particular usage of the name the visibility and scope can be taken into account, and because overloading needs parameters.

Anyway I am gonna try and sleep now (too much coffee at dinner) and will try some more tomorrow ... erm later today.

Edit: while turning off rpc-log I noticed the hover-enable setting, now I get a small war and peace about the symbol on hover in the source. Will explore more later.

[techee]

Anyway I am gonna try and sleep now (too much coffee at dinner) and will try some more tomorrow ... erm later today.

Sweet dreams about various clangd versions and document symbols :-).