bug#70589: [PATCH] Refine the Custom type of generated '*-modes' options

[Eshel Yaron]

reopen 70589
quit

Eshel Yaron writes:

> Thanks, so I've now pushed it to master.  I'm not closing the bug yet,
> in favor of your additional suggestion below.

Sorry, I mistakenly closed the bug nonetheless.  Reopening.

>> but really this is Lars's code, so you don't need me "on board", really.
>>
>> Also, while I'm here: I think part of the "problem" is in the semantics:
>> anything after a t or nil is ignored, which is hard to explain via
>> a "single small line" of text.
>
> Agreed.  Although it's not such a big problem IMO, since the Customize
> buffer also shows the docstring of the option, which explains the
> semantics pretty clearly.
>
>> We could imagine extending the semantics so that you can use `((not a)
>> . t)` instead, in which case this meaning of `t` can be shared with the
>> "main one" (instead of having two `t` cases and two `nil` cases) in the
>> sense that the syntax would be:
>>
>>     PRED can be:
>>     t                        Always accept
>>     nil                      Always decline
>>     ((not . MODES) . PRED)   Decline if in MODES, otherwise like PRED
>>     (MODE . PRED)            Accept if in MODE, otherwise like PRED
>>
>
> That sounds neat.
>
>> but then we couldn't use the `repeat` Custom type and instead we'd have
>> to implement an ad-hoc type for it, I believe.
>
> I think that's right.