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

[Daniel Mendler]

On 1/28/22 03:35, Dmitry Gutov wrote:
> Let's remove it, I think.
> 
> IMHO, backward compatibility hacks are the reason of >50% of existing 
> CAPF's problems: you add one special case, then another, then another.
> 
> Each step isn't bad by itself (just like Stefan's current suggestion 
> sounds workable), but every one of them complicates reading the code, 
> and writing code to it, even if by a little.
> 
> If we were designing it from the ground up, we probably wouldn't add an 
> 'ignore' style. We could have added a special value like 't' which would 
> mean the opposite (*do* the fallback, for those users who would want 
> their configs to be just a little bit more terse), just like in the 
> local values of hook variables. But I'm not sure how kludgy the 
> implementation of this will turn out either, and terseness is not the 
> primary end goal for this part of user customization, I think.

I agree with you. Removing the fail over seems better in the long term.
For the users of Orderless and other custom documentation styles etc, we
can document that the fail over mechanism has been removed and provide
an advice in the documentation, which can be used to upgrade the behavior.

The user base of Orderless etc is dynamic as you point out, so they will
adapt to changes. If we assume that these users make up the majority of
users who make use of the fail over, this should not be a blocker for
this minor breaking change. Furthermore I've got multiple reports where
people wondered about the failover, so the current behavior is more
confusing than having no failover. Using `t` as last element to trigger
fail over seems like a good idea.

Daniel