emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: Re: master 08c80c45dde: Don't use file-truepath in Eglot (bug#70036)
Date: Thu, 18 Apr 2024 09:34:26 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]