GNU bug report logs - #41423
27.0.91; eshell file completion in tramp dir is slow (3 minutes) [regression on pretest]

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andrés ramírez <rrandresf <at> gmail.com>,
 41423 <at> debbugs.gnu.org
Subject: Installing the fix for bug#41423 on emacs-27 (was: 27.0.91; eshell
 file completion in tramp dir is slow (3 minutes) [regression on pretest])
Date: Sun, 31 Jan 2021 23:36:09 -0500

Stefan Monnier [2021-01-31 21:45:39] wrote:
> FWIW, I installed a variant of my earlier patch into `master`.
> I suspect it has a few rough edges, so watch out for regressions, please
> and complain to me (with as precise a recipe as you can) when you bump
> into them,

I installed a further change which should fix the main issue I could
foresee.  I'm now reasonably happy with the patch (I think it's "right"
rather than a quick ad-hoc fix.  It deserves further improvements to add
some form of caching, but that's largely orthogonal to this bug report).

IIUC Michael had marked this bug as "blocking" for Emacs-27, so this
argues for installing it on the `emacs-27` branch.

The patch is not without risks seeing how it changes a function from
returning a list to returning a function and how it fundamentally
changes *when* the code is executed.  So I'm not sure whether it should
go on the `emacs-27` branch:

A- For non-Eshell users it is "obviously safe".
B- For Eshell-over-Tramp users it should be a clear improvement even if
   it turns out to introduce some unforeseen regressions in some cases.
C- Finally, Eshell-not-over-Tramp users should hopefully see no
   difference at all, which mostly means no improvement to make up for
   any risk of regression.

So, is the improvement in B worth the risk in C?


        Stefan

Previous Next

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