GNU bug report logs -
#72696
Track-changes errors out when file is overwritten using Node.js's fs.writeFile (at least on macOS)
Previous Next
Full log
View this message in rfc822 format
Hi, Stefan,
On Tue, Aug 20, 2024 at 2:15 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> >> - Eglot errors out. This should definitely not happen and seems like
> >> a regression. Restarting Eglot should definitely not be needed.
> >> Could you clarify what you mean by Eglot erroring out and why
> >> restarting it is necessary?
> > Eglot gets in a weird state and begins reporting erroneous data to the
> > LSP server.
>
> Can you give any further details?
Consider a Python file with the following contents (including a
trailing newline):
from urllib import urlretrieve
local_filename, headers = urlretrieve('http://python.org/')
Using the Pyright LSP server, Eglot correctly reports that:
Pyright [reportAttributeAccessIssue]: "urlretrieve" is unknown import symbol
Now, rewrite the file using Node.js as instructed above so that its
contents become (again, including a trailing newline):
from urllib.request import urlretrieve
local_filename, headers = urlretrieve('http://python.org/')
Eglot now weirdly reports that:
Pyright [reportMissingImports]: Import "urllib.request.request"
could not be resolved
Somehow it thinks that the ".request" part appears twice in a row.
Here is the relevant communication between Eglot and Pyright:
[jsonrpc] e[13:00:21.956] --> textDocument/didOpen
{
"jsonrpc": "2.0",
"method": "textDocument/didOpen",
"params": {
"textDocument": {
"uri": "file:///Volumes/workplace/playground/test.py",
"version": 0,
"languageId": "python",
"text": "from urllib import urlretrieve\nlocal_filename,
headers = urlretrieve('http://python.org/')\n"
}
}
}
[jsonrpc] e[13:00:22.617] <-- textDocument/publishDiagnostics
{
"jsonrpc": "2.0",
"method": "textDocument/publishDiagnostics",
"params": {
"uri": "file:///Volumes/workplace/playground/test.py",
"version": 0,
"diagnostics": [
{
"range": {
"start": {
"line": 0,
"character": 19
},
"end": {
"line": 0,
"character": 30
}
},
"message": "\"urlretrieve\" is unknown import symbol",
"severity": 1,
"code": "reportAttributeAccessIssue",
"source": "Pyright",
"codeDescription": {
"href":
"https://github.com/microsoft/pyright/blob/main/docs/configuration.md#reportAttributeAccessIssue"
}
}
]
}
}
[jsonrpc] e[13:00:26.362] --> textDocument/didClose
{
"jsonrpc": "2.0",
"method": "textDocument/didClose",
"params": {
"textDocument": {
"uri": "file:///Volumes/workplace/playground/test.py"
}
}
}
[jsonrpc] e[13:00:26.364] --> textDocument/didOpen
{
"jsonrpc": "2.0",
"method": "textDocument/didOpen",
"params": {
"textDocument": {
"uri": "file:///Volumes/workplace/playground/test.py",
"version": 0,
"languageId": "python",
"text": "from urllib.request import
urlretrieve\nlocal_filename, headers =
urlretrieve('http://python.org/')\n"
}
}
}
[jsonrpc] e[13:00:26.366] --> textDocument/didChange
{
"jsonrpc": "2.0",
"method": "textDocument/didChange",
"params": {
"textDocument": {
"uri": "file:///Volumes/workplace/playground/test.py",
"version": 1
},
"contentChanges": [
{
"range": {
"start": {
"line": 0,
"character": 11
},
"end": {
"line": 0,
"character": 11
}
},
"rangeLength": 0,
"text": ".request"
}
]
}
}
[jsonrpc] e[13:00:26.629] <-- textDocument/publishDiagnostics
{
"jsonrpc": "2.0",
"method": "textDocument/publishDiagnostics",
"params": {
"uri": "file:///Volumes/workplace/playground/test.py",
"version": 1,
"diagnostics": [
{
"range": {
"start": {
"line": 0,
"character": 5
},
"end": {
"line": 0,
"character": 27
}
},
"message": "Import \"urllib.request.request\" could not be
resolved",
"severity": 1,
"code": "reportMissingImports",
"source": "Pyright",
"codeDescription": {
"href":
"https://github.com/microsoft/pyright/blob/main/docs/configuration.md#reportMissingImports"
}
}
]
}
}
As far as I can see, the testDocument/didChange request should not be
there. The rewrite seems to have triggered a textDocument/didClose
followed by a textDocument/didOpen, so the erroneous
textDocument/didChange ended up making the LSP server think the
".request" part appears twice in a row.
Best regards,
Dario
This bug report was last modified 302 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.