GNU bug report logs - #24774
26.0.50; Menu display navigation commands

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: stephen.berman <at> gmx.net, stefan <at> marxist.se, 24774 <at> debbugs.gnu.org
Subject: bug#24774: 26.0.50; Menu display navigation commands
Date: Sat, 27 Feb 2021 09:43:55 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stephen.berman <at> gmx.net,  stefan <at> marxist.se,  24774 <at> 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 <at> 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 <at> 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).

Previous Next

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