bug#41742: 28.0.50; Derive gnus-edit-form-mode from lisp-data-mode

[Eric Abrahamsen]

On 06/06/20 23:31 PM, Basil L. Contovounesios wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> "Basil L. Contovounesios" <contovob@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
Description: Text Data