pyright server insists on sending type 2 completion (snippet) even if the client is replying that it doesn't support "snippets"

[tshu-w]

Hi, pyright server seems insist on sending type 2 completion (snippet) even if the client is replying that it doesn't support "snippets" as analysis in joaotavora/eglot#884 (comment)

[erictraut]

I'm not sure what you mean by "snippets" in this context. Can you provide more context?

Which LSP client are you using? And what is the LSP feature it claims not to support?

[erictraut]

Ah, interesting question. In the case where the client supports snippets, the client should handle this. In the case where the client doesn't handle snippets, I'm not sure but my guess is that the server should handle it. Pyright doesn't currently do so. Could you please file a bug report on this? I can work on a fix.

Do you plan to add support for snippets? That would be preferable since most other clients already provide such support.

[tshu-w]

I'm using snippets packages to make sure it indents correctly on Emacs. But I hope this can work without snippets, and It seems pyright doesn't support snippet yet? I will report a bug later this day.

[erictraut]

Pyright's completion provide does emit snippets if the client supports them. See

pyright/packages/pyright-internal/src/languageService/completionProvider.ts

Line 1235 in 043c5bd

sb += this._options.snippet ? '${0:pass}' : 'pass';

.

[erictraut]

I dug into this further, and VS Code appears to insert the indentation/spaces automatically even if the result is not a snippet. This implies that the client should treat \n characters as if the user has typed a "return" at that point and insert the appropriate indentation.

I'm going to assume this is the intended/expected behavior for clients, in which case pyright is correct in not providing additional spaces in its response. So there's no need to file a bug. You'll need to address this in the client code.

[tshu-w]

Ok, thank you for your investigating.

[joaotavora]

This implies that the client should treat \n characters as if the user has typed a "return" at that point and insert the appropriate indentation.

I'm sorry to disagree, but I don't know how VS Code's behaviour "implies" it. If you find something in the LSP spec that is one thing, but VS Code's behaviour is not the authority here, as much as I understand it is Microsoft's editor and you work for/collaborate with Microsoft.

According to my understanding of LSP, an edit is emitted by the server for a given document to leave that document at a certain intended state. A language agnostic client cannot generally know what the "appropriate indentation" after each newline character provided in the edit. It's the server who has all knowledge of what the language is or what that indentation means. In Python, it is not just decorative, as we know.

Snippets are special edits, which are specified to be inserted at a given column and inherit "dumb" current columnar indentation. At least Emacs's snippets are. They were inherited from the old TextMate editor, as were LSP's. And in TextMate, they behaved like that.

Anyway, with snippets all is fine: server and client agree on the exact way to do things. But normal edits are different, they have no such precise indication of behavior.

At least not until relatively recently. I went to check the standard, as I should have done in the beginning. From 3.16.0 on, completion items may contain this nugget:

/**
	 * How whitespace and indentation is handled during completion
	 * item insertion. If not provided the client's default value depends on
	 * the `textDocument.completion.insertTextMode` client capability.
	 *
	 * @since 3.16.0
	 * @since 3.17.0 - support for `textDocument.completion.insertTextMode`
	 */
	insertTextMode?: InsertTextMode;

In https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#insertTextMode you find out more. The server can supply a completion for which "dumb" columnar indentation is to be added by the client:

/**
 * How whitespace and indentation is handled during completion
 * item insertion.
 *
 * @since 3.16.0
 */
export namespace [InsertTextMode](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#insertTextMode) {
	/**
	 * The insertion or replace strings is taken as it is. If the
	 * value is multi line the lines below the cursor will be
	 * inserted using the indentation defined in the string value.
	 * The client will not apply any kind of adjustments to the
	 * string.
	 */
	export const asIs: 1 = 1;

	/**
	 * The editor adjusts leading whitespace of new lines so that
	 * they match the indentation up to the cursor of the line for
	 * which the item is accepted.
	 *
	 * Consider a line like this: <2tabs><cursor><3tabs>foo. Accepting a
	 * multi line completion item is indented using 2 tabs and all
	 * following lines inserted will be indented using 2 tabs as well.
	 */
	export const adjustIndentation: 2 = 2;
}

Of course, as always, the server has to check for the client's capability to handle this new feature. Probably VS code declares it, but Eglot doesn't. So the server shouldn't rely on its presence.

In its absence it should, IMHO, fallback to the old "asIs" indentation semantics. Why, given the legal void, shouldn't it fallback to the other "dumb column" semantics? Well, because it flows from the even older definition of textEdit, which describes the process to insert a given set of characters in a given order in the document.

In practical terms, it may be that Eglot develops this capability in the future. It doesn't seem devilish to implement and I will support any good PR doing it. But I'm also not particularly concerned:

• this behaviour that I personally consider incorrect seems only to be exhibited by pyright.
• with snippets everything's correctly specified and working, so for now a workaround is just to enable snippets in Emacs, which is easy.

[tshu-w]

@erictraut Hi, what's your opinion about @joaotavora comment.

[erictraut]

I don't have plans to change the non-snippets behavior at this time. If the emacs LSP plans to enable snippets support, that sounds like it addresses everyone's needs.

[joaotavora]

To be clear, Emacs LSP client already supports snippets. But they can be turned off by the user, which is what I suppose @tshu-w does.