Feature proposal: serve completion items from cache about jedi-language-server

[hanspinckaers]

Hi! Sounds good! Sorry for me not replying to your message, I was on vacation. Your points/concerns sound really valid.

For me, I just wanted a bit of a quick hack to first serve cached completions and also in the background ask Jedi for new completions, then update the completions (not sure if possible with language servers). This way you're never out of date for long.

One quick (beginner) question: how do you develop/debug the language server? I want to just run it from the command line and be able to use breakpoints etc.

[pappasam]

Developing / debugging is currently not the simplest process. Abstractly:

1. Make sure your language server is running the development version of jedi-language-server (eg, the one you've pip installed in the cloned repo)
2. To see things that are happening, insert server.show_message to essentially "echo" data in your editor. For example, in jedi_language_server.server.completion, if you want to see the first completed item that's returned, add the following line:

@SERVER.feature(COMPLETION, trigger_characters=[".", "'", '"'])
def completion(
    server: JediLanguageServer, params: CompletionParams
) -> Optional[CompletionList]:
    """Returns completion items."""
    ...
    completion_items = [
        jedi_utils.lsp_completion_item(
            name=completion,
            char_before_cursor=char_before_cursor,
            enable_snippets=enable_snippets,
            markup_kind=markup_kind,
        )
        for completion in completions_jedi
    ]
    if completion_items:
        server.show_message(str(completion_items))
    return (
        CompletionList(is_incomplete=False, items=completion_items)
        if completion_items
        else None
    )

3. If the server doesn't appear to be running / your completion / goto definition don't work, run pylint and mypy on your code to see if anything is wrong: poetry run pylint jedi_language_server and poetry run mypy jedi_language_server.

Note: it's somewhat difficult to develop your development tools (like jedi_language_server) because, if you break them, your development environment becomes hard to work with. Catch-22...

[pappasam]

I believe this is resolved as of recent releases. @hanspinckaers let me know if you think otherwise

[pappasam]

While this would be an interesting exercise, my current understanding is that we can't (easily) cache much beyond what Jedi has already cached because cache-validation is extremely complicated with code completion tools. For example, if we cache code that you've imported and the code itself has changed, it's somewhat involved to know that we can remove anything associated with that module from the cache and re-analyze at a future date. If you just want read-only completions, we already support: https://github.com/pappasam/coc-jedi#jedijedisettingsautoimportmodules

That said, if you want to take a stab at something and are able to:

1. Provide a (relatively) simple, easy-to-work-with/extend jls cache implemention
2. Show that it is demonstrably better in terms of performance
3. Show that it doesn't introduce any horrible edge cases

I'd be happy to be proven wrong!

If you'd like to read more about Jedi's caching challenges, see this issue: davidhalter/jedi#1059

[pappasam]

@hanspinckaers let me know if you notice any performance improvements from the latest release: https://github.com/pappasam/jedi-language-server/blob/master/CHANGELOG.md#0210

[hanspinckaers]

I'm sorry @pappasam, I'm quite busy at the moment. I did however remove all the type-information retrieval and disabled snippets, and now autocomplete flies. It's incredibly fast. Numpy autocompletion show up for me < 200ms and instant the second time. So, for me, that is actually enough, I don't really look at the type information anyway. I do miss the snippets, but the signature help in coc.nvim helps.

Maybe we want to make this an option? It's is pretty barebones though:

I was thinking maybe we could also limit the type-information retrieval to the first x items in the completion list, but I don't think that will work with the trimming down of the list via fuzzy completion in some clients.

[pappasam]

I just tested locally and it seems like disabling snippets gives sufficient performance improvement for Numpy to complete quickly (after the first completion) when including numpy in https://github.com/pappasam/coc-jedi#jedijedisettingsautoimportmodules.

We already have an initialization option for disabling snippets, so maybe we just need to document that disabling snippets + autoImportModules can help completion performance issues.

[krassowski]

Could implementation of completionItem/resolve allow for the best user experience?

The idea is that the textDocument/completion sends only the properties which are cheap to compute (say label, sortText, insertText, etc), while documentation, detail (and any other property since LSP 3.16.0) would be only sent once the clients requests to resolve the details with the completionItem/resolve request. This improves the initial speed and gives the user all information - no compromise.

The lag for completionItem/resolve can be lower than the perception threshold (dozens of milliseconds), and the client can pre-fetch a few completionItem/resolve as soon as it gets the completion result (I implemented this in my client here).

I would be happy to help with implementation.

[pappasam]

@krassowski interesting... yes, I think the new resolution patterns in 3.16 are a great opportunity for us to speed things up a lot (and to add new features, like selecting a sane name for codeAction results, etc). Two issues that might make supporting LSP 3.16 challenging in the short-term:

1. I don't think this library's language server framework, pygls, supports LSP 3.16 yet. Its developers are more focused on improving performance with pydantic at the moment, which may also have a positive impact on completionItem speed.
2. Many language clients don't-yet support the latest LSP version. See here for coc's progress toward supporting 3.16.

Would love your thoughts on supporting LSP 3.16 features based on the aforementioned challenges!

[krassowski]

I agree 3.16 is fresh. What about implementing completionItem/resolve just with the documentation and detail for now, as these were there almost forever?

I think that it might be nice to allow for the user to configure the server so that it either returns eagerly (at a price of lower performance) or uses completionItem/resolve as indeed some clients may not be optimized for completionItem/resolve. It could be an array of properties, where user could specify "resolveEagerly": ["detail"] if their client supports displaying detail always, or does not support completionItem/resolve. Then once support of resolving "type" eagerly is added the user would be able to add it here as well.

[krassowski]

Actually clients already have to opt-in to allow for lazy resolution of anything else than "documentation" and "detail", so no backward compatibility issue here:

	/**
	 * Indicates which properties a client can resolve lazily on a
	 * completion item. Before version 3.16.0 only the predefined properties
	 * `documentation` and `details` could be resolved lazily.
	 *
	 * @since 3.16.0
	 */
	resolveSupport?: {
		/**
		 * The properties that a client can resolve lazily.
		 */
		properties: string[];
	};

[krassowski]

FYI here is the implementation for pyls: https://github.com/palantir/python-language-server/pull/905/files

[pappasam]

@hanspinckaers does #56 solve this issue for you?

[hanspinckaers]

Looks good! Will take a look later today.

[hanspinckaers]

Yes, this PR with snippets disabled is just as fast as my dirty hack. Awesome work! I'm not sure if the resolveEagerly should be default to false while coc.nvim doesn't support the resolve yet?