Lsp: Feature request, option to use tooltips instead of phantoms

[slifin]

In the PHPCS plugin via sublime-linter I can hover over problems and get an idea of what the issues are:

In sublime LSP I click somewhere near my problem, open the command palette find "LSP: next diagnostic" which opens this phantom which in my theme is styled weirdly:

When there are a lot of issues this is hard to manage because of the extra step and because next diagnostic doesn't always seem to end up where I want it

Is it possible to enable the use of tooltips?

[rwols]

You can also hover over diagnostics in LSP and it'll show the problem in a hover popup instead of a phantom.

You may also bind the lsp_hover command to a keybinding.

[rwols]

For the phantoms, you may also use F8 to move forward, and SHIFTF8 to move backwards. This can be modified in the keybindings through the command Preferences: LSP Keybindings in the command palette.

[slifin]

hmm I can't replicate a tooltip on hover my settings are:

// Settings in here override those in "LSP/LSP.sublime-settings",

{
    "show_view_status": false,
    "auto_show_diagnostics_panel": "never",
    "diagnostics_highlight_style": "box",
    "document_highlight_style": "fill",
    "initialize_timeout": 300,
    "diagnostics_gutter_marker": "",
    "show_code_actions_bulb": false,
    "show_symbol_action_links": false,
    "clients":
    {
        // you probably have some other clients in here
        "phan":
        {
            "command":
            [
                "phan",
                "--quick",
                "--allow-polyfill-parser",
                "--language-server-on-stdin",
                "--language-server-enable-hover",
                "--language-server-enable-completion",
                "--language-server-enable-go-to-definition",
            ],
            "enabled": true,
            "initializationOptions":
            {
                "storagePath": "/tmp/phan"
            },
            "languageId": "php",
            "scopes":
            [
                "source.php",
                "embedding.php"
            ],
            "syntaxes":
            [
                "Packages/PHP/PHP.sublime-syntax"
            ]
        }
    },
    "clj-kondo":
       {
         "command":
         [
           "java",
           "-jar",
           "/Users/adriansmith/Scripts/kondo-lsp.jar"
         ],
         "enabled": true,
         "languageId": "clojure",
         "scopes":
         [
           "source.clojure"
         ],
         "syntaxes":
         [
           "Packages/Clojure/Clojure.sublime-syntax"
         ]
       }
}

If I focus an error caused by the lsp server I get

edit: binding the command lsp_hover doesn't appear to do anything either I wonder if something is conflicting, I can't see anything in the console

[rwols]

The on_hover callback that is used in this plugin simply calls the lsp_hover command, so getting the lsp_hover command to work is the first step.

To log all commands in SublimeText, open the console and run the following:

sublime.log_commands(True)

Then, bind lsp_hover to a keybinding and run it manually. For instance, mine is bound like this:

    {"keys": ["ctrl+shift+h"], "command": "lsp_hover" , "context": [{"key": "setting.lsp_active"}]},

Manually triggering lsp_hover should result in something like this in the console:

command: lsp_hover
command: lsp_update_server_panel {"message": "--> pyls textDocument/hover(33): {'textDocument': {'uri': 'file:///home/raoul/.config/sublime-text-3/Packages/LSP/plugin/core/transports.py'}, 'position': {'line': 41, 'character': 11}}", "prefix": ":"}
command: lsp_update_server_panel {"message": "<<< pyls 33: {'contents': [{'language': 'python', 'value': 'content_length(line: bytes) -> Optional[int]'}]}", "prefix": ":"}
command: insert {"characters": "content_length(line: bytes) -> Optional[int]"}

Now that I think about it, the lsp_hover command will only work if the language server advertises that it is a hoverProvider. It looks like Phar is mainly a linter. Perhaps it does not advertise that it is a hoverProvider. You can check this by opening the language server log panel (LSP: Toggle Log Panel in the command palette) and looking at the response of our initialize request. It is the very first request that we send to the language server. The language server will respond with its capabilities, among which should be hoverProvider. If it doesn't advertise that it is a hoverProvider, no popup will appear when doing lsp_hover.

Looking at your startup command you're passing "--language-server-enable-hover", so I would expect hoverProvider to be there in the initialize response.

By the way, I have never heard of those language servers you're using. Very cool!

[rwols]

Perhaps we should add a command to dump the server's capabilities to a scratch view :thinking:

[slifin]

I get something like this:

command: lsp_hover
command: drag_select {"event": {"button": 1, "x": 300.492788462, "y": 394.753605769}}
command: lsp_hover
command: lsp_hover
command: show_panel {"panel": "console", "toggle": true}
command: drag_select {"event": {"button": 1, "x": 343.263221154, "y": 278.852163462}}
command: lsp_hover
command: _nv_feed_key {"key": "j"}
command: lsp_hover
command: drag_select {"event": {"button": 1, "x": 335.567908654, "y": 291.427283654}}
command: lsp_hover
command: drag_select

The maintainer of phan is usually very responsive: https://github.com/phan/phan

[rwols]

Check the server log panel to see if the textDocument/hover request is sent, and check to see if it gets a response back.

[rchl]

It seems to be enabled by default judging from their readme:
https://github.com/phan/phan/blob/master/internal/CLI-HELP.md

And the code is here: https://github.com/phan/phan/blob/3fdb2257f6da180fd90fb418a173ad1004b3c4fe/src/Phan/LanguageServer/LanguageServer.php#L1036

[slifin]

@rwols how do I access the server log panel?

[rwols]

You can open the panel by running LSP: Toggle Log Panel from the command palette. If you set "log_payloads": true and "log_debug": true in the settings you'll see very verbose logging in the panel, but you may want to disable that again once done.

[rchl]

I've checked what happens.
Server responds with null for textDocument/hover. At least for the lines with diagnostic errors/warnings.

The popup that VSCode shows actually shows diagnostic for hovered region. I think it makes sense.

We only show diagnostics in the status bar (well, also separate panel) but for that you need to put cursor on the diagnostic first.
And diagnostics in the status bar seem to get "stuck" sometimes. They are shown even though cursor is not on the region with a problem.

[rwols]

So the gist of this issue is basically that given any sort of info for a region, we want that to appear in a popup. Whether that be diagnostics or hover info.

[rchl]

Are we showing diagnostics in the popup now? It seems like so to me when I'm checking with pyls. But I don't remember us doing any fixes for this.

Or maybe it depends on the server's response to textDocument/hover? pyls responds with this if nothing is to be shown:

{
  "contents": ""
}

[rwols]

It depends on whether the server is a hoverProvider. If it’s not a hoverProvider then no popup is shown.

[rchl]

But I've made this comment before:

Server responds with null for textDocument/hover. At least for the lines with diagnostic errors/warnings.

So it looks like that server is a hover provider but maybe null response makes us not show the popup?

[rwols]

This is fixed in the ST4 branch.