emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU ELPA] New package proposal: aggressive-completion.El


From: Philip Kaludercic
Subject: Re: [GNU ELPA] New package proposal: aggressive-completion.El
Date: Sat, 03 Apr 2021 19:22:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Tassilo Horn <tsdh@gnu.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>> Just tried out the package, and it seems to work very well! I just
>> have two annoyances:
>>
>> 1. Where there are too many options, lag is noticeable (eg. with C-h o).
>
> There's a knob for that: `aggressive-completion-max-shown-completions'.

Sadly it still persists. All in all it is barley noticeable, and it only
affects the first letter in my case. Maybe you can replicate it:

        C-h o
        a
        [wait]
        
on my system there is about half a second of lag between typing a and a
appearing on the screen. If I typo more letter, they are all delayed by
half a second.

>> 2. The completion buffer keeps appearing and disappearing, shrinking
>>    and growing.
>
> The *Completions* buffer should appear as soon as there is at least one
> and at most `aggressive-completion-max-shown-completions' completions,
> and it'll disappear when completion selected a unique match.  Do you see
> something different?

No, but if I remove a word and the completion is not unique any more, the
buffer re-appears.

> Wrt. the resizing: that's the standard completion help behavior you'd
> also see when double-TAB-ing during completion.  Not sure if there's a
> way to restrict that window's height.

Yes, but my point was that the change in window height is in response to
a manual completion request. This might just be me, but I try to avoid
"undeterministic" behaviour, or at least effects that I cannot infer
from my actions. I cannot say for sure, but I think that if you could
force the completion buffer to stay at one place during the entire
completion, this would be preferable.

> Bye,
> Tassilo
>
>

-- 
        Philip K.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]