bug#70036: 30.0.50; Move file-truename to the C level

[Theodor Thornhill]

On Mar 31, 2024 14:57, Felician Nemeth <felician.nemeth@gmail.com> wrote:

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Felician Nemeth <felician.nemeth@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  70036@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?

I can look into get-file-buffer, sure. But remember that my new caching is merely a data structure change from list to map. The managed buffer list is still there

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.