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

Previous Next

Full log

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?

Previous Next

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