techee / geany-lsp Goto Github PK

I got a bit lazy and didn't take these into account and only use what's enabled/disabled in the config file. So for instance, when autocompletion is enabled in the config file but the server doesn't support it, autocompletion will not work - instead, it should fall back to the TM implementation.

Since the defaults will be enabled for most options, users would have to manually disable the features the given server doesn't support to get the TM fallback which isn't very user-friendly.

Example of such a initialize response from the server is for instance something like below. Currently only some of them are parsed and used, such as commit characters or text document sync kind.

{
  "capabilities" : {
    "astProvider" : true,
    "callHierarchyProvider" : true,
    "clangdInlayHintsProvider" : true,
    "codeActionProvider" : true,
    "compilationDatabase" : {
      "automaticReload" : true
    },
    "completionProvider" : {
      "allCommitCharacters" : [
        " ",
        "\t",
        "(",
        ")",
        "[",
        "]",
        "{",
        "}",
        "<",
        ">",
        ":",
        ";",
        ",",
        "+",
        "-",
        "/",
        "*",
        "%",
        "^",
        "&",
        "#",
        "?",
        ".",
        "=",
        "\"",
        "'",
        "|"
      ],
      "resolveProvider" : false,
      "triggerCharacters" : [
        ".",
        "<",
        ">",
        ":",
        "\"",
        "/",
        "*"
      ]
    },
    "declarationProvider" : true,
    "definitionProvider" : true,
    "documentFormattingProvider" : true,
    "documentHighlightProvider" : true,
    "documentLinkProvider" : {
      "resolveProvider" : false
    },
    "documentOnTypeFormattingProvider" : {
      "firstTriggerCharacter" : "\n",
      "moreTriggerCharacter" : []
    },
    "documentRangeFormattingProvider" : true,
    "documentSymbolProvider" : true,
    "executeCommandProvider" : {
      "commands" : [
        "clangd.applyFix",
        "clangd.applyTweak"
      ]
    },
    "hoverProvider" : true,
    "implementationProvider" : true,
    "memoryUsageProvider" : true,
    "referencesProvider" : true,
    "renameProvider" : true,
    "selectionRangeProvider" : true,
    "semanticTokensProvider" : {
      "full" : {
        "delta" : true
      },
      "legend" : {
        "tokenModifiers" : [
          "declaration",
          "deprecated",
          "deduced",
          "readonly",
          "static",
          "abstract",
          "virtual",
          "dependentName",
          "defaultLibrary",
          "usedAsMutableReference",
          "functionScope",
          "classScope",
          "fileScope",
          "globalScope"
        ],
        "tokenTypes" : [
          "variable",
          "variable",
          "parameter",
          "function",
          "method",
          "function",
          "property",
          "variable",
          "class",
          "interface",
          "enum",
          "enumMember",
          "type",
          "type",
          "unknown",
          "namespace",
          "typeParameter",
          "concept",
          "type",
          "macro",
          "comment"
        ]
      },
      "range" : false
    },
    "signatureHelpProvider" : {
      "triggerCharacters" : [
        "(",
        ")",
        "{",
        "}",
        "<",
        ">",
        ","
      ]
    },
    "textDocumentSync" : {
      "change" : 2,
      "openClose" : true,
      "save" : true
    },
    "typeDefinitionProvider" : true,
    "typeHierarchyProvider" : true,
    "workspaceSymbolProvider" : true
  },
  "serverInfo" : {
    "name" : "clangd",
    "version" : "Debian clangd version 14.0.6 linux+grpc aarch64-unknown-linux-gnu"
  }
}

I've discovered the source of the performance problem with semantic tokens, it's

https://gitlab.gnome.org/GNOME/json-glib/-/merge_requests/60

It can be reproduced e.g. on Editor.cxx of Scintilla which freezes Geany on load with semantic tokens enabled and then repeatedly when editing the file and the edit has some impact on the semantic tokens.

Now I'm afraid that before this change gets to distributions, it will take several years. One option is to disable semantic tokens by default and warn users which would be a bit unfortunate because the colorization is quite nice, the other direction in which I'll probably go is to ship json-glib and jsonrpc-glib together with the plugin. These aren't big and it should hopefully not be a big problem.

Find references on a function name gives a list of the files:lines where it occurs, would be good if the line content could be included to help select which to click on to goto, ie file:line: the line.

For extra credits you could generate the inset subwindow showing the list and the context of the selected item a la Vscode ... what Scintilla won't do that ... bah!!!

Allow logging only requests and notifications (instead of full json) in a way similar to clangd:

I[22:29:17.945] <-- textDocument/semanticTokens/full(49)
I[22:29:18.553] --> textDocument/publishDiagnostics
I[22:29:18.555] --> reply:textDocument/semanticTokens/full(49) 609 ms
I[22:29:56.342] <-- textDocument/didOpen
I[22:29:56.345] <-- textDocument/semanticTokens/full(50)

May be useful for debugging other servers that don't provide any logging capabilities.

The Scintilla popup used for calltips or hover messages is very limited:

• cannot be scrolled
• supports only plain text and no markup
• doesn't support links

Right now the UI shows just a scary popup warning users about what could go wrong. Ideally, there should be some preview showing affected files, possibly with the changes they contain.

I suggest having a look at the 3 points at the beginning of the settings file regarding settings loading. Basically:

[filetype] user config > [all] user config > [filetype] global config > [all] global config
[filetype] project config > [all] project config > [filetype] global config > [all] global config

where > means "overrides settings from".

Nearly all options can be specified either in the [all] section, or in the [filetype] section where they override the corresponding option from [all] or the global config file. The only exceptions are cmd, use, rpc_log, and initialization_options_file which are per-filetype settings only.

On the topic, the paragraph setting is helpful, the per line one tended to cut stuff off if it happened to be a bit long. But for pylsp the paragraph setting would be best as 1 and clangd 2 AFAICT, so maybe later it can be per server.

Can be done already, these config options can be specified in any section.

Also you said that per project LSP settings were possible, but didn't say how to set that up.

Go to Project->Properties->LSP Client, select "Use project configuration" from the combo and point it to the conf file you want to use for the project in the edit box below. You can e.g. make a copy of the currently used user config file from ~/.config/geany/plugins/lsp/lsp.conf somewhere where you want to store the project config. After this, "User configuration" in the LSP Client menu will be grayed out and the project configuration file will be used instead.

Suggested by @elextr here:

#9 (comment)

Right now, Scintilla attempts to make the selection based on alphabetic sorting but we have autocompletion items sorted by some internal logic of the LSP server. While the plugin tries to select the first item in this list, the wrong item gets selected by Scintilla first which leads to some flickering:

https://sourceforge.net/p/scintilla/bugs/2403/

Try to submit some patch to Scintilla to fix this problem.

I have a WIP patch for Geany improving how calltips re-appear when the calltip window is dismissed - could be modified for the plugin as well. Right now the LSP plugin relies on the "trigger" characters (which are typically ( , )) but when the autocompletion popup disappears, the calltip window should reappear too.

If I start Geany with a Python file as the current document pylsp doesn't start, but if I switch from the python file to something else and back pylsp is started.

If I start Geany with a C file as current document clangd does start immediately.

Its hard to see buried in @b4n's elements warnings, so in case you missed it.

[187/234] Compiling C object 'plugins/...lsp@sha/lsp_json-glib_json-parser.c.o'
../plugins/lsp/json-glib/json-parser.c: In function ‘json_parser_load’:
../plugins/lsp/json-glib/json-parser.c:1013:17: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
 1013 |   gchar *data = input_data;
      |                 ^~~~~~~~~~

This may be useful, otherwise these files may show diagnostic message errors.

I haven't checked yet if window/workDoneProgress is reported when clangd starts indexing the project (but I'd assume it is), so implementing

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_workDoneProgress_create

could prevent some confusion when the project gets indexed for the first time:

#10

When there is an error and a warning reported e.g. for some identifier, both the error and the warning marker is displayed. We should just show a single marker and the error marker should take precedence over the warning marker.

When the cursor is moved off any code a hover popup shows for line 1.

Since it also shows over windows which cover Geany its very annoying, move the cursor off Geany to the browser to write this and the browser covers geany but the line 1 popup shows on top of the browser.

Maybe Scintilla can be used to tell the cursor is not in code and so the hover not be shown.

Have made a Geany project in one of my C++ projects, it is Cmake, but it has the compile_commands.json and I get local types highlighted and autocomplete and good scope autocompletes for variables declared with them, but only if I have the .hpp file open.

And I get no highlighting, autocomplete or scope autocomplete for the C++ STL library.

@elextr Just curious - would the LSP plugin be enough for you to switch back to Geany for your C++ projects? I know you mentioned bad autocompletion, symbol goto and symbol highlighting as the main problems of the tag manager but these should be much better with the LSP plugin. Is there anything else? (After ironing-out possible bugs and usability problems of the plugin.)

Right now there are various LSP features unimplemented by the plugin (code formatting, refactoring support, auto-fixes, etc.) which I plan to add in the future - I just concentrated on the features that affect the API between Geany and LSP plugins.

On the other hand, I don't want to do some things like managing the build process (will have to be done externally) and I'm not sure if all the "workspace" features of LSP could be implemented with Geany not really knowing what files are part of the project.

Is there anything outside of what LSP provides that you'd miss and what LSP features currently unimplemented by the plugin you'd need most?

Geany 2.0 does, Scite does, Vscode does.

As a result the right click menu applies to the wrong thing.

Put the cursor on a symbol, delay for a moment, right click, the symbol popup overwrites the menu making it impossible to select some of the items in the menu. And once its there its persistent, have to go to another symbol to get rid of it, also of course closing the menu.

Its very timing dependent, only happened once or twice. Maybe something like the right click happening after the popup has been idle queued, but not rendered yet (wild ass guess).

So far, I haven't debugged the plugin for memory leaks. I bet there will be some missing unref()s there...

Cloned, built installed with meson, there is a lsp.so in lib/x86_64-linux-gnu with filebrowser and other core plugins, they appear in plugin manager, lsp does not.

Message in debug messages:

18:50:33: Geany INFO		: Can't load plugin: /home/lex/geany_lsp/geany-lsp/lib/x86_64-linux-gnu/geany/lsp.so: undefined symbol: JSONRPC_MESSAGE_PUT_VARIANT

Is there a specific version of json-rpc needed, have 3.34.0?

Scrolling waaaay back in the build I found:

../plugins/lsp/lsp-server.c:506:4: warning: implicit declaration of function ‘JSONRPC_MESSAGE_PUT_VARIANT’; did you mean ‘JSONRPC_MESSAGE_GET_VARIANT’? [-Wimplicit-function-declaration]
  506 |    JSONRPC_MESSAGE_PUT_VARIANT(get_init_options(server)),
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Dear olde C, thinking a macro is a function, sigh!!!

Seems like it needs to be 3.42 AFAICT, you might check.

At the moment, diagnostic markers (error/warning underlines) are redrawn every time a message arrives from the server. Also, all the document's markers are cleared and all of them are re-inserted. This could be made more efficient if there are performance problems:

• marker re-drawings could be batched and performed only after some small delay in case multiple diagnostic messages arrive in burst from the server
• some diff could be calculated against the displayed markers and only the differences could be cleared/redrawn
• possibly, only the visible area of the document could be redrawn

Pulled b4n's latest encodings changes and mesoned them but had encodings.c open at the time. Got a reload info bar as expected, selected reload and then the positioning of semantic highlighting is wrong. Looks like clangd is still using its cache and not reparsing the modified file or the plugin isn't updating semantics in Scintilla.

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" :-)

This currently seems to be a limitation in Scintilla as specifying the whole prefix length in SCI_AUTOCSHOW leads to some weird selection behavior, see

https://sourceforge.net/p/scintilla/bugs/2403/

See comments in code

foo.cpp:

#include <string>
#include <iostream>
#include <memory>
#include "foo.hpp"

using namespace std;

class Cpp {
	std::string s;
public:
	Cpp(std::string&& st):s(move(st)){}
	std::string str(){ return s; }
	void str(const string& st){ s = st; }
	// string is highlighted without std:: because of the using
	size_t size();
	~Cpp(){}
};

size_t Cpp::size(){
	return s.size();
}

size_t Hpp::size(){
	return s.size();
}

int main(){
	Hpp h("foo");
	Cpp c("bar");
	auto cp = make_unique<Cpp>("abc");
	std::cout<<"h="<<h.str()<<":"<<h.size()<<" c="<<c.str()<<":"<<c.size()<<std::endl;
	c.str("abc");
	cout<<"cp="<<cp->str()<<endl; 
	// cp-> works, and type of cp was inferred from a template at L29!!!
	// cp->str( correctly shows two overloads
	int Hpp = 0; ++Hpp;
	//  ^^^ should not be highlighted
	// I guess this is Scintilla (once a name is in a keyword list its always a type)
	return 0;
}

This is a follow on from this.

Geany has goto declaration and goto definition but Vscode also has goto type definition as per this LSP message.

Use case:

In code Foo* something(); auto p = something(); p->foo the foo is red wriggly underlined and the hover says "No member named 'foo' in 'Foo'".

As discussed in the link above goto on foo will do nothing, its not visible here, lets see whats p (hovers) oh, its a Foo*, tries goto definition gets auto p bah!!! and same for goto declaration, but in Vscode goto type definition lands on class Foo where its obvious the member is goo not foo, woo hoo ;-P

In this simple example it would be possible to goto definition of p then goto definition of something() to find Foo which can goto declaration and get to class Foo. But thats a number of steps and it is only a simple sequence, it could easily get longer and the sequence would be blocked if something() return type was inferred or was a template parameter, then there would not be a Foo written down to follow.

LSP supports autocompletion snippets that for instance fill-in the whole if block. Since this can be annoying, it should be configurable whether to enable/disable this feature.

Right now, only one LSP server is allowed for one filetype. This could be limiting in cases when there are multiple LSP servers for a given language and each of them is better at something else so e.g. one could be used for autocompletion, the other for formatting.

This would, however, complicate the config file and it's hard to say if it's a real-life scenario. The config file would have to be updated to support more servers for a single file and allow sections like [Pascal_1], [Pascal_2], etc. for all the servers.