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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: João Távora <joaotavora <at> gmail.com>
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: bug#47711: 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 03:06:48 +0200

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.

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)?

Previous Next

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