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

[Daniel Mendler]

On 1/26/22 18:19, Stefan Monnier wrote:
> No, because `ignore` will return nil and so we'll just keep going to the
> next style.  We need try/all-completion functions for this style to
> return a non-nil value but that is like "no completion".
> 
> I suspect it can't be done quite right without changing `minibuffer.el`,
> but we can probably get close enough to be tolerable with older Emacsen.
> 
> E.g. for the try-completion case, I think we can return (STRING . POINT)
> and for all-completions maybe returning `0` will do the trick.

Okay, right. This makes the proposal a bit less appealing to be honest,
since we end up with a hack, where the result is something like a
non-nil invalid completion result. Hmm. So maybe we shouldn't do this
and fix the problem at the root? Remove the failover mechanism? I am not
fond of introducing a hack to work around the problematic failover design.
> While we're here, let's not forget the other problem with
> `completion-category-defaults` which is when a package puts something
> like `substring` in it because `partial-completion` is not "good
> enough": this can end up taking precedence over the users's
> customization of the default to something like `flex` which is probably
> not what's wanted.

Exactly. This is the reason why I reset `completion-category-defaults`
in my configuration and I also recommend this in the README of the
packages. I should probably describe the problem more explicitly. Often
users copy example configurations from packages without investigating
the implications. Furthermore in the case of completion styles the
implications are often not that obvious. One more reason to remove
complexity if possible...

> I'm not completely sure how to fix that one.  An cheap solution would be
> to allow `completion-category-defaults` to specify a function rather
> than a list of styles, and then this function will return the list of
> styles to use so it can dynamically adapt to the user's chosen default.
> But it's kind of a cop out because that function will need to "guess"
> what is the relationship between the various styles, which is the crux
> of the matter.
> 
> This problem doesn't apply to `completion-category-override` since we
> can consider it to be the user's responsability to take `completion-styles`
> into account when setting `completion-category-override`.

My cheap proposal would be the removal of `completion-category-defaults`
and the removal of the failover mechanism of
`completion-category-overrides`. Then the user can adjust the
`completion-styles` entirely in their configuration. This is maybe not
the most user friendly solution in the first place. But as soon as you
start to tweak the completion styles it makes things simpler and easier
to understand. My opinion in this case is admittedly a bit radical since
I propose that users adjust their completion styles heavily to unlock a
lot of potential (for example look at orderless and the flexible
orderless style dispatchers). But such adjustments may not be for everyone.

Daniel