[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70036: 30.0.50; Move file-truename to the C level
From: |
Eli Zaretskii |
Subject: |
bug#70036: 30.0.50; Move file-truename to the C level |
Date: |
Thu, 28 Mar 2024 08:22:01 +0200 |
> From: Theodor Thornhill <theo@thornhill.no>
> Cc: 70036@debbugs.gnu.org
> Date: Wed, 27 Mar 2024 22:56:41 +0100
>
> Eli Zaretskii <eliz@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?
> 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.
bug#70036: 30.0.50; Move file-truename to the C level, Felician Nemeth, 2024/03/27
- bug#70036: 30.0.50; Move file-truename to the C level, Theodor Thornhill, 2024/03/27
- bug#70036: 30.0.50; Move file-truename to the C level, Eli Zaretskii, 2024/03/28
- bug#70036: 30.0.50; Move file-truename to the C level, Theodor Thornhill, 2024/03/28
- bug#70036: 30.0.50; Move file-truename to the C level, Theodor Thornhill, 2024/03/28
- bug#70036: 30.0.50; Move file-truename to the C level, Felician Nemeth, 2024/03/28
- bug#70036: 30.0.50; Move file-truename to the C level, Theodor Thornhill, 2024/03/28
- bug#70036: 30.0.50; Move file-truename to the C level, Felician Nemeth, 2024/03/30
- bug#70036: 30.0.50; Move file-truename to the C level, Theodor Thornhill, 2024/03/30