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

[Theodor Thornhill <theo@thornhill.no>]

João Távora <joaotavora@gmail.com> writes:

> On Thu, Apr 18, 2024 at 6:49 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > 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.
>
> Surely not by me, and perhaps whoever told you this wasn't
> considering this and other scenarios.  Some funcionality works
>
>> 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.
>
> As far as I can tell, file-truename is (was) only used "naked"
> once or twice,  I think it's the use inside "find-buffer-visiting" which is the
> most crucial for the scenarios at hand.  I'll try to see if I can separate
> them.
>
> João

This is correct. The find-buffer-visiting is the most crucial one.

Theo