Markdown in docs looks like it highlights python keywords about jedi-language-server

[karthiknadig]

@pappasam Thank you. I verified that this is fixed.

[pappasam]

Strange... which version of jedi-language-server is this being generated by? On version 0.28.4, if your editor prefers markdown and you haven't explicitly configured your preferred markup as plaintext, jedi-language-server returns the following text wrapped in triple ticks without any language format specified:

See: https://github.com/pappasam/jedi-language-server/pull/72/files

[karthiknadig]

I will investigate this and move it accordingly. It might take me a couple of days to get to this.

[karthiknadig]

This is the request and response for hover:

[Trace - 1:28:34 AM] Sending request 'textDocument/hover - (716)'.
Params: {
    "textDocument": {
        "uri": "file:///c%3A/GIT/jedi-language-server/tests/test_data/hover/hover_test1.py"
    },
    "position": {
        "line": 2,
        "character": 14
    }
}


[Trace - 1:28:34 AM] Received response 'textDocument/hover - (716)' in 8ms.
Result: {
    "contents": {
        "kind": "markdown",
        "value": "```\nModule doc string for testing\n```\n"
    },
    "range": {
        "start": {
            "line": 2,
            "character": 7
        },
        "end": {
            "line": 2,
            "character": 17
        }
    }
}

I don't think the text should be wrapper in triple-back ticks.

This is form pylance, where we wrap only the name of the module in triple-back ticks:

[Trace - 1:35:06 AM] Received response 'textDocument/hover - (16)' in 3ms.
Result: {
    "contents": {
        "kind": "markdown",
        "value": "```python\n(module) somemodule\n```\n---\nModule doc string for testing"
    },
    "range": {
        "start": {
            "line": 2,
            "character": 8
        },
        "end": {
            "line": 2,
            "character": 18
        }
    }
}

[krassowski]

This is intended to show pre-formatted text from docstrings as such (preserving white spaces and using constant character width).
IMO the issue is with you editor as fenced backticks without info string (language specifier) should not use syntax highlighting, see common markdown specification and test cases. In particular Python docstrings include code blocks of other languages which may not have universally supported code highlighters (e.g. production lists) or which cannot be determined from static analysis.

[krassowski]

But if there are no indents at all AND we can safely assume there it is no code either then the backticks could be removed indeed.

[wyuenho]

@karthiknadig Is this Emacs? Cause I'm seeing the same trace from lsp-mode's log. There are two issues here I believe, one is even if the server was initialized with "markupKindPreferred": "plaintext", the completion.completionItem.documentationFormat returned from the server is still "markdown". Also, Emacs's lsp-mode is also doing something weird when rendering the completion documentation as well, as I think the docs are getting font-locked twice.

Update
This looks up a emacs lsp-mode problem as the documentationFormat is currently hardcoded as markdown.

[wyuenho]

There's also an additional problem: if the client declares capabilities "completion.completionItem.documentationFormat": ["markdown", "plaintext"], and the server is initialized to "jedi.markupKindPreferred": "plaintext", the client capabilities still wins so there's not really a way to prefer plaintext in user configuation.

But the jls code in choose_markup seems to prefer the value in jedi.markupKindPreferred, but the server traces shows the documentation kind is markdown... somewhere the preferred value is lost...

[wyuenho]

Ok this is my fault, lsp-jedi's initializationOptions shouldn't be nested inside an extra jedi dict...

[karthiknadig]

@wyuenho This is from VS Code.

[pappasam]

@karthiknadig I believe this has been resolved in the latest release. Please let me know if you think otherwise.

[karthiknadig]

I will test this sometime this week.

But we can't take this in the extension. Since we have not yet deprecated 3.6.*. If i understand correctly this now requires python greater than 3.6.2?

[pappasam]

Ah, in that case I'll look into re-adding support for 3.6.0+. Removing support simplified some thing for development dependencies, but since I don't think any regular dependencies are impacted, I can probably find a workaround. Stay tuned!

[pappasam]

@karthiknadig jls 0.33.0 now supports all Python 3.6+!