bug#22324: 25.0.50; completion-category-defaults style doesn't override completion-styles (gets prepended instead)

[Dmitry Gutov]

On 24.01.2022 11:46, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > So the fix I had in mind looks like:
> >
> > diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> > index d58c23af8f..0aee55f33c 100644
> > --- a/lisp/minibuffer.el
> > +++ b/lisp/minibuffer.el
> > @@ -1043,7 +1043,7 @@ completion--styles
> >     (let* ((cat (completion-metadata-get metadata 'category))
> >            (over (completion--category-override cat 'styles)))
> >       (if over
> > -        (delete-dups (append (cdr over) (copy-sequence completion-styles)))
> > +        (cdr over)
> >          completion-styles)))
>
> Oh, I see.  Hm...  that would change the behaviour for those that depend
> on this working the old way.

My theory is that this has never been reported because people never 
really notice the distinction in practice since if the completions 
styles are customized, that's usually done in favor of more lax ones.

So appending the default styles at the end doesn't affect the behavior 
in 99% of the cases. But it does add some CPU usage/latency in the "no 
matches" case, because that's the only case when the failover happens.

There might be a few users out there, of course, who rely on the current 
behavior, but I'm not sure what their use cases would be, and there 
can't be many people like that either because the completion styles 
stuff is fairly obscure. People have been exploring alternative 
front-ends recently that plug into CAPF, but 
completion-category-overrides is probably not a popular variable to 
customize still.

> Perhaps it'd make more sense to add a new variable to allow real overrides?

I don't know. What would it be called? 
completion-category-overrides-for-real-now?

Given that the only times people are likely to notice the distinction 
are some odd edge cases (and the extra lag is not so big or obvious), 
there will be even fewer occasions for people to learn about and 
customize the new var.

Unless we obsolete the previous one, which would be a fair approach, if 
we knew that it actually has a fair amount of users who need to migrate.