Pyright LSP completion lowercase to uppercase leaves first few characters #5469
Comments
|
It looks like this might be a language server issue, actually. Looks like the -> {
"jsonrpc": "2.0",
"method": "completionItem/resolve",
"params": {
"data": {
"filePath": "/tmp/tmp.ZmHxbsplID/src/example.py",
"position": {
"character": 2,
"line": 3
},
"symbolLabel": "Uppercase",
"workspacePath": "/tmp/tmp.ZmHxbsplID"
},
"kind": 7,
"label": "Uppercase",
"sortText": "09.9999.Uppercase"
},
"id": 13
}
<- {
"jsonrpc": "2.0",
"id": 13,
"result": {
"data": {
"filePath": "/tmp/tmp.ZmHxbsplID/src/example.py",
"position": {
"character": 2,
"line": 3
},
"symbolLabel": "Uppercase",
"workspacePath": "/tmp/tmp.ZmHxbsplID"
},
"kind": 7,
"label": "Uppercase",
"sortText": "09.9999.Uppercase",
"documentation": {
"kind": "plaintext",
"value": "class Uppercase()"
}
}
}
<- {
"data": {
"filePath": "/tmp/tmp.ZmHxbsplID/src/example.py",
"position": {
"character": 2,
"line": 3
},
"symbolLabel": "Uppercase",
"workspacePath": "/tmp/tmp.ZmHxbsplID"
},
"documentation": {
"kind": "plaintext",
"value": "class Uppercase()"
},
"kind": 7,
"label": "Uppercase",
"sortText": "09.9999.Uppercase"
}But the equivalent from rust-analyzer, for instance, look like this: -> {
"jsonrpc": "2.0",
"method": "textDocument/didChange",
"params": {
"contentChanges": [
{
"range": {
"end": {
"character": 6,
"line": 4
},
"start": {
"character": 4,
"line": 4
}
},
"text": "Uppercase"
}
],
"textDocument": {
"uri": "file:///tmp/tmp.a2fOsJD8aq/src/main.rs",
"version": 27
}
}
}
-> {
"jsonrpc": "2.0",
"method": "completionItem/resolve",
"params": {
"additionalTextEdits": [],
"deprecated": false,
"filterText": "Uppercase",
"kind": 22,
"label": "Uppercase",
"preselect": true,
"sortText": "ffffffef",
"textEdit": {
"insert": {
"end": {
"character": 6,
"line": 4
},
"start": {
"character": 4,
"line": 4
}
},
"newText": "Uppercase",
"replace": {
"end": {
"character": 6,
"line": 4
},
"start": {
"character": 4,
"line": 4
}
}
}
},
"id": 20
}
<- {
"jsonrpc": "2.0",
"id": 20,
"result": {
"label": "Uppercase",
"kind": 22,
"deprecated": false,
"preselect": true,
"sortText": "ffffffef",
"filterText": "Uppercase",
"textEdit": {
"newText": "Uppercase",
"insert": {
"start": {
"line": 4,
"character": 4
},
"end": {
"line": 4,
"character": 6
}
},
"replace": {
"start": {
"line": 4,
"character": 4
},
"end": {
"line": 4,
"character": 6
}
}
},
"additionalTextEdits": []
}
}
<- {
"additionalTextEdits": [],
"deprecated": false,
"filterText": "Uppercase",
"kind": 22,
"label": "Uppercase",
"preselect": true,
"sortText": "ffffffef",
"textEdit": {
"insert": {
"end": {
"character": 6,
"line": 4
},
"start": {
"character": 4,
"line": 4
}
},
"newText": "Uppercase",
"replace": {
"end": {
"character": 6,
"line": 4
},
"start": {
"character": 4,
"line": 4
}
}
}
}Neovim (and presumably Visual Studio Code) must be papering over the difference. |
|
rust-analyzer seems to give its completions as TextEdits, properly replacing the prompt text, while Pyright just gives them as raw suggestions and lets the editor decide how to format it. I'm not certain, because I don't know much at all about LSP implementation. |
|
Duplicate of #4851 |
the-mikedavis
added
the
R-duplicate
|
I think this a bit different then the referenced issue, I tested with the proposed fix in #1819 (I rebased it onto master but either I did something wrong or there is something that needs to be fixed in the implementation because I found it made the editor quite slow) and it doesn't replace the |
|
@the-mikedavis This isn't the same issue, because it's completely deterministic here and related only to capitalization. |
the-mikedavis
removed
the
R-duplicate
|
Looks likely to me like the relevant bit is in helix-term/src/ui/completion.rs line 136, where |
|
Ah, it wouldn't just be a case-insensitive version, but having to replace the case-insensitive-matching prefix entirely, or figuring out otherwise how to entirely replace the entered text that prompted the completion. I'm not sure if that could just be calculated with the |
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
|
Should be fixed by #6173 |
|
I think #5728 fixes this actually |
|
Good point :) |
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
…5469) Most LSPs will complete case-insensitive matches, particularly from lowercase to uppercase. In some cases, notably Pyright, this is given as a simple insert text instead of TextEdit. When this happens, the prefix text was left unedited.
Summary
When I use Pyright completion that changes case from lowercase to uppercase, the first two characters remain instead of being replaced.
The same does not happen using the same language server in neovim, so I don't think it's an issue with the language server itself.
Reproduction Steps
Using this
languages.tomlentry for Pyright:If I create a simple python project with a virtualenvironment and activate the language server:
Then add a simple uppercase
Uppercaseclass, and start typinguppercaseand complete it to the class, I end up with this:If I type it in the right casing to begin with, it has no problem and does not duplicate the first two letters.
Helix log
Platform
Fedora Linux 37
Terminal Emulator
gnome-terminal
Helix Version
helix 22.12
The text was updated successfully, but these errors were encountered: