Fix #715: fix eglot-extend-to-xref under Windows

[wsw0108]

By downcase 'buffer-file-name' as hash key

[joaotavora]

Thanks, but can you explain how you reached the conclusion that there is a casing problem here? When exactly is one filename with a given casing inserted into the hash table only to be retrieved with a different casing? Give a simple example.

[wsw0108]

For feature eglot-extend-to-xref, it use var eglot--servers-by-xrefed-file.

From the log attached to this issue, we can see that it's the casing mismatch problem(between lsp server and emacs). So just normalize the key for set/get to/from hash table eglot--servers-by-xrefed-file.

[joaotavora]

From the log attached to this issue, we can see that it's the casing mismatch problem(between lsp server and emacs). So just normalize the key for set/get to/from hash table eglot--servers-by-xrefed-file.

Where can I see this? Can you point it out specifically?

You wrote in that issue:

cangd return "file:///C:/Program%20Files%20%28x86%29/Windows%20Kits/10/Include/10.0.19041.0/ucrt/stdio.h"
buffer-file-name is "c:/Program Files (x86)/Windows Kits/10/Include/10.0.19041.0/ucrt/stdio.h"

But the difference between the two representations of the same file (presumably) is much more than just casing.

So I must be missing something.

[wsw0108]

(eglot--uri-to-path "file:///C:/Program%20Files%20%28x86%29/Windows%20Kits/10/Include/10.0.19041.0/ucrt/stdio.h")
"C:/Program Files (x86)/Windows Kits/10/Include/10.0.19041.0/ucrt/stdio.h"

When Emacs visit the stdio.h, the buffer-file-name will be "c:/Program Files (x86)/Windows Kits/10/Include/10.0.19041.0/ucrt/stdio.h".

And in eglot--xref-make-match, it use eglot--uri-to-path to extract file from uri, then use (expand-file-name file) as key to check eglot--servers-by-xrefed-file.

eglot/eglot.el

Lines 2347 to 2351 in 777a716

	(defun eglot--xref-make-match (name uri range)
	"Like `xref-make-match' but with LSP's NAME, URI and RANGE.
	Try to visit the target file for a richer summary line."
	(pcase-let*
	((file (eglot--uri-to-path uri))

eglot/eglot.el

Lines 2379 to 2380 in 777a716

	(setf (gethash (expand-file-name file) eglot--servers-by-xrefed-file)
	(eglot--current-server-or-lose))

[joaotavora]

Ah, thanks, so it's only the drive letter?

[wsw0108]

Ah, thanks, so it's only the drive letter?

Yes, Emacs just downcase the driver letter under Windows.

[joaotavora]

Ok. Then I don't think this is the right solution, as it has the potential to create new bugs on case sensitive file systems.

…

On Wed, Apr 27, 2022, 09:57 Shiwei Wang ***@***.***> wrote: Ah, thanks, so it's only the drive letter? Yes, Emacs just downcase the driver letter under Windows. — Reply to this email directly, view it on GitHub <#933 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC6PQZ6DU4VATKXIF4D5QLVHD6QZANCNFSM5ULR4RLQ> . You are receiving this because you commented.Message ID: ***@***.***>

[wsw0108]

(expand-file-name (eglot--uri-to-path "file:///C:/Program%20Files%20%28x86%29/Windows%20Kits/10/Include/10.0.19041.0/ucrt/stdio.h"))
"C:/Program Files (x86)/Windows Kits/10/Include/10.0.19041.0/ucrt/stdio.h"

(expand-file-name "/abc.txt")
"c:/abc.txt"

It seems expand-file-name handle absolute path specially.

[wsw0108]

FYI: https://github.com/emacs-mirror/emacs/blob/d4e3e548f5519e98c2fc842daf73a6acac7faa70/src/fileio.c#L91

[wsw0108]

this pr can not fix #715, as gopls does not follow the fs displayed case(ex gopls return C:/go/src, and fs explorer display C:/Go/src.

So I close it.