GNU bug report logs - #41742
28.0.50; Derive gnus-edit-form-mode from lisp-data-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41742 in the body.
You can then email your comments to 41742 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Sat, 06 Jun 2020 12:23:52 -0700

[Message part 1 (text/plain, inline)]

Hopefully this is fairly uncontroversial: Gnus has a gnus-edit-form-mode
for editing group parameters and other things, which presents the data
as elisp forms and is a perfect use-case for lisp-data-mode -- turning
on paredit or what have you. This patch derives the former from the
latter.

Eric

[0001-Derive-gnus-edit-form-mode-from-lisp-data-mode.patch (text/x-patch, attachment)]

Message #8 received at 41742 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 41742 <at> debbugs.gnu.org
Subject: Re: bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Sat, 06 Jun 2020 21:06:10 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Hopefully this is fairly uncontroversial: Gnus has a gnus-edit-form-mode
> for editing group parameters and other things, which presents the data
> as elisp forms and is a perfect use-case for lisp-data-mode -- turning
> on paredit or what have you. This patch derives the former from the
> latter.

LGTM, FWIW.

While there, would you mind cleaning up how gnus-edit-form-mode-map is
defined?  It currently does a defvar+unless+setq dance, whereas it
should ideally only be a defvar+let, as per the last few paragraphs of
(info "(elisp) Tips for Defining").

Thanks,

-- 
Basil

Message #11 received at 41742 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 41742 <at> debbugs.gnu.org
Subject: Re: bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Sat, 06 Jun 2020 13:25:13 -0700

"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Hopefully this is fairly uncontroversial: Gnus has a gnus-edit-form-mode
>> for editing group parameters and other things, which presents the data
>> as elisp forms and is a perfect use-case for lisp-data-mode -- turning
>> on paredit or what have you. This patch derives the former from the
>> latter.
>
> LGTM, FWIW.
>
> While there, would you mind cleaning up how gnus-edit-form-mode-map is
> defined?  It currently does a defvar+unless+setq dance, whereas it
> should ideally only be a defvar+let, as per the last few paragraphs of
> (info "(elisp) Tips for Defining").

Huh, the last few paragraphs of that info page make it look like it's
_okay_ to do defvar+unless+setq, am I misreading this? Granted it only
says to do it so you can get the docstring closer to the defvar, and
there's no docstring in this case, but it does seem acceptable.

I wonder what the point of writing it this way is, otherwise?

Message #14 received at 41742 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 41742 <at> debbugs.gnu.org
Subject: Re: bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Sat, 06 Jun 2020 23:31:46 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> "Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
>
>> While there, would you mind cleaning up how gnus-edit-form-mode-map is
>> defined?  It currently does a defvar+unless+setq dance, whereas it
>> should ideally only be a defvar+let, as per the last few paragraphs of
>> (info "(elisp) Tips for Defining").
>
> Huh, the last few paragraphs of that info page make it look like it's
> _okay_ to do defvar+unless+setq, am I misreading this? Granted it only
> says to do it so you can get the docstring closer to the defvar, and
> there's no docstring in this case, but it does seem acceptable.

I posit it's always better to defvar+let in one swell foop.

> I wonder what the point of writing it this way is, otherwise?

In most places I've seen defvar+unless, it's due to the author thinking
in terms of "if the user hasn't already defined this map before loading
this file, then..."

But defvar provides these semantics for free and in a cleaner way.

Unless I'm missing something, that is.

-- 
Basil

Message #17 received at 41742 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 41742 <at> debbugs.gnu.org
Subject: Re: bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Sat, 06 Jun 2020 16:34:50 -0700

[Message part 1 (text/plain, inline)]

On 06/06/20 23:31 PM, Basil L. Contovounesios wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> "Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
>>
>>> While there, would you mind cleaning up how gnus-edit-form-mode-map is
>>> defined?  It currently does a defvar+unless+setq dance, whereas it
>>> should ideally only be a defvar+let, as per the last few paragraphs of
>>> (info "(elisp) Tips for Defining").
>>
>> Huh, the last few paragraphs of that info page make it look like it's
>> _okay_ to do defvar+unless+setq, am I misreading this? Granted it only
>> says to do it so you can get the docstring closer to the defvar, and
>> there's no docstring in this case, but it does seem acceptable.
>
> I posit it's always better to defvar+let in one swell foop.

In principle, I agree.

>> I wonder what the point of writing it this way is, otherwise?
>
> In most places I've seen defvar+unless, it's due to the author thinking
> in terms of "if the user hasn't already defined this map before loading
> this file, then..."
>
> But defvar provides these semantics for free and in a cleaner way.
>
> Unless I'm missing something, that is.

I can't imagine anyone actually defining the whole map in their own
config, rather than just adding keybindings as necessary. And as you
(and the manual) point out, defvar already handles atomic
definition/double loading avoidance, etc.

Here's another version...

[0001-Derive-gnus-edit-form-mode-from-lisp-data-mode-fix-m.patch (text/x-patch, attachment)]

Message #20 received at 41742 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 41742 <at> debbugs.gnu.org
Subject: Re: bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Sun, 07 Jun 2020 00:41:32 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Here's another version...

Thanks, LGTM except for one tiny nit.

> From 0ee576ed0819a15a37a01e2b3a3bc176e9827c04 Mon Sep 17 00:00:00 2001
> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Date: Sat, 6 Jun 2020 12:13:15 -0700
> Subject: [PATCH] Derive gnus-edit-form-mode from lisp-data-mode, fix mode map
>
> * lisp/gnus/gnus-eform.el (gnus-edit-form-mode): Handy for users who
> have turned on things like paredit for lisp-data-mode.

I'd say "Derive from lisp-data-mode" here as well, since the sentence
does not otherwise stand on its own without the preceding commit
summary's context.

-- 
Basil

Message #23 received at 41742 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 41742 <at> debbugs.gnu.org
Subject: Re: bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Sat, 06 Jun 2020 16:46:05 -0700

On 06/07/20 00:41 AM, Basil L. Contovounesios wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Here's another version...
>
> Thanks, LGTM except for one tiny nit.
>
>> From 0ee576ed0819a15a37a01e2b3a3bc176e9827c04 Mon Sep 17 00:00:00 2001
>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Date: Sat, 6 Jun 2020 12:13:15 -0700
>> Subject: [PATCH] Derive gnus-edit-form-mode from lisp-data-mode, fix mode map
>>
>> * lisp/gnus/gnus-eform.el (gnus-edit-form-mode): Handy for users who
>> have turned on things like paredit for lisp-data-mode.
>
> I'd say "Derive from lisp-data-mode" here as well, since the sentence
> does not otherwise stand on its own without the preceding commit
> summary's context.

Sure! I've made the change locally. I'll wait a few days for possible
objections (though I don't expect any) and then push.

Thanks,
Eric

Message #26 received at 41742 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 41742 <at> debbugs.gnu.org, 41742-done <at> debbugs.gnu.org
Subject: Re: bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode
Date: Fri, 12 Jun 2020 09:30:54 -0700

On 06/07/20 00:41 AM, Basil L. Contovounesios wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Here's another version...
>
> Thanks, LGTM except for one tiny nit.
>
>> From 0ee576ed0819a15a37a01e2b3a3bc176e9827c04 Mon Sep 17 00:00:00 2001
>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Date: Sat, 6 Jun 2020 12:13:15 -0700
>> Subject: [PATCH] Derive gnus-edit-form-mode from lisp-data-mode, fix mode map
>>
>> * lisp/gnus/gnus-eform.el (gnus-edit-form-mode): Handy for users who
>> have turned on things like paredit for lisp-data-mode.
>
> I'd say "Derive from lisp-data-mode" here as well, since the sentence
> does not otherwise stand on its own without the preceding commit
> summary's context.

Done, and pushed. Thanks!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.