Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Stefan Monnier]

>     * packages/gnugo/gnugo.el (gnugo-board-mode-map):
>     Delete defvar; move init to top-level, prior to ‘provide’
>     form; conditionalize init on expected ‘?’ binding.

Hmm... I have been installing the exact reverse change in many packages
of the years.  IOW this changes "idiomatic code" to "non-idiomatic code".
Both options have advantages and disadvantages, so I'm curious why you
prefer the non-idiomatic way,


        Stefan

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]


() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Wed, 08 Feb 2017 17:28:44 -0500

   why you prefer the non-idiomatic way

I don't know what to call idiomatic or non-idiomatic.  I simply
try to muddle through (i.e., survive w/o {add,los}ing many gray
hairs) the evolution of Emacs.  In the old days, the model was:

 (defvar MODE-map nil)                    ; model A
 (defun MODE () ...)
 (unless MODE-map
   (setq MODE-amp INIT))

This and the byte-compiled result worked fine for many years,
satisfying the design goals: (a) declare once; (b) init once,
even during re-‘load’ (to avoid clobbering customizations); (c)
init only after commands are defined.  Aside: (c) is arguably
non-idiomatic to begin w/ for Emacs Lisp; it's a personal
aesthetic born from exposure to C and Guile, where keeping
definitions topologically sorted makes for less-cluttered code.

Then, at some point ‘define-derived-mode’ was introduced and i
tried the modified model:

 (defvar MODE-map nil)                    ; model B
 (define-derived-mode MODE ...)
 (unless MODE-map
   (setq MODE-map INIT))

This worked sometimes, but not others.  I suspect the times it
didn't work were when byte-compiling substituted the ‘nil’ in
the declaration for ‘(make-sparse-keymap)’, resulting in the
‘unless’ CONDITION evaluating to true and thus precluding init.

Rather than investigate further, i vaguely recall reluctantly
forgoing design goal (c) and adopting the model:

 (defvar MODE-map INIT)                   ; model C
 (define-derived-mode MODE ...)

The comment in the removed INIT in the patch (in Subject) shows
some of the hand-wringing involved w/ the B-C transition.  What
i (somewhat stupidly) didn't realize at the time is that using
‘define-derived-mode’ (models B and later) already departs from
design goal (a).  So that brings us to the present model:

 (define-derived-mode MODE ...)           ; model D
 (unless EXPECTED-MODE-map-BINDING
   (INITIALZE MODE-map))

which once again supports all three design goals, though less
perfectly (CONDITION was algorithmic, now heuristic) than model
A.  I think in this case, the chosen CONDITION is close enough.

Anyway, i especially enjoy the reduction in forms, which is what
i imagine the introduction of ‘define-derived-mode’ was supposed
to achieve.  Pruned profligacy for perplexable programmers!  :-D

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical mailing-list) t)
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Stefan Monnier]

>  (defvar MODE-map INIT)                   ; model C
>  (define-derived-mode MODE ...)

This is the idiomatic form.

The main benefit is that there's a clear place where the mode map is
defined and `C-h o` will get you there.

> The comment in the removed INIT in the patch (in Subject) shows
> some of the hand-wringing involved w/ the B-C transition.  What

The only thing I see in that comment is that you see something ugly, and
that maybe this aesthetic problem is due to the use forward references.

So, is it fair to say that the reason for the patch was to avoid those
forward references?

>  (unless EXPECTED-MODE-map-BINDING

Of course, this misfires if the user wants to change this
EXPECTED-MODE-map-BINDING binding ;-)


        Stefan

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]


() Stefan Monnier <monnier@iro.umontreal.ca>
() Thu, 09 Feb 2017 13:02:22 -0500

   >  (defvar MODE-map INIT)                   ; model C
   >  (define-derived-mode MODE ...)

   This is the idiomatic form.

OK, noted.

   The main benefit is that there's a clear place where the mode
   map is defined and `C-h o` will get you there.

Thanks for the tip.  ‘C-h o’ is new to me.  That's indeed a nice
benefit.

   aesthetic problem is due
   to the use forward references.

   So, is it fair to say that the reason for the patch was to
   avoid those forward references?

Yes, exactly.

   >  (unless EXPECTED-MODE-map-BINDING

   Of course, this misfires if the user wants to change this
   EXPECTED-MODE-map-BINDING binding ;-)

True, that's the risk.

I'll release, wait a year or two for complaints, and revisit the
decision then -- perhaps ‘C-h o’ will in the meantime learn how
to accomodate some non-idiomatic forms, such as this one.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Stefan Monnier]

>    The main benefit is that there's a clear place where the mode
>    map is defined and `C-h o` will get you there.
> Thanks for the tip.  ‘C-h o’ is new to me.

It's indeed newish, but it's just a combination of C-h f and C-h v.
C-h v would also get you there: I just used `C-h o` because I'm trying
to advertise this new functionality.

> I'll release, wait a year or two for complaints, and revisit the
> decision then -- perhaps ‘C-h o’ will in the meantime learn how
> to accomodate some non-idiomatic forms, such as this one.

`C-h o` and `C-h v` work by making you jump to "the definition" but in
your case, "the definition" is in define-derived-mode and is just not
very interesting.  `C-h v` might get there, but that's not what the user
wants to see.  Instead she'll probably want to see the place where the
default bindings are set up, but it's difficult for Emacs to distinguish
a define-key executed within your `if` from a define-key executed
anywhere else, and it's even more difficult for Emacs to guess that your
`if` test is trying to guess if the map is already defined.  So there's
very little hope for `C-h o` to improve in this respect.


        Stefan

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]


() Stefan Monnier <monnier@iro.umontreal.ca>
() Tue, 14 Feb 2017 09:04:56 -0500

   `C-h o` and `C-h v` work by making you jump to "the
   definition" but in your case, "the definition" is in
   define-derived-mode and is just not very interesting.

I see.

   ["definition" search obstacles].  So there's very little
   hope for `C-h o` to improve in this respect.

It's good enough for ‘C-h o’ to find ‘define-derived-mode’.  I
expect someone will make it so sooner or later, in the name of
Emacs cohesion.

For gnugo.el, i've installed a small comment intended to help
anyone who gets to the ‘define-derived-mode’ to make the last
step in the search, and will do likewise for other (personal)
code.  Perhaps if enough people adopt this convention, it will
become "alternative idiomatic"... :-D

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Do., 9. Feb. 2017 um
19:02 Uhr:

> >  (defvar MODE-map INIT)                   ; model C
> >  (define-derived-mode MODE ...)
>
> This is the idiomatic form.
>

If that's the case, could you please describe this convention in
https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html
and
fix the example there? Thanks.

[-- Attachment #2: Type: text/html, Size: 866 bytes --]

Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars.

[Stefan Monnier]

> If that's the case, could you please describe this convention in
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html
> and
> fix the example there? Thanks.

I fixed the example, thanks,


        Stefan