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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70589 in the body.
You can then email your comments to 70589 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 09:50:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eshel Yaron <me <at> eshelyaron.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 26 Apr 2024 09:50:06 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tags: patch
This makes it easier for users to customize generated '*-modes' options,
such as 'global-completion-preview-modes', via the Custom interface.
[0001-Refine-the-Custom-type-of-generated-modes-options.patch (text/patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 10:58:13 GMT)
Full text and
rfc822 format available.
Message #8 received at 70589 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 26 Apr 2024 11:49:19 +0200
> From: Eshel Yaron via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 10:59:08 GMT)
Full text and
rfc822 format available.
Message #11 received at 70589 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 26 Apr 2024 11:49:19 +0200
> From: Eshel Yaron via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> --- a/lisp/emacs-lisp/easy-mmode.el
> +++ b/lisp/emacs-lisp/easy-mmode.el
> @@ -580,7 +580,19 @@ define-globalized-minor-mode
> and nil means \"don't use\". There's an implicit nil at the end of the
> list."
> mode)
> - :type '(repeat sexp)
> + :type '(choice (const :tag "Enable in all major modes" t)
> + (const :tag "Don't enable in any major mode" nil)
> + (repeat :tag "Only enable in"
> + (choice
> + (const :tag "All major modes" t)
> + (const :tag "No major mode" nil)
> + (symbol :value fundamental-mode
> + :tag "Specific major mode")
> + (cons :tag "Exclude modes"
> + (const :tag "Exclude..." not)
> + (repeat
> + (symbol :value fundamental-mode
> + :tag "Major mode"))))))
Why does it make sense to have the "all" and "none" alternatives
twice?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 11:15:04 GMT)
Full text and
rfc822 format available.
Message #14 received at 70589 <at> debbugs.gnu.org (full text, mbox):
Hi,
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Fri, 26 Apr 2024 11:49:19 +0200
>> From: Eshel Yaron via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> --- a/lisp/emacs-lisp/easy-mmode.el
>> +++ b/lisp/emacs-lisp/easy-mmode.el
>> @@ -580,7 +580,19 @@ define-globalized-minor-mode
>> and nil means \"don't use\". There's an implicit nil at the end of the
>> list."
>> mode)
>> - :type '(repeat sexp)
>> + :type '(choice (const :tag "Enable in all major modes" t)
>> + (const :tag "Don't enable in any major mode" nil)
>> + (repeat :tag "Only enable in"
>> + (choice
>> + (const :tag "All major modes" t)
>> + (const :tag "No major mode" nil)
>> + (symbol :value fundamental-mode
>> + :tag "Specific major mode")
>> + (cons :tag "Exclude modes"
>> + (const :tag "Exclude..." not)
>> + (repeat
>> + (symbol :value fundamental-mode
>> + :tag "Major mode"))))))
>
> Why does it make sense to have the "all" and "none" alternatives
> twice?
These are slightly different: a value of t ("Enable in all major modes")
says to enable everywhere, while a t inside a list ("All major modes")
says to enable in modes that were not mentioned earlier in the list (so
putting t in the end of the list means "otherwise, enable"). Similarly
for the "none" alternatives: a value of nil ("Don't enable...") means we
never enable the minor mode, while the effect of a nil inside the list
is relative to the previous elements, and means "otherwise, don't".
Does that make sense?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 11:35:08 GMT)
Full text and
rfc822 format available.
Message #17 received at 70589 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 70589 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Fri, 26 Apr 2024 13:13:37 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Why does it make sense to have the "all" and "none" alternatives
> > twice?
>
> These are slightly different: a value of t ("Enable in all major modes")
> says to enable everywhere, while a t inside a list ("All major modes")
> says to enable in modes that were not mentioned earlier in the list (so
> putting t in the end of the list means "otherwise, enable"). Similarly
> for the "none" alternatives: a value of nil ("Don't enable...") means we
> never enable the minor mode, while the effect of a nil inside the list
> is relative to the previous elements, and means "otherwise, don't".
> Does that make sense?
It might make sense, if we change the labels to say what you tell
above.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 12:26:10 GMT)
Full text and
rfc822 format available.
Message #20 received at 70589 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 70589 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Fri, 26 Apr 2024 13:13:37 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Why does it make sense to have the "all" and "none" alternatives
>> > twice?
>>
>> These are slightly different: a value of t ("Enable in all major modes")
>> says to enable everywhere, while a t inside a list ("All major modes")
>> says to enable in modes that were not mentioned earlier in the list (so
>> putting t in the end of the list means "otherwise, enable"). Similarly
>> for the "none" alternatives: a value of nil ("Don't enable...") means we
>> never enable the minor mode, while the effect of a nil inside the list
>> is relative to the previous elements, and means "otherwise, don't".
>> Does that make sense?
>
> It might make sense, if we change the labels to say what you tell
> above.
>
> Thanks.
OK, here's an updated patch with revised labels:
[v2-0001-Refine-the-Custom-type-of-generated-modes-options.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 15:02:04 GMT)
Full text and
rfc822 format available.
Message #23 received at 70589 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 70589 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Fri, 26 Apr 2024 14:24:42 +0200
>
> >> These are slightly different: a value of t ("Enable in all major modes")
> >> says to enable everywhere, while a t inside a list ("All major modes")
> >> says to enable in modes that were not mentioned earlier in the list (so
> >> putting t in the end of the list means "otherwise, enable"). Similarly
> >> for the "none" alternatives: a value of nil ("Don't enable...") means we
> >> never enable the minor mode, while the effect of a nil inside the list
> >> is relative to the previous elements, and means "otherwise, don't".
> >> Does that make sense?
> >
> > It might make sense, if we change the labels to say what you tell
> > above.
> >
> > Thanks.
>
> OK, here's an updated patch with revised labels:
Thanks, but I find the likes of "By default, enable" not clear enough.
Would it be accurate to say this instead:
(const :tag "Enable in any other mode" t)
(const :tag "Don't enable in the other modes" nil)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 16:35:04 GMT)
Full text and
rfc822 format available.
Message #26 received at 70589 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 70589 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>> Date: Fri, 26 Apr 2024 14:24:42 +0200
>>
>> >> These are slightly different: a value of t ("Enable in all major modes")
>> >> says to enable everywhere, while a t inside a list ("All major modes")
>> >> says to enable in modes that were not mentioned earlier in the list (so
>> >> putting t in the end of the list means "otherwise, enable"). Similarly
>> >> for the "none" alternatives: a value of nil ("Don't enable...") means we
>> >> never enable the minor mode, while the effect of a nil inside the list
>> >> is relative to the previous elements, and means "otherwise, don't".
>> >> Does that make sense?
>> >
>> > It might make sense, if we change the labels to say what you tell
>> > above.
>> >
>> > Thanks.
>>
>> OK, here's an updated patch with revised labels:
>
> Thanks, but I find the likes of "By default, enable" not clear enough.
> Would it be accurate to say this instead:
>
> (const :tag "Enable in any other mode" t)
> (const :tag "Don't enable in the other modes" nil)
That could also work, but I think this wording is a bit confusing when
entering the first list element (so there are no "other mode/s" yet).
If you think it's nevertheless preferable, I don't object.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 17:17:12 GMT)
Full text and
rfc822 format available.
Message #29 received at 70589 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 70589 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Fri, 26 Apr 2024 18:34:20 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Eshel Yaron <me <at> eshelyaron.com>
> >> Cc: 70589 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> >> Date: Fri, 26 Apr 2024 14:24:42 +0200
> >>
> >> >> These are slightly different: a value of t ("Enable in all major modes")
> >> >> says to enable everywhere, while a t inside a list ("All major modes")
> >> >> says to enable in modes that were not mentioned earlier in the list (so
> >> >> putting t in the end of the list means "otherwise, enable"). Similarly
> >> >> for the "none" alternatives: a value of nil ("Don't enable...") means we
> >> >> never enable the minor mode, while the effect of a nil inside the list
> >> >> is relative to the previous elements, and means "otherwise, don't".
> >> >> Does that make sense?
> >> >
> >> > It might make sense, if we change the labels to say what you tell
> >> > above.
> >> >
> >> > Thanks.
> >>
> >> OK, here's an updated patch with revised labels:
> >
> > Thanks, but I find the likes of "By default, enable" not clear enough.
> > Would it be accurate to say this instead:
> >
> > (const :tag "Enable in any other mode" t)
> > (const :tag "Don't enable in the other modes" nil)
>
> That could also work, but I think this wording is a bit confusing when
> entering the first list element (so there are no "other mode/s" yet).
> If you think it's nevertheless preferable, I don't object.
Feel free to suggest a better wording, that caters also to that
special situation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 17:56:12 GMT)
Full text and
rfc822 format available.
Message #32 received at 70589 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Thanks, but I find the likes of "By default, enable" not clear enough.
>> > Would it be accurate to say this instead:
>> >
>> > (const :tag "Enable in any other mode" t)
>> > (const :tag "Don't enable in the other modes" nil)
>>
>> That could also work, but I think this wording is a bit confusing when
>> entering the first list element (so there are no "other mode/s" yet).
>> If you think it's nevertheless preferable, I don't object.
>
> Feel free to suggest a better wording, that caters also to that
> special situation.
Hmm, how about "Enable in all (other) modes" and "Don't enable in any
(other) mode"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Fri, 26 Apr 2024 18:31:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 70589 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 70589 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Fri, 26 Apr 2024 19:55:05 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> > Thanks, but I find the likes of "By default, enable" not clear enough.
> >> > Would it be accurate to say this instead:
> >> >
> >> > (const :tag "Enable in any other mode" t)
> >> > (const :tag "Don't enable in the other modes" nil)
> >>
> >> That could also work, but I think this wording is a bit confusing when
> >> entering the first list element (so there are no "other mode/s" yet).
> >> If you think it's nevertheless preferable, I don't object.
> >
> > Feel free to suggest a better wording, that caters also to that
> > special situation.
>
> Hmm, how about "Enable in all (other) modes" and "Don't enable in any
> (other) mode"?
Fine with me, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Sat, 27 Apr 2024 07:01:14 GMT)
Full text and
rfc822 format available.
Message #38 received at 70589 <at> debbugs.gnu.org (full text, mbox):
> Cc: 70589 <at> debbugs.gnu.org
> Date: Fri, 26 Apr 2024 13:56:50 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Date: Fri, 26 Apr 2024 11:49:19 +0200
> > From: Eshel Yaron via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Sat, 27 Apr 2024 14:34:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 70589 <at> debbugs.gnu.org (full text, mbox):
>> > 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, 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.
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
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.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Sat, 27 Apr 2024 15:36:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 70589 <at> debbugs.gnu.org (full text, mbox):
close 70589 30.1
quit
Stefan Monnier <monnier <at> 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.
bug marked as fixed in version 30.1, send any further explanations to
70589 <at> debbugs.gnu.org and Eshel Yaron <me <at> eshelyaron.com>
Request was from
Eshel Yaron <me <at> eshelyaron.com>
to
control <at> debbugs.gnu.org.
(Sat, 27 Apr 2024 15:36:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Sat, 27 Apr 2024 15:49:01 GMT)
Full text and
rfc822 format available.
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Sat, 27 Apr 2024 15:49:02 GMT)
Full text and
rfc822 format available.
bug No longer marked as fixed in versions 30.1 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 27 Apr 2024 15:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Sat, 27 Apr 2024 21:04:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 70589 <at> debbugs.gnu.org (full text, mbox):
>> 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.
FWIW, I think we can close it: the bug was about improving the Custom
type and that's done.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70589; Package
emacs.
(Sun, 28 Apr 2024 19:08:03 GMT)
Full text and
rfc822 format available.
Message #60 received at 70589 <at> debbugs.gnu.org (full text, mbox):
close 70589 30.1
quit
Stefan Monnier <monnier <at> iro.umontreal.ca> 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.
>
> FWIW, I think we can close it: the bug was about improving the Custom
> type and that's done.
All right then, closing again :)
bug marked as fixed in version 30.1, send any further explanations to
70589 <at> debbugs.gnu.org and Eshel Yaron <me <at> eshelyaron.com>
Request was from
Eshel Yaron <me <at> eshelyaron.com>
to
control <at> debbugs.gnu.org.
(Sun, 28 Apr 2024 19:08:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 27 May 2024 11:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 21 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.