'textDocument/definition' requests returns incorrect case for C:\Users directory in windows

Describe the bug There seems to be inconsistent formatting (in Windows) for C:\Users-directory:

jupyterlab-lsp extension is using: ‘textDocument/definition’ requests for jump-to-definition feature. This seems to be behaving inconsistently when “jumping” from .robot file to .robot file and when from .robot to .py file.

Looks like the result is correct when jumping from .robot to .robot, meaning c:\Users is with title case for the directory name. When jumping from .robot to .py c:\users is with lower case for directory name.

Expected behavior ‘textDocument/definition’ requests should return correct case for directories.

Screenshots Relevant snippets from logs: .robot to .py

lsp: 2020-11-12 10:18:52 UTC pid: 20728 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.streams
Read: {"jsonrpc":"2.0","id":4,"method":"textDocument/definition","params":{"textDocument":{"uri":"file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/resources/keywords.robot"},"position":{"line":8,"character":32}}}

lsp: 2020-11-12 10:18:52 UTC pid: 20728 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.endpoint
Handling request from client {'jsonrpc': '2.0', 'id': 4, 'method': 'textDocument/definition', 'params': {'textDocument': {'uri': 'file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/resources/keywords.robot'}, 'position': {'line': 8, 'character': 32}}}

lsp: 2020-11-12 10:18:52 UTC pid: 20728 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.endpoint
Executing async request handler functools.partial(<bound method RobotFrameworkLanguageServer._threaded_document_definition of <robotframework_ls.robotframework_ls_impl.RobotFrameworkLanguageServer object at 0x0000018DE4978E08>>, <robotframework_ls.server_api.client.RobotFrameworkApiClient object at 0x0000018DE4B4E088>, 'file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/resources/keywords.robot', 8, 32)

lsp: 2020-11-12 10:18:52 UTC pid: 20728 - ThreadPoolExecutor-0_0 - DEBUG - robocorp_ls_core.jsonrpc.streams
Writing: {'jsonrpc': '2.0', 'id': 23, 'method': 'findDefinition', 'params': {'doc_uri': 'file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/resources/keywords.robot', 'line': 8, 'col': 32}}

lsp: 2020-11-12 10:18:52 UTC pid: 20728 - Thread-5 - DEBUG - robocorp_ls_core.jsonrpc.streams
Read: {"jsonrpc": "2.0", "id": 23, "result": [{"uri": "file:///c:/users/avaissi/Robots/new_template/libraries/ExampleLibrary.py", "range": {"start": {"line": 4, "character": 0}, "end": {"line": 4, "character": 0}}}]}

lsp: 2020-11-12 10:18:52 UTC pid: 20728 - Thread-5 - DEBUG - robocorp_ls_core.client_base
Will handle read message: {'jsonrpc': '2.0', 'id': 23, 'result': [{'uri': 'file:///c:/users/avaissi/Robots/new_template/libraries/ExampleLibrary.py', 'range': {'start': {'line': 4, 'character': 0}, 'end': {'line': 4, 'character': 0}}}]}

lsp: 2020-11-12 10:18:52 UTC pid: 20728 - ThreadPoolExecutor-0_0 - DEBUG - robocorp_ls_core.jsonrpc.streams
Writing: {'jsonrpc': '2.0', 'id': 4, 'result': [{'uri': 'file:///c:/users/avaissi/Robots/new_template/libraries/ExampleLibrary.py', 'range': {'start': {'line': 4, 'character': 0}, 'end': {'line': 4, 'character': 0}}}]}

And compare with: .robot to .robot

lsp: 2020-11-12 10:28:54 UTC pid: 20728 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.streams
Read: {"jsonrpc":"2.0","id":5,"method":"textDocument/definition","params":{"textDocument":{"uri":"file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/tasks.robot"},"position":{"line":8,"character":30}}}

lsp: 2020-11-12 10:28:54 UTC pid: 20728 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.endpoint
Handling request from client {'jsonrpc': '2.0', 'id': 5, 'method': 'textDocument/definition', 'params': {'textDocument': {'uri': 'file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/tasks.robot'}, 'position': {'line': 8, 'character': 30}}}

lsp: 2020-11-12 10:28:54 UTC pid: 20728 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.endpoint
Executing async request handler functools.partial(<bound method RobotFrameworkLanguageServer._threaded_document_definition of <robotframework_ls.robotframework_ls_impl.RobotFrameworkLanguageServer object at 0x0000018DE4978E08>>, <robotframework_ls.server_api.client.RobotFrameworkApiClient object at 0x0000018DE4B4E088>, 'file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/tasks.robot', 8, 30)

lsp: 2020-11-12 10:28:54 UTC pid: 20728 - ThreadPoolExecutor-0_1 - DEBUG - robocorp_ls_core.jsonrpc.streams
Writing: {'jsonrpc': '2.0', 'id': 24, 'method': 'findDefinition', 'params': {'doc_uri': 'file:///c:/Users/avaissi/Robots/new_template/.virtual_documents/tasks.robot', 'line': 8, 'col': 30}}

lsp: 2020-11-12 10:28:54 UTC pid: 20728 - Thread-5 - DEBUG - robocorp_ls_core.jsonrpc.streams
Read: {"jsonrpc": "2.0", "id": 24, "result": [{"uri": "file:///c:/Users/avaissi/Robots/new_template/resources/keywords.robot", "range": {"start": {"line": 6, "character": 0}, "end": {"line": 12, "character": 1}}}]}

lsp: 2020-11-12 10:28:54 UTC pid: 20728 - Thread-5 - DEBUG - robocorp_ls_core.client_base
Will handle read message: {'jsonrpc': '2.0', 'id': 24, 'result': [{'uri': 'file:///c:/Users/avaissi/Robots/new_template/resources/keywords.robot', 'range': {'start': {'line': 6, 'character': 0}, 'end': {'line': 12, 'character': 1}}}]}

lsp: 2020-11-12 10:28:54 UTC pid: 20728 - ThreadPoolExecutor-0_1 - DEBUG - robocorp_ls_core.jsonrpc.streams
Writing: {'jsonrpc': '2.0', 'id': 5, 'result': [{'uri': 'file:///c:/Users/avaissi/Robots/new_template/resources/keywords.robot', 'range': {'start': {'line': 6, 'character': 0}, 'end': {'line': 12, 'character': 1}}}]}

Versions:

• OS: [Windows 10]
• Robot Framework Version [3.2.2]
• Robot Framework Language Server Version [0.5.0, current master]

Logs robotframework_ls.lsp.20728.log

[fabioz]

I’ll take a look at it (at the start of the next week).

A question: why is this an issue? (In windows both paths should be the same, so, this seems like a client bug not being able to recognize that c:/users and C:/Users is the same thing).

– note: fixing it in the language server to provide the real path stored and not normalized should be ok, but I’m curious on why that’s a problem in the first place.

[fabioz]

Closing this (the issue seems to be on jupyterlab-lsp which does some hacks in mapping things with an internal representation).