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

[Dmitry Gutov <dgutov@yandex.ru>]

On 26.01.2022 20:59, Daniel Mendler wrote:
> 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.

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.