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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

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.