bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]


From: Dmitry Gutov
Subject: bug#47711: 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 03:11:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 27/10/2023 02:44, João Távora wrote:
It is slower in the sorting step, though: mostly due to the extra
consing created with the alist to-be-sorted, I guess, but also because
of the repeated string-match call (which, while fast and much faster
than the match-data call, is still not free).
And is the sorting step not included in the full call to
completion-filter-completions?  I don't fully understand how it works.

It recomputes all the scores inside the display-sort-function.

That's how when compared in practice using fido-vertical-mode the
results were about the same.
But that's what matters right?

Pretty much, yes. Except for some potential exotic cases where the UI or the user would want to override the sorting logic. Corfu and Vertico have such capability, but I'm not sure if it's used often.

Also in the last iteration of the "yoyo" fido-vertical-mode test,
results with my latest patch are quite a bit faster.

Hmm, your latest (lazy-hilit-2023-v3.diff) improves the (completing-read "" obarray) scenario a lot (over the original two 2023 solutions), but not the the 'C-h v' scenario. I don't have an explanation.





reply via email to

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