Skip to content

Inconsistent jedi_completion with snippets enabled client (vim-lsp) #619

Open

Description

@torimus

Using Vim 9.1 with latest vim-lsp and UltiSnips integration. I do explicitly enable in pylsp.plugins

  • jedi_completion.enabled to true
  • jedi_completion.include_params to true

When I invoke code completion at symbol, sometimes lsp#complete inserts function including parameters as snippet placeholders

Image

finishing completion inserts selected function with arguments as snippet placeholders:

Image

However in a quite similar case, insertion of function arguments does not happen

Image

results in

Image

Possible bug in jedi_completion plugin? Any other explanation?

Activity

  1. krassowski commented on Apr 11, 2025

    @krassowski
    Member

    Currently only an initial set of completion items (by default 25) receive snippets:

    if include_params and not is_exception_class(d.name):
    snippet = _snippet(d, resolve_label_or_snippet)
    completion.update(snippet)

    And snippets are not resolved in completionItem/resolve:

    @hookimpl
    def pylsp_completion_item_resolve(config, completion_item, document):
    """Resolve formatted completion for given non-resolved completion"""
    shared_data = document.shared_data["LAST_JEDI_COMPLETIONS"].get(
    completion_item["label"]
    )
    completion_capabilities = config.capabilities.get("textDocument", {}).get(
    "completion", {}
    )
    item_capabilities = completion_capabilities.get("completionItem", {})
    supported_markup_kinds = item_capabilities.get("documentationFormat", ["markdown"])
    preferred_markup_kind = _utils.choose_markup_kind(supported_markup_kinds)
    if shared_data:
    completion, data = shared_data
    return _resolve_completion(completion, data, markup_kind=preferred_markup_kind)
    return completion_item

    This might explain it.

  2. krassowski commented on Apr 11, 2025

    @krassowski
    Member

    The specification forbids changing insertText in resolution phase unless completionItem#resolveSupport lists it:

    By default the request can only delay the computation of the detail and documentation properties. Since 3.16.0 the client can signal that it can resolve more properties lazily. This is done using the completionItem#resolveSupport client capability which lists all properties that can be filled in during a ‘completionItem/resolve’ request. All other properties (usually sortText, filterText, insertText and textEdit) must be provided in the textDocument/completion response and must not be changed during resolve

    So it will only work for clients which do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions