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

Previous Next

Full log

Message #32 received at 70036 <at> debbugs.gnu.org (full text, mbox):

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70036 <at> debbugs.gnu.org
Subject: Re: bug#70036: 30.0.50; Move file-truename to the C level
Date: Thu, 28 Mar 2024 08:03:25 +0100

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

>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: 70036 <at> debbugs.gnu.org
>> Date: Wed, 27 Mar 2024 22:56:41 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> As for the patch - it now relies on wordexp to resolve the paths, and I
>> >> believe there is no real feature parity with the old variant as for now,
>> >> but I haven't seen any issues thus far. If this approach is accepted I
>> >> will of course make sure we have feature parity, unless that isn't
>> >> wanted.
>> >
>> > We cannot rely on wordexp and we cannot rely on realpath: both are not
>> > portable enough.
>> 
>> OK - for my education on the portability argument. Is that because of
>> Emacs support targets like haiku and old versions of windows, or
>> something else inherent in these functions?
>
> Platforms other than GNU/Linux are the main concern, yes.  Another
> aspect to consider is whether the function is available in Gnulib --
> if it is, we can import the Gnulib implementation and use it on
> platforms which don't provide it natively; in that case, using such a
> function is okay (but the MS-Windows port will likely need to provide
> its own implementation, because Emacs uses Unicode APIs to access and
> process file names, something Gnulib doesn't do on Windows).
>
> In this case, realpath is available in Gnulib, but wordexp isn't,
> AFAICT.  And I'm not even sure we want to use wordexp here, because
> (reading its docs) it does stuff we don't want to do in file-truename.
> Why did you need to call it here?
>

Thanks! I'll admit Fexpand-file-name likely does what we want in this
case, so I'll look into this.

>> Another much simpler way to improve Eglot performance her could be to
>> allow for the relevant functions to execute through handlers, to not
>> break other parts of Emacs. For example `find-buffer-visiting` could
>> allow to run through a simpler function that merely expands and looks up
>> the current file, considering that the LSP server likely reports on
>> files that are already existing, and likely most symlink shenanigans
>> aren't an issue here. Just thinking out loudly on this.
>
> AFAIR, find-buffer-visiting was significantly sped up recently (see
> bug#66117), so if you did your benchmarks with Emacs before commit
> b7a737ef49 on master, perhaps do it again with the latest master
> branch.

These reports are made using some commit from yesterday, so these
speedups should be included. `find-buffer-visiting` is used inside of
the `publishDiagnostics` handler, which sometimes receives file paths
for the whole project, so this really becomes a bottleneck for servers
that provide project wide diags.

Previous Next

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