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

View this message in rfc822 format

From: Gregory Heytings <ghe <at> sdf.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Tim Vaughan <timv <at> ughan.xyz>, rrandresf <at> gmail.com, Michael Albinus <michael.albinus <at> gmx.de>, 41423 <at> debbugs.gnu.org
Subject: bug#41423: 27.0.91; eshell file completion in tramp dir is slow (3 minutes) [regression on pretest]
Date: Tue, 1 Sep 2020 10:31:14 +0200 (CEST)

>
>> 26. therefore pcomplete-completions does not call pcomplete/cd but 
>> eshell-complete-commands-list
>
> I guess this is the culprit
>

No, see below.

>
> and this is where the time is spent.
>

Yes, this is what I said.

>
> `eshell-complete-commands-list` eagerly builds the list of possible 
> candidates and it takes a while whereas we should here return something 
> quickly and cheaply, e.g. by returning a function which will build and 
> return this list more lazily when completion is actually performed.
>

No, the bug is in the completion mechanism, not in eshell.  I don't know 
exactly (because the mechanism is so complicated) where the completion 
functions should be fixed, but it is clear that there is no reason to call 
pcomplete-completions-at-point *three* times.

There is no reason to call pcomplete-completions-at-point when RET is 
pressed.

Typing "cd foo/ RET" does not call pcomplete-completions-at-point. 
Typing "cd foo TAB RET" should only call pcomplete-completions-at-point to 
add the trailing slash, and should not build a list of all possible 
commands.

>
> Of course, the slowdown will presumably still be seen when you do 
> actually want to complete a command name, so we should probably try and 
> figure out more precisely where the slowdown comes from and how to 
> avoid/reduce it.
>

That's another, separate issue, and it is not relevant here.  BTW, when 
you want to complete a command name, at least you have some characters in 
the prefix (or if you don't, you expect that listing all candidates will 
be slow).

Typing "cd TAB" works almost instantaneously (and prints "Sole 
completion"), even on a remote host.  Typing "ls TAB" works almost 
instantaneously, too, even on a remote host.  It prints "Complete, but not 
unique", and pressing TAB again lists the alternate completion candidates. 
Typing "l TAB" takes (on a remote host) five to ten seconds before 
printing all completion candidates, but again this is what a user expects.

Nobody expects that typing RET, when the completion has already been done, 
would take three minutes.

>
> Maybe `tramp-eshell-directory-change` should tell 
> `eshell-complete-commands-list` to cache the list and also not to bother 
> checking `file-executable-p`?
>

That's yet another, separate issue, that is not relevant here.  Indeed 
there are possible improvements in eshell and tramp, but this bug is in 
the completion mechanism, not in eshell or in tramp.

Previous Next

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