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


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Daniel Mendler <mail <at> daniel-mendler.de>, "emacs-devel <at> gnu.org" <emacs-devel <at> gnu.org>
Cc: João Távora <joaotavora <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org
Subject: bug#47711: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting
Date: Sat, 14 Aug 2021 06:11:26 +0300
Hi Daniel,

I haven't yet read the patch in detail, but it sounds like a move in the 
right direction (even if it doesn't include the long-overdue overhaul of 
the whole API).

A few notes on the new stuff:

> Finally the
`highlight` value is a function taking a list of completion strings
and returns a new list of new strings with highlighting applied.

First of all, I'd really like it to be a function that applies to 
individual completion strings, not the whole collection. That would make 
it much easier to use in company-capf without having to rewrite a lot of 
code in the presentation layer.

Second, perhaps instead of modifying the strings themselves it could 
return some data (like a list of faces-intervals tuples) that could be 
used to do so?

Again, in company-capf's we end up parsing the face properties in the 
string, so those modifications are just extra work for CPU which we 
could eliminate.

This is less critical, though.

On 11.08.2021 19:11, Daniel Mendler wrote:
> There are currently two issues with the patch with regards to backward
> compatibility. Fortunately they are fixable with a little effort.
> 
> 1. I would like to deprecate `completion-score' or remove it altogether,
>     but unfortunately `completion-score' is used in the wild. In order to
>     preserve `completion-score', bind `completion--filter-completions' in
>     the highlighting functions. Add `completion-score' in
>     `completion-pcm--hilit-commonality' when
>     `completion--filter-completions' is nil.

And third: I think completion-score could ultimately use the same 
treatment as 'highlight'. Meaning, being returned up the stack together 
with completions, so other bits of code could look up those values.

I don't have a clear picture of this yet, but see the recently filed 
bug#49888. If we want to be able to combine matching scores with recency 
scores, simply sorting the completions after matching is not going to 
cut it.

Not sure if this is something we can tackle now, but keeping this 
possible evolution in mind could help us make good choices in the 
current migration.




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.