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 #71 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <ghe <at> sdf.org>,
 "Gregory Heytings via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, rrandresf <at> gmail.com,
 Tim Vaughan <timv <at> ughan.xyz>, 41423 <at> debbugs.gnu.org
Subject: Re: bug#41423: 27.0.91;
 eshell file completion in tramp dir is slow (3 minutes) [regression
 on pretest]
Date: Tue, 01 Sep 2020 13:14:33 +0300

On September 1, 2020 11:31:14 AM GMT+03:00, "Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:
>
>>
>>> 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.

Would it help to profile the completion process in this use case using the built-in Lisp profiler?

Previous Next

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