bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stephen.berman@gmx.net,  stefan@marxist.se,  24774@debbugs.gnu.org
> Date: Sat, 27 Feb 2021 05:30:39 +0100
> 
> > But the same argument can be brought up for cl-macs.el and cl-lib.el
> > and seq.el and map.el and pcase.el and probably several others.
> 
> Yes, of course.
> 
> > Where do we stop, if the criterion is "better and more sensible"
> > (which are highly subjective judgments)?
> 
> I don't think anybody claims that the non-easymenu way of defining menus
> is superior?

It isn't a catastrophe, IMO, not even close.  Non-easymenu:

    (bindings--define-key prof-map [prof-natprof-stop]
      '(menu-item "Stop Native Profiler" profiler-stop
                  :help "Stop recording profiling information"
                  :enable (and (featurep 'profiler)
                               (profiler-running-p))))

With easymenu:

    ["Show trailing whitespace" whitespace-mode
     :style toggle :selected (bound-and-true-p whitespace-mode)
     :help "Show trailing whitespace in modified lines"]

There's some boilerplate in the former, but it isn't unreadable, and
writing it is just a bunch of C-y's in addition to the actual content,
which must be typed in both cases.  It isn't superior, but is it so
awfully inferior? I don't think so.

> Our most important code is the one that is in the very core of Emacs,
> and it's a shame we don't use more of these libraries there, and instead
> open-code stuff badly.

I disagree with "shame" and "badly".  Next we will see similar
arguments about all the other packages mentioned above.

Again, I think we should agree on some criteria, because otherwise we
will not be able to reconcile subjective opinions about stylistic
issues.

> > I'd like to see the actual numbers, please.  And also the memory
> > footprint before and after loading easymenu.  With the current code, I
> > see a 0.25MB increase in the VM size after I load easymenu.elc.
> 
> Pre patch:
> 
> larsi@xo:~/src/emacs/trunk$ ls -l src/emacs src/emacs.pdmp 
> lisp/progmodes/elisp-mode.elc
> -rw-r--r-- 1 larsi larsi    60375 Feb 27 05:09 lisp/progmodes/elisp-mode.elc
> -rwxr-xr-x 2 larsi larsi 32583784 Feb 27 05:10 src/emacs
> -rw-r--r-- 2 larsi larsi 10630544 Feb 27 05:10 src/emacs.pdmp
> 
> Post patch:
> 
> larsi@xo:~/src/emacs/trunk$ ls -l src/emacs src/emacs.pdmp 
> lisp/progmodes/elisp-mode.elc
> -rw-r--r-- 1 larsi larsi    58798 Feb 27 05:21 lisp/progmodes/elisp-mode.elc
> -rwxr-xr-x 2 larsi larsi 32583784 Feb 27 05:21 src/emacs
> -rw-r--r-- 2 larsi larsi 10632360 Feb 27 05:21 src/emacs.pdmp
> 
> (- (+ 10632360 58798) (+ 10630544 60375)) => 239 bytes.

Thanks, but I meant the runtime memory footprint, not the size on disk
(which IMO is of no importance, as long as small savings are being
discussed).