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

[Daniel Mendler <mail@daniel-mendler.de>]

Hello Dmitry,

thank you for pinging me.

> Apparently this config is recommended in the README of both Corfu and 
> Vertico (https://github.com/minad/vertico#configuration), both projects 
> by Daniel Mendler.
> 
> I guess we should ask Daniel whether he has been aware of the 
> completion-styles failover mechanic, and what he thinks about it.

Yes, I've been aware of the failover mechanic and I think it is not
good. From my experience, I would prefer if the override is a real
override, which this issue is about. Users can still opt-in to the
default styles on a case by case basis if this is desired.

The assessment that the variable `completion-category-overrides` is
modified rarely might have been true, but this is not the case anymore.
In the context of the GNU ELPA packages Orderless, Vertico, Consult,
Embark, Marginalia etc., we educate users to make heavy use of this
variable since it permits fine tuning of the completion behavior
depending on the completion category. We also use the completion
category heavily in Marginalia and Embark to determine the type of the
candidates for annotations and minibuffer actions.

Unfortunately the configurations you mentioned, Dmitry, make use of the
failover mechanism. I indeed want to use partial-completion and then
failover to the orderless default. If there wouldn't be a failover I
would have of course recommended another override (partial-completion +
orderless).

Nevertheless I would appreciate the removal (or replacing) of the
failover mechanism. I noticed that it has lead to confusion for some
users before. It leads to performance issues when the slow default sets
in as has been pointed out already. Since currently there is no
possibility to really override the completion styles except via an
advice, removing the failover seems like a good idea.

Furthermore we've also got `completion-category-defaults`. It may make
sense to distinguish them by making the override a real override and
keep the current behavior for the defaults. The alternative would be a
deprecation of the override variable and the introduction of new
variable which is a real override.

One final statement regarding making a breaking change here: You should
consider that the packages orderless etc are fairly new and still have
breaking changes from time to time, so even if these configurations are
widespread or see growing adoption, this should not hold you back from
making a breaking change. I will then promptly adapt the documentation
of these projects and add a warning note, which will soon propagate to
the users who use Emacs master, which is still young in the development
cycle. Of course my statement applies only if the aforementioned are
truly the only widespread packages affected by this.

Daniel