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

[Eshel Yaron]

close 70589 30.1
quit

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > This makes it easier for users to customize generated '*-modes' options,
>>> > such as 'global-completion-preview-modes', via the Custom interface.
>>>
>>> This kind of discussion is not useful with Stefan (CC'ed) on board.
>>                                         ^^^^
>> Oops, I meant "without", of course.  Sorry.
>
> 🙂
>
> FWIW, the latest patch looks fine to me,

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

> 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.