GNU bug report logs - #47711
27.1; Deferred highlighting support in `completion-all-completions', `vertico--all-completions`

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Sun, 11 Apr 2021 20:52:01 UTC

Severity: normal

Found in version 27.1

Done: Daniel Mendler <mail <at> daniel-mendler.de>

Bug is archived. No further changes may be made.

Full log


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

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 47711 <at> debbugs.gnu.org
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
 new `completion-filter-completions` API and deferred highlighting
Date: Wed, 8 Nov 2023 01:24:08 +0000
On Wed, Nov 8, 2023 at 1:06 AM Dmitry Gutov <dmitry <at> gutov.dev> wrote:
>
> On 07/11/2023 14:13, João Távora wrote:
> > Any objections?  Seems to speed it up when flex is the preferred
> > completion style outside icomplete.  These are average times
> > collected from the instrumentation of the above
> > completion-all-completions when doing a M-: (setq i TAB)
> >
> > I just used my normal Emacs session for this.
> >
> > with lazy hilit:      0.104536125
> > without lazy hilit:   0.172522571
>
> IIUC the problem with the default completion-at-point UI here is that is
> prints all completions anyway, in the buffer *Completions*. And so it
> applies syntax highlighting to them as well, and does that eagerly (as
> opposed to e.g. doing that via jit-lock).
>
> If you instrumented only the 'completion-all-completions' call, then
> that might miss the subsequent time spent in sorting.

You probably mean highlighting: that's the saving being made here,
not sorting.

Anyway, it _felt_ snappier, but maybe I was dreaming.  Got any
better suggestions for places where to place `benchmark-progn`?

Also, I don't think *Completions* has _every_ matching completion,
does it?  Doesn't it display more completions as you keep TABing?
That's what I supposed was providing the speedup.

> But speaking of the case when the *Completions* buffer isn't shown yet,
> the code calls something similar to completion-try-completion, which
> ultimately goes through completion-pcm--find-all-completions. Does it
> currently apply faces too (in the default, non-lazy scenario)?

No idea. just looking to optimize low-hanging fruit I can find.  If you
can find more, go ahead.

João




This bug report was last modified 172 days ago.

Previous Next


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