First, you can't be sure that the LSP server returns all the fields or that it even support certain feature.

True, but then we don't know exactly what capabilities each ctags parser has, especially regex or peg ones and we seem to get along "ok".

You can't be sure if it contains signature or not - for instance, for C it contains void (gpointer) for a void function returning void and taking gpointer parameter, for Go it's something like func(bar int) string and one would have to implement a LSP-server-specific parser of these fields to get the true signature out of strings like that.

Well, they are signatures, how do you specify a C function, exactly like that void(gpointer), it is rarely used in C I admit, but its used in C++ more std::function<void(gpointer)> for example.

From my rather limited (10 mins) go knowledge func (bar int) string is the signature of a function that takes an int and returns a string. And when the programmer declared it they probably didn't even specify the string and it was inferred.

Probably our ctags based replication of the original declaration has preconditioned to seeing the function name in the signature, but maybe that has to change when returns or variable declarations are inferred.

Then the SymbolKind kind contains symbol kinds but these are different than the one Geany uses; moreover, depending on the LSP protocol version the server supports, it may contain only a subset of the values so may get different results with different versions of the same LSP server.

"Different" as in worse, better, or just ctags ones are more familiar? Anyway as above ctags parsers can also only support a subset.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.