GNU bug report logs - #70036
30.0.50; Move file-truename to the C level

Previous Next

Full log

View this message in rfc822 format

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70036 <at> debbugs.gnu.org, theo <at> thornhill.no
Subject: bug#70036: 30.0.50; Move file-truename to the C level
Date: Sun, 31 Mar 2024 14:57:15 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Felician Nemeth <felician.nemeth <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  70036 <at> debbugs.gnu.org
>> Date: Sat, 30 Mar 2024 10:46:00 +0100
>> 
>> I think using find-buffer-visiting instead of get-file-buffer and
>> file-truename instead of expand-file-name in Eglot is problematic.
>> Let's say we have these files:
>> 
>> /project/a.c
>> /project/a.h -> /other/a.h
>> 
>> Eglot will communicate these file names to the LSP server: /project/a.c
>> and /other/a.h.  Then the server cannot "associate" a.h with a.c.
>> Additionally, a.h will be outside of the LSP workspace.
>> 
>> This indeed confuses clangd a bit: it only takes into account the
>> changes of buffer a.h when it is saved.  (Because it assumes
>> /project/a.h is not opened in the editor.)
>
> Can LSP servers resolve symlinks?  If they can, then expand-file-name
> is TRT, AFAIU.

The LSP specification does not talk about symlinks.  The servers I used
let the operating system resolve symlinks for them.

All in all, I think Eglot should switch to use expand-file-name as well.
It should also use get-file-buffer instead of the more complicated
caching mechanism proposed previously.  Theo?

Nevertheless, Eglot will continue to handle poorly the case when there
is a symlink in a project that points outside of the project.
Hopefully, this can be potentially solved later with the idea behind
eglot--servers-by-xrefed-file.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.