Completion items are sent back with a lot of duplicates

[rchiodo]

Since 3.17, LSP has a way to send duplicate data on completions only once instead of in each completion item.

This here:

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#completionItem

Doing so could make Pylance faster (and make sync server closer to async server)

[rchiodo]

Okay this is blocked on possibly changing the LSP client code to combine the data differently: https://github.com/microsoft/vscode-languageserver-node/issues/1338

[rchiodo]

Changes taking advantage of this are here: https://github.com/rchiodo/pyrx/tree/rchiodo/completion_dupes

[debonte]

Another possible size optimization would we to eliminate the textEdit field when it's not necessary. I did a quick test where I typed print and looked through the response. There were 735 items that included textEdit and about 50% of those appeared to be unnecessary -- the range was the range of the identifier we were completing and newText matched the label. I checked this quickly by eye, so I might have missed something.

The other half were functions that needed the textEdit to insert the parens (because I had python.analysis.completeFunctionParens enabled) and move the cursor between them.

HeeJae agrees that this could make the response smaller, but is concerned about the perf impact of deciding when textEdit is needed or not.

Here's a typical textEdit. It's not small...

            "textEdit": {
                "range": {
                    "start": {
                        "line": 13,
                        "character": 0
                    },
                    "end": {
                        "line": 13,
                        "character": 1
                    }
                },
                "newText": "_P"
            },

[heejaechang]

a lot of range is same since it refer to the same range, if completion has a way to internalize or share range between items, that would save a lot of repeated text (text of LSP message)

[rchiodo]

Somebody fixed this in LSP. We'd just need to adopt the new applyKind:

https://github.com/microsoft/vscode-languageserver-node/pull/1558