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

Previous Next

Full log

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

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: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
 new `completion-filter-completions` API and deferred highlighting
Date: Fri, 27 Oct 2023 02:35:33 +0300

On 27/10/2023 02:27, João Távora wrote:
> Dmitry Gutov<dmitry <at> gutov.dev>  writes:
> 
>> My understanding is it's due to the judicious call (copy-sequence
>> orig) that you added before 'put-text-property' is called. While it
>> seems like a good idea to preserve the original value, when almost all
>> of obarray matches the current input (which is the current scenario),
>> a lot of strings will be copied.
> You're right, I reproduced the regression.  I thought I had taken out
> the copy-sequence, but forgot it there.  In an earlier stage I suspected
> that I needed the copy, but I don't think I do.  Please try this new
> patch that removes it.  I've also pushed it to the
> feature/completion-lazy-hilit branch.

Yep, without copy-sequence the regression is gone. Now the input strings 
are routinely mutated, though. ;-(

You could do a copy a little later -- after the match succeeds and the 
score is computed. But for short widely-matching inputs like 'a' that 
would make little difference.

I also experimented with hash-tables for "external" score storage. But 
it still comes out a little slower than either of the proposed solutions.

Previous Next

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