GNU bug report logs -
#70589
[PATCH] Refine the Custom type of generated '*-modes' options
Previous Next
Reported by: Eshel Yaron <me <at> eshelyaron.com>
Date: Fri, 26 Apr 2024 09:50:05 UTC
Severity: normal
Tags: patch
Fixed in version 30.1
Done: Eshel Yaron <me <at> eshelyaron.com>
Bug is archived. No further changes may be made.
Full log
Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 1 year and 22 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.