Re: master 08c80c45dde: Don't use file-truepath in Eglot (bug#70036)

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Thu, 18 Apr 2024 01:24:59 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> Let's say that during the Eglot session I visit both main.cpp
>> and mainlink.cpp in different buffers (either because I don't visit
>> them at the same time or because find-file-existing-other-name is
>> nil).  Then I press M-? on lib.h's foo() to tell me who references it.
>> 
>> Before you change, Eglot will -- correctly -- tell me there  is a single
>> user of lib.h's foo() function in my project.
>> 
>> After your change, it tells me there are two users.  This is wrong,
>> there is only one.
>> 
>> It could be that some servers with direct access to the file system
>> can deduplicate the information and add back the symlink smarts.
>> 
>> But clangd doesn't do this, and in general servers _can't_ do
>> this because LSP models a virtual file system.
>> 
>> And for symlinks to large enough files, I'd be surprised if this
>> doesn't slow down the performance of the server because it has to
>> analyse what it is told is a completely new file.
>> 
>> So this seems like a pretty big flaw to me after just minimal
>> surface scratching.  Please reinstate the previous code.
>
> I asked exactly this question when the change was discussed, and was
> told that symlinks are not a problem.
>

I still believe it is not. The spec [1] states the URI should follow
rfc3986 [2], which states that

```
   Because URIs exist to identify resources, presumably they should be
   considered equivalent when they identify the same resource.  However,
   this definition of equivalence is not of much practical use, as there
   is no way for an implementation to compare two resources unless it
   has full knowledge or control of them.  For this reason,
   determination of equivalence or difference of URIs is based on string
   comparison, perhaps augmented by reference to additional rules
   provided by URI scheme definitions.  We use the terms "different" and
   "equivalent" to describe the possible outcomes of such comparisons,
   but there are many application-dependent versions of equivalence.
```

This to me reads that we shouldn't really consider symlinks, and if
necessary it should be done on the server side. 

I tried the exact same recipe Joao provided in java and go. It works in
java, but not go, and that is mentioned here [3]

> If we need to support symlinks in Emacs instead of leaving this to the
> LSP servers, we could perhaps do that once in some strategic place,
> instead of using file-truename everywhere where normally
> expand-file-name would do.  Or maybe explicitly test with
> file-symlink-p before using file-truename, which is (and has to be)
> pretty expensive.  IOW, "punishing" everyone for the benefit of
> relatively rare use cases is not the best optimization

I agree with this. I'll test it a little.

Theo


[1]: 
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#uri
[2]: https://datatracker.ietf.org/doc/html/rfc3986
[3]: https://go-review.googlesource.com/c/tools/+/454355