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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <ghe <at> sdf.org>
Cc: Tim Vaughan <timv <at> ughan.xyz>, rrandresf <at> gmail.com,
 Michael Albinus <michael.albinus <at> gmx.de>, 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: Wed, 02 Sep 2020 12:36:38 -0400

>> The lispref says the following:
>>
>>    The functions on this hook should generally return quickly, since
>>    they may be called very often (e.g., from @code{post-command-hook}).
>>    Supplying a function for @var{collection} is strongly recommended if
>>    generating the list of completions is an expensive operation.  Emacs
>>    may internally call functions in @code{completion-at-point-functions}
>>    many times, but care about the value of @var{collection} for only
>>    some of these calls.  By supplying a function for @var{collection},
>>    Emacs can defer generating completions until necessary.  You can use
>>    @code{completion-table-dynamic} to create a wrapper function:
>>
>
> I see, thanks for the pointer.  I did not find this because I was searching
> for `pcomplete-completions-at-point' and `pcomplete-completions'.  It would
> make sense to put this pointer in pcomplete.el.

Indeed, it might make sense to add a reminder that `pcomplete-here` is
the function where we "choose which completion table to use" and that
this choice should always be quick (so if the set of candidates can take
a while to compute, make sure the completion table computes it lazily).

> It seems to me (even now that I understand the design of
> `pcomplete-completion-at-point', and that I understand how the more
> complex mechanism can be made as efficient as the simple one) that
> this simple mechanism is often sufficient, that it is easier to
> understand, and that it should remain available.

You can definitely write such a "simple completion UI" on top of
`completion-at-point-functions`, and make sure it calls things like
`pcomplete-completion-at-point` only once.

Basically, take `completion-at-point`, throw out the "minor mode"
part and you're done.

> What is still missing IMO is a general description/documentation of the
> various parts of the completion mechanisms (completion-at-point,
> completion-in-region, pcomplete, pcomplete-completion-at-point,
> comint-completion-at-point, icomplete, ...) in Emacs behave and
> interact. I was completely lost when I started working on this bug, things
> are a bit clearer now, but still not very clear.

I find it hard to write such things because I'm too familiar with it to
know what's non-obvious.  Maybe you could try writing something that
you'd have found useful, and then we can collaboratively improve it?

>> In the patch I sent I think there's a bug in that a leading * should
>> change the START..END returned by `pcomplete-completion-at-point-function`
>> so the `glob-name` computation should be done outside of the
>> `completion-table-dynamic`.
> *sigh* So this bug can still not be considered fixed?

Yup :-(
I'll try to come up with something better if noone else beats me to it.


        Stefan

Previous Next

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