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

Previous Next

Full log

Message #365 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: Thu, 2 Nov 2023 16:40:29 +0200

On 02/11/2023 11:48, João Távora wrote:
> On Wed, Nov 1, 2023 at 10:45 PM Dmitry Gutov <dmitry <at> gutov.dev> wrote:
> 
>>> If orderless (which I've never tried), does some kind of scoring of
>>> completions, it probably also needs the same complications of flex.
>>
>> Turns out, Orderless doesn't do any scoring or sorting. Only filtering.
> 
> Interesting, so if I M-x d i f f with orderless I don't get results in
> any particular order?

Right.

And input "diff" actually results in prefix-only matching. But if the 
input contains space (or any other pre-configured delimiter character), 
then it's translated to a set of substring matches, performed in any 
order. So "diff mode" does not translate to ".*diff.*mode", but a more 
complex regexp with all permutations.

IOW, this whole approach results in stricter matching with fewer 
results, so a smarter sort isn't that necessary.

>>>>>> Anyway, have you looked into what it would take to solve it?
>>>>>
>>>>> No, naively, I just think it's a similar situation of display and business
>>>>> logic being mixed up.  Presumably the quoted stuff is just for insertion
>>>>> (and display?), and the unquoted stuff is what patterns/scoring should
>>>>> operate on.
>>>>
>>>> Apparently it's good for insertion, but according to that comment inside
>>>> the function, the unquoted stuff might actually be better for display.
>>>
>>> No idea what the unquoted stuff is for, so I haven't really tested it.
>>
>> A couple of scenarios:
> 
> Thanks.  Then I think it is working OK, but it would be safer if you were
> to double-check yourself, as I really never use this functionality.

They look okay, yes. I imagine Daniel also tested the 
'completion--unquoted' solution before offering his patches.

> I addressed all your docstring suggestions, fixed a bug and significantly
> simplified the code in the latest version of the patch.  I also
> removed the instrumentation in icomplete.el.  Patch attached here
> and pushed to feature/completion-lazy-hilit.

Thank you. I don't see that the bug was, but deferring the scoring even 
in the eager highlighting case looks sensible (why not, indeed, if the 
performance is no worse).

Previous Next

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