bug#24774: 26.0.50; Menu display navigation commands

bug#24774: 26.0.50; Menu display navigation commands

[Andreas Röhler]

Hi,

think it would be a gain if Emacs-lisp menu displays navigation commands.

Thanks,

Andreas
GNU Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-10-11

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
   value of $LANG: de_DE.utf8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 8 169065 8354)
  (symbols 24 38597 0)
  (miscs 20 41 160)
  (strings 16 53551 4976)
  (string-bytes 1 873524)
  (vectors 8 13713)
  (vector-slots 4 474922 6778)
  (floats 8 183 30)
  (intervals 28 197 8)
  (buffers 520 12)
  (heap 1024 18127 894))

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> think it would be a gain if Emacs-lisp menu displays navigation commands.

What kind of navigation commands?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Andreas Röhler]

On 27.07.19 15:18, Lars Ingebrigtsen wrote:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> think it would be a gain if Emacs-lisp menu displays navigation commands.
> What kind of navigation commands?
>

Stuff like beginning-of-defun, up-list, forward-sexp


Thanks,

Andreas

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> On 27.07.19 15:18, Lars Ingebrigtsen wrote:
>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>
>>> think it would be a gain if Emacs-lisp menu displays navigation commands.
>> What kind of navigation commands?
>
> Stuff like beginning-of-defun, up-list, forward-sexp

Oh, sexp-based navigation commands.  Yes, I think that's a good idea --
it'll make them more discoverable for new users.  I think both an
"Editing" sub-menu (`kill-sexp' etc) as well as a "Navigation" menu
would be nice.

Eep!

    (bindings--define-key menu-map [separator-format] menu-bar-separator)
    (bindings--define-key menu-map [comment-region]
      '(menu-item "Comment Out Region" comment-region
		  :help "Comment or uncomment each line in the region"
		  :enable mark-active))
    (bindings--define-key menu-map [indent-region]
      '(menu-item "Indent Region" indent-region
		  :help "Indent each nonblank line in the region"
		  :enable mark-active))

(ad nauseam).  elisp-mode.el doesn't use easy-menu, so every creating
menus there is so. much. typing.  And the file is dumped with Emacs, so
I'm guessing requiring easy-menu and doing a rewrite wouldn't be
welcome?

So while I agree that these sub-menus should be added, I think I'll
leave that to somebody else...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Stuff like beginning-of-defun, up-list, forward-sexp
>
> Oh, sexp-based navigation commands.  Yes, I think that's a good idea --
> it'll make them more discoverable for new users.  I think both an
> "Editing" sub-menu (`kill-sexp' etc) as well as a "Navigation" menu
> would be nice.
>
> Eep!
>
>     (bindings--define-key menu-map [separator-format] menu-bar-separator)
>     (bindings--define-key menu-map [comment-region]
>       '(menu-item "Comment Out Region" comment-region
> 		  :help "Comment or uncomment each line in the region"
> 		  :enable mark-active))
>     (bindings--define-key menu-map [indent-region]
>       '(menu-item "Indent Region" indent-region
> 		  :help "Indent each nonblank line in the region"
> 		  :enable mark-active))
>
> (ad nauseam).  elisp-mode.el doesn't use easy-menu, so every creating
> menus there is so. much. typing.  And the file is dumped with Emacs, so
> I'm guessing requiring easy-menu and doing a rewrite wouldn't be
> welcome?
>
> So while I agree that these sub-menus should be added, I think I'll
> leave that to somebody else...

Is preloading easy-menu.el excluded?

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Is preloading easy-menu.el excluded?

If I do an "emacs -Q", then it turns out that easymenu.el is already
present, so I think something is already loading it (even if it's not
explicitly mentioned by lisp/loadup.el).

So rewriting the emacs-lisp menus using easymenu should be
uncontroversial.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Drew Adams]

> So rewriting the emacs-lisp menus using easymenu should be
> uncontroversial.

Really?  _Why_ rewrite them?

And easy-menu doesn't offer all that an "extended menu
item' offers.  What would be the point of rewriting to
use easy-menu.

I actually find easy-menu harder to work with, FWIW.
It's too monolithic.  Ordinary menu bindings are
individual, essentially independent.  The easy-menu
functions seem too all-or-nothing.

(I'm no expert on easy-menu, so some of my view of it
might be mistaken.  It just seems to me more of a pain
than a help, when trying to adapt or adjust some "easy"
menu that already exists.)

And what on earth does rewriting Elisp menus to use
easy-menu have to do with this bug?

This sounds like a solution (something you're perhaps
more used to) in search of a problem.

bug#24774: 26.0.50; Menu display navigation commands

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> So rewriting the emacs-lisp menus using easymenu should be
>> uncontroversial.
>
> Really?  _Why_ rewrite them?

They would be easier to read, understand and change.

bug#24774: 26.0.50; Menu display navigation commands

[Drew Adams]

> >> So rewriting the emacs-lisp menus using easymenu should be
> >> uncontroversial.
> >
> > Really?  _Why_ rewrite them?
> 
> They would be easier to read, understand and change.

Easier for whom?

I don't find maintenance easier with easy-menu.  I find
it harder.  Of course my "maintenance" of existing Emacs
menus means adding to, or otherwise changing, them.

(How do you do the equivalent of a `define-key-after',
for example?  Oh, or is there no equivalent?) 

bug#24774: 26.0.50; Menu display navigation commands

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> (How do you do the equivalent of a `define-key-after',
> for example?  Oh, or is there no equivalent?)

I'm not sure why you can't use `define-key-after', but there is also
`easy-menu-define-key'.

bug#24774: 26.0.50; Menu display navigation commands

[Stefan Kangas]

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

tags 24774 + patch
thanks

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> Is preloading easy-menu.el excluded?
>
> If I do an "emacs -Q", then it turns out that easymenu.el is already
> present, so I think something is already loading it (even if it's not
> explicitly mentioned by lisp/loadup.el).
>
> So rewriting the emacs-lisp menus using easymenu should be
> uncontroversial.

How do the attached patches look?

[-- Attachment #2: 0001-Preload-easymenu.el.patch --]
[-- Type: text/x-diff, Size: 2199 bytes --]

From 73e00b8517ec97e5c7c6041eab30b4b0ddfb5d30 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Thu, 19 Nov 2020 02:19:19 +0100
Subject: [PATCH 1/2] Preload easymenu.el

* lisp/loadup.el: Preload easymenu.  It turns out that it is already
loaded in a default Emacs 27.
---
 lisp/emacs-lisp/easymenu.el | 4 ----
 lisp/loadup.el              | 1 +
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/lisp/emacs-lisp/easymenu.el b/lisp/emacs-lisp/easymenu.el
index bcd5cfd99b..68b0a27b6a 100644
--- a/lisp/emacs-lisp/easymenu.el
+++ b/lisp/emacs-lisp/easymenu.el
@@ -35,7 +35,6 @@
 (defsubst easy-menu-intern (s)
   (if (stringp s) (intern s) s))
 
-;;;###autoload
 (defmacro easy-menu-define (symbol maps doc menu)
   "Define a pop-up menu and/or menu bar menu specified by MENU.
 If SYMBOL is non-nil, define SYMBOL as a function to pop up the
@@ -166,7 +165,6 @@ easy-menu-binding
                       ""))
                 (cons menu props)))))
 
-;;;###autoload
 (defun easy-menu-do-define (symbol maps doc menu)
   ;; We can't do anything that might differ between Emacs dialects in
   ;; `easy-menu-define' in order to make byte compiled files
@@ -218,7 +216,6 @@ easy-menu-avoid-duplicate-keys
 If it holds a list, this is expected to be a list of keys already seen in the
 menu we're processing.  Else it means we're not processing a menu.")
 
-;;;###autoload
 (defun easy-menu-create-menu (menu-name menu-items)
   "Create a menu called MENU-NAME with items described in MENU-ITEMS.
 MENU-NAME is a string, the name of the menu.  MENU-ITEMS is a list of items
@@ -474,7 +471,6 @@ easy-menu-make-symbol
 	    (eval `(lambda () (interactive) ,callback) t)))
     command))
 
-;;;###autoload
 (defun easy-menu-change (path name items &optional before map)
   "Change menu found at PATH as item NAME to contain ITEMS.
 PATH is a list of strings for locating the menu that
diff --git a/lisp/loadup.el b/lisp/loadup.el
index d60aa2ead2..c16cd61594 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -266,6 +266,7 @@
 (load "isearch")
 (load "rfn-eshadow")
 
+(load "emacs-lisp/easymenu")
 (load "menu-bar")
 (load "tab-bar")
 (load "emacs-lisp/lisp")
-- 
2.30.0


[-- Attachment #3: 0002-Convert-emacs-lisp-mode-menu-to-easy-menu-define.patch --]
[-- Type: text/x-diff, Size: 12273 bytes --]

From 7613470112b5a5bcb492f1adda2947052b1e07c8 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Tue, 23 Feb 2021 15:51:16 +0100
Subject: [PATCH 2/2] Convert emacs-lisp-mode menu to easy-menu-define

* lisp/progmodes/elisp-mode.el (emacs-lisp-mode-map): Convert menu to
use easy-menu-define.
---
 lisp/progmodes/elisp-mode.el | 215 +++++++++++++++--------------------
 1 file changed, 89 insertions(+), 126 deletions(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 397eb269a7..9532cf692e 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -46,140 +46,103 @@ emacs-lisp-mode-syntax-table
   "Syntax table used in `emacs-lisp-mode'.")
 
 (defvar emacs-lisp-mode-map
-  (let ((map (make-sparse-keymap))
-	(menu-map (make-sparse-keymap "Emacs-Lisp"))
-	(lint-map (make-sparse-keymap))
-	(prof-map (make-sparse-keymap))
-	(tracing-map (make-sparse-keymap)))
+  (let ((map (make-sparse-keymap)))
     (set-keymap-parent map lisp-mode-shared-map)
     (define-key map "\e\t" 'completion-at-point)
     (define-key map "\e\C-x" 'eval-defun)
     (define-key map "\e\C-q" 'indent-pp-sexp)
-    (bindings--define-key map [menu-bar emacs-lisp]
-      (cons "Emacs-Lisp" menu-map))
-    (bindings--define-key menu-map [eldoc]
-      '(menu-item "Auto-Display Documentation Strings" eldoc-mode
-		  :button (:toggle . (bound-and-true-p eldoc-mode))
-		  :help "Display the documentation string for the item under cursor"))
-    (bindings--define-key menu-map [checkdoc]
-      '(menu-item "Check Documentation Strings" checkdoc
-		  :help "Check documentation strings for style requirements"))
-    (bindings--define-key menu-map [re-builder]
-      '(menu-item "Construct Regexp" re-builder
-		  :help "Construct a regexp interactively"))
-    (bindings--define-key menu-map [tracing] (cons "Tracing" tracing-map))
-    (bindings--define-key tracing-map [tr-a]
-      '(menu-item "Untrace All" untrace-all
-		  :help "Untrace all currently traced functions"))
-    (bindings--define-key tracing-map [tr-uf]
-      '(menu-item "Untrace Function..." untrace-function
-		  :help "Untrace function, and possibly activate all remaining advice"))
-    (bindings--define-key tracing-map [tr-sep] menu-bar-separator)
-    (bindings--define-key tracing-map [tr-q]
-      '(menu-item "Trace Function Quietly..." trace-function-background
-		  :help "Trace the function with trace output going quietly to a buffer"))
-    (bindings--define-key tracing-map [tr-f]
-      '(menu-item "Trace Function..." trace-function
-		  :help "Trace the function given as an argument"))
-    (bindings--define-key menu-map [profiling] (cons "Profiling" prof-map))
-    (bindings--define-key prof-map [prof-restall]
-      '(menu-item "Remove Instrumentation for All Functions" elp-restore-all
-		  :help "Restore the original definitions of all functions being profiled"))
-    (bindings--define-key prof-map [prof-restfunc]
-      '(menu-item "Remove Instrumentation for Function..." elp-restore-function
-		  :help "Restore an instrumented function to its original definition"))
-
-    (bindings--define-key prof-map [sep-rem] menu-bar-separator)
-    (bindings--define-key prof-map [prof-resall]
-      '(menu-item "Reset Counters for All Functions" elp-reset-all
-		  :help "Reset the profiling information for all functions being profiled"))
-    (bindings--define-key prof-map [prof-resfunc]
-      '(menu-item "Reset Counters for Function..." elp-reset-function
-		  :help "Reset the profiling information for a function"))
-    (bindings--define-key prof-map [prof-res]
-      '(menu-item "Show Profiling Results" elp-results
-		  :help "Display current profiling results"))
-    (bindings--define-key prof-map [prof-pack]
-      '(menu-item "Instrument Package..." elp-instrument-package
-		  :help "Instrument for profiling all function that start with a prefix"))
-    (bindings--define-key prof-map [prof-func]
-      '(menu-item "Instrument Function..." elp-instrument-function
-		  :help "Instrument a function for profiling"))
-    ;; Maybe this should be in a separate submenu from the ELP stuff?
-    (bindings--define-key prof-map [sep-natprof] menu-bar-separator)
-    (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))))
-    (bindings--define-key prof-map [prof-natprof-report]
-      '(menu-item "Show Profiler Report" profiler-report
-		  :help "Show the current profiler report"
-		  :enable (and (featurep 'profiler)
-			       (profiler-running-p))))
-    (bindings--define-key prof-map [prof-natprof-start]
-      '(menu-item "Start Native Profiler..." profiler-start
-		  :help "Start recording profiling information"))
-
-    (bindings--define-key menu-map [lint] (cons "Linting" lint-map))
-    (bindings--define-key lint-map [lint-di]
-      '(menu-item "Lint Directory..." elint-directory
-		  :help "Lint a directory"))
-    (bindings--define-key lint-map [lint-f]
-      '(menu-item "Lint File..." elint-file
-		  :help "Lint a file"))
-    (bindings--define-key lint-map [lint-b]
-      '(menu-item "Lint Buffer" elint-current-buffer
-		  :help "Lint the current buffer"))
-    (bindings--define-key lint-map [lint-d]
-      '(menu-item "Lint Defun" elint-defun
-		  :help "Lint the function at point"))
-    (bindings--define-key menu-map [edebug-defun]
-      '(menu-item "Instrument Function for Debugging" edebug-defun
-		  :help "Evaluate the top level form point is in, stepping through with Edebug"
-		  :keys "C-u C-M-x"))
-    (bindings--define-key menu-map [separator-byte] menu-bar-separator)
-    (bindings--define-key menu-map [disas]
-      '(menu-item "Disassemble Byte Compiled Object..." disassemble
-		  :help "Print disassembled code for OBJECT in a buffer"))
-    (bindings--define-key menu-map [byte-recompile]
-      '(menu-item "Byte-recompile Directory..." byte-recompile-directory
-		  :help "Recompile every `.el' file in DIRECTORY that needs recompilation"))
-    (bindings--define-key menu-map [emacs-byte-compile-and-load]
-      '(menu-item "Byte-compile and Load" emacs-lisp-byte-compile-and-load
-		  :help "Byte-compile the current file (if it has changed), then load compiled code"))
-    (bindings--define-key menu-map [byte-compile]
-      '(menu-item "Byte-compile This File" emacs-lisp-byte-compile
-		  :help "Byte compile the file containing the current buffer"))
-    (bindings--define-key menu-map [separator-eval] menu-bar-separator)
-    (bindings--define-key menu-map [ielm]
-      '(menu-item "Interactive Expression Evaluation" ielm
-		  :help "Interactively evaluate Emacs Lisp expressions"))
-    (bindings--define-key menu-map [eval-buffer]
-      '(menu-item "Evaluate Buffer" eval-buffer
-		  :help "Execute the current buffer as Lisp code"))
-    (bindings--define-key menu-map [eval-region]
-      '(menu-item "Evaluate Region" eval-region
-		  :help "Execute the region as Lisp code"
-		  :enable mark-active))
-    (bindings--define-key menu-map [eval-sexp]
-      '(menu-item "Evaluate Last S-expression" eval-last-sexp
-		  :help "Evaluate sexp before point; print value in echo area"))
-    (bindings--define-key menu-map [separator-format] menu-bar-separator)
-    (bindings--define-key menu-map [comment-region]
-      '(menu-item "Comment Out Region" comment-region
-		  :help "Comment or uncomment each line in the region"
-		  :enable mark-active))
-    (bindings--define-key menu-map [indent-region]
-      '(menu-item "Indent Region" indent-region
-		  :help "Indent each nonblank line in the region"
-		  :enable mark-active))
-    (bindings--define-key menu-map [indent-line]
-      '(menu-item "Indent Line" lisp-indent-line))
     map)
   "Keymap for Emacs Lisp mode.
 All commands in `lisp-mode-shared-map' are inherited by this map.")
 
+(easy-menu-define emacs-lisp-mode-menu emacs-lisp-mode-map
+  "Menu for Emacs Lisp mode."
+  '("Emacs-Lisp"
+    ["Indent Line" lisp-indent-line]
+    ["Indent Region" indent-region
+     :help "Indent each nonblank line in the region"
+     :active mark-active]
+    ["Comment Out Region" comment-region
+     :help "Comment or uncomment each line in the region"
+     :active mark-active]
+    "---"
+    ["Evaluate Last S-expression" eval-last-sexp
+     :help "Evaluate sexp before point; print value in echo area"]
+    ["Evaluate Region" eval-region
+     :help "Execute the region as Lisp code"
+     :active mark-active]
+    ["Evaluate Buffer" eval-buffer
+     :help "Execute the current buffer as Lisp code"]
+    ["Interactive Expression Evaluation" ielm
+     :help "Interactively evaluate Emacs Lisp expressions"]
+    "---"
+    ["Byte-compile This File" emacs-lisp-byte-compile
+     :help "Byte compile the file containing the current buffer"]
+    ["Byte-compile and Load" emacs-lisp-byte-compile-and-load
+     :help "Byte-compile the current file (if it has changed), then load compiled code"]
+    ["Byte-recompile Directory..." byte-recompile-directory
+     :help "Recompile every `.el' file in DIRECTORY that needs recompilation"]
+    ["Disassemble Byte Compiled Object..." disassemble
+     :help "Print disassembled code for OBJECT in a buffer"]
+    "---"
+    ["Instrument Function for Debugging" edebug-defun
+     :help "Evaluate the top level form point is in, stepping through with Edebug"
+     :keys "C-u C-M-x"]
+    ["Linting"
+     ["Lint Defun" elint-defun
+      :help "Lint the function at point"]
+     ["Lint Buffer" elint-current-buffer
+      :help "Lint the current buffer"]
+     ["Lint File..." elint-file
+      :help "Lint a file"]
+     ["Lint Directory..." elint-directory
+      :help "Lint a directory"]]
+    ["Profiling"
+     ;; Maybe this should be in a separate submenu from the ELP stuff?
+     ["Start Native Profiler..." profiler-start
+      :help "Start recording profiling information"]
+     ["Show Profiler Report" profiler-report
+      :help "Show the current profiler report"
+      :active (and (featurep 'profiler)
+                   (profiler-running-p))]
+     ["Stop Native Profiler" profiler-stop
+      :help "Stop recording profiling information"
+      :active (and (featurep 'profiler)
+                   (profiler-running-p))]
+     "---"
+     ["Instrument Function..." elp-instrument-function
+      :help "Instrument a function for profiling"]
+     ["Instrument Package..." elp-instrument-package
+      :help "Instrument for profiling all function that start with a prefix"]
+     ["Show Profiling Results" elp-results
+      :help "Display current profiling results"]
+     ["Reset Counters for Function..." elp-reset-function
+      :help "Reset the profiling information for a function"]
+     ["Reset Counters for All Functions" elp-reset-all
+      :help "Reset the profiling information for all functions being profiled"]
+     "---"
+     ["Remove Instrumentation for All Functions" elp-restore-all
+      :help "Restore the original definitions of all functions being profiled"]
+     ["Remove Instrumentation for Function..." elp-restore-function
+      :help "Restore an instrumented function to its original definition"]]
+    ["Tracing"
+     ["Trace Function..." trace-function
+      :help "Trace the function given as an argument"]
+     ["Trace Function Quietly..." trace-function-background
+      :help "Trace the function with trace output going quietly to a buffer"]
+     "---"
+     ["Untrace All" untrace-all
+      :help "Untrace all currently traced functions"]
+     ["Untrace Function..." untrace-function
+      :help "Untrace function, and possibly activate all remaining advice"]]
+    ["Construct Regexp" re-builder
+     :help "Construct a regexp interactively"]
+    ["Check Documentation Strings" checkdoc
+     :help "Check documentation strings for style requirements"]
+    ["Auto-Display Documentation Strings" eldoc-mode
+     :button (:toggle . (bound-and-true-p eldoc-mode))
+     :help "Display the documentation string for the item under cursor"]))
+
 (defun emacs-lisp-byte-compile ()
   "Byte compile the file containing the current buffer."
   (interactive)
-- 
2.30.0

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> So rewriting the emacs-lisp menus using easymenu should be
>> uncontroversial.
>
> How do the attached patches look?

Looks good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 23 Feb 2021 09:19:19 -0600
> Cc: 24774@debbugs.gnu.org
> 
> * lisp/loadup.el: Preload easymenu.  It turns out that it is already
> loaded in a default Emacs 27.

It is?  I don't see it in "emacs -Q".  It only gets loaded when
emacs-lisp-mode is activated.

So why do we need to preload it?

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It is?  I don't see it in "emacs -Q".  It only gets loaded when
> emacs-lisp-mode is activated.

emacs -Q
(featurep 'easymenu)
=> t

This is probably because *scratch* is an Emacs Lisp-derived mode, but it
means that it's usually loaded on startup, and emacs-lisp.el should be
able to use it, because the typical impact on users will be nil.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This is probably because *scratch* is an Emacs Lisp-derived mode, but it
> means that it's usually loaded on startup, and emacs-lisp.el should be
> able to use it, because the typical impact on users will be nil.

Sorry -- I meant that there is typically no negative impact on users,
but there is, of course, typically a positive impact on preloading
easymenu -- it means that Emacs will, invoked the typical way, start
faster.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefan@marxist.se>,  24774@debbugs.gnu.org
> Date: Tue, 23 Feb 2021 17:02:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is?  I don't see it in "emacs -Q".  It only gets loaded when
> > emacs-lisp-mode is activated.
> 
> emacs -Q
> (featurep 'easymenu)
> => t

I get nil here, in Emacs 28.  Both on MS-Windows and on GNU/Linux in
"emacs -Q -nw".

Maybe it's system-dependent?  What Emacs configuration is the one
where you get the above?

> This is probably because *scratch* is an Emacs Lisp-derived mode

Nope.

> emacs-lisp.el should be able to use it, because the typical impact
> on users will be nil.

Why cannot emacs-lisp.el use it without preloading it?  emacs-lisp.el
is not itself preloaded, it loads only when you invoke the mode the
first time, e.g. by visiting a .el file.

bug#24774: 26.0.50; Menu display navigation commands

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Why cannot emacs-lisp.el use it without preloading it?  emacs-lisp.el
> is not itself preloaded, it loads only when you invoke the mode the
> first time, e.g. by visiting a .el file.

The correct name is "elisp-mode.el", and that file is preloaded.

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 23 Feb 2021 10:37:04 -0600
> Cc: 24774@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why cannot emacs-lisp.el use it without preloading it?  emacs-lisp.el
> > is not itself preloaded, it loads only when you invoke the mode the
> > first time, e.g. by visiting a .el file.
> 
> The correct name is "elisp-mode.el", and that file is preloaded.

OK, but easymenu is still not loaded here in "emacs -Q".  Can you
figure out which code loads it on your system?

bug#24774: 26.0.50; Menu display navigation commands

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Stefan Kangas <stefan@marxist.se>,  24774@debbugs.gnu.org
>> Date: Tue, 23 Feb 2021 17:02:51 +0100
>> 
>> emacs -Q
>> (featurep 'easymenu)
>> => t
>
> I get nil here, in Emacs 28.  Both on MS-Windows and on GNU/Linux in
> "emacs -Q -nw".

I get nil too with C-j, C-x C-e, and M-:, and regardless of '-nw'.

> Maybe it's system-dependent?  What Emacs configuration is the one
> where you get the above?

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-02-23 built on tia
Repository revision: 228fd92fb389eeaf2ec0bbca51da0569fce28ee7
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11
XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 50707 5750)
 (symbols 48 6596 1)
 (strings 32 18891 1693)
 (string-bytes 1 608073)
 (vectors 16 12103)
 (vector-slots 8 165037 8809)
 (floats 8 23 41)
 (intervals 56 229 0)
 (buffers 992 10))

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  stefan@marxist.se,
>   24774@debbugs.gnu.org
> Date: Tue, 23 Feb 2021 16:50:53 +0000
> 
> I get nil too with C-j, C-x C-e, and M-:, and regardless of '-nw'.
> 
> > Maybe it's system-dependent?  What Emacs configuration is the one
> > where you get the above?
> 
> -- 
> Basil
> 
> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
>  of 2021-02-23 built on tia

So maybe this is specific to GTK builds?

bug#24774: 26.0.50; Menu display navigation commands

[Gregory Heytings]

>> I get nil too with C-j, C-x C-e, and M-:, and regardless of '-nw'.
>>
>>> Maybe it's system-dependent?  What Emacs configuration is the one 
>>> where you get the above?
>>
>> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2021-02-23 built on tia
>
> So maybe this is specific to GTK builds?
>

I just tried on several GTK builds (of Emacs 26, 27 and 28) and they all 
return nil.

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> Date: Tue, 23 Feb 2021 17:24:38 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 24774@debbugs.gnu.org
> 
> > So maybe this is specific to GTK builds?
> >
> 
> I just tried on several GTK builds (of Emacs 26, 27 and 28) and they all 
> return nil.

Thanks for testing.

So, Lars and Stefan: what is your secret?  We are all dying to know.

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So, Lars and Stefan: what is your secret?  We are all dying to know.

This is really weird -- I'm also getting (featurep 'easymenu) => nil now
on "emacs -Q".

Hm.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Stephen Berman]

On Wed, 24 Feb 2021 16:12:22 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> So, Lars and Stefan: what is your secret?  We are all dying to know.
>
> This is really weird -- I'm also getting (featurep 'easymenu) => nil now
> on "emacs -Q".
>
> Hm.

When you got t previously, could you have done `C-h v features' before
testing featurep?  help-mode loads easymenu.el.

Steve Berman

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> When you got t previously, could you have done `C-h v features' before
> testing featurep?  help-mode loads easymenu.el.

Aha!  Just doing `C-h v TAB' loads easymenu.  So I must have done that
(or something similar) on my way to `M-: (featurep 'easymenu)'

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> The correct name is "elisp-mode.el", and that file is preloaded.
>
> OK, but easymenu is still not loaded here in "emacs -Q".  Can you
> figure out which code loads it on your system?

I can no longer reproduce this now:

emacs -Q
M-: (featurep 'easymenu)
=> nil

I tried this several times both on master and Emacs 27.

I have no idea what I did differently before, because I did confirm that
it was preloaded (or so it seemed).  Perhaps I inadvertently did
something else that loaded it?

I do see this on both master and Emacs 27:

emacs -Q foo.txt
M-: (featurep 'easymenu)
=> t

So it seems very easy to get it to load it in normal use.

bug#24774: 26.0.50; Menu display navigation commands

[Stephen Berman]

On Wed, 24 Feb 2021 19:25:25 -0600 Stefan Kangas <stefan@marxist.se> wrote:

> I do see this on both master and Emacs 27:
>
> emacs -Q foo.txt
> M-: (featurep 'easymenu)
> => t

I cannot reproduce this.  Also with this:

emacs-27 -Q --eval "(message \"easymenu is%s loaded\" (if (featurep 'easymenu) \"\" \" not\"))" foo.txt

C-x b *Messages*
=> easymenu is not loaded

Compare:

emacs-27 -Q --eval "(progn (load-library \"easymenu\") (message \"easymenu is%s loaded\" (if (featurep 'easymenu) \"\" \" not\")))" foo.txt

C-x b *Messages*
=> easymenu is loaded

If you don't get this difference, something is weird somewhere.

Steve Berman

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

On February 25, 2021 11:04:06 AM GMT+02:00, Stephen Berman <stephen.berman@gmx.net> wrote:
> On Wed, 24 Feb 2021 19:25:25 -0600 Stefan Kangas <stefan@marxist.se>
> wrote:
> 
> > I do see this on both master and Emacs 27:
> >
> > emacs -Q foo.txt
> > M-: (featurep 'easymenu)
> > => t
> 
> I cannot reproduce this.  Also with this:
> 
> emacs-27 -Q --eval "(message \"easymenu is%s loaded\" (if (featurep
> 'easymenu) \"\" \" not\"))" foo.txt
> 
> C-x b *Messages*
> => easymenu is not loaded
> 
> Compare:
> 
> emacs-27 -Q --eval "(progn (load-library \"easymenu\") (message
> \"easymenu is%s loaded\" (if (featurep 'easymenu) \"\" \" not\")))"
> foo.txt
> 
> C-x b *Messages*
> => easymenu is loaded
> 
> If you don't get this difference, something is weird somewhere.

I'm guessing that Stefan did this in a Git-versioned tree, where visiting a file loads vc-git.el, which loads diff-mode.el, which loads easymenu.

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm guessing that Stefan did this in a Git-versioned tree, where
> visiting a file loads vc-git.el, which loads diff-mode.el, which loads
> easymenu.

Right.  Even `C-h v' loads easymenu, so I think the conclusion here is
that it's difficult to do many normal operations in Emacs without
easymenu being loaded.  So preloading it seems like the right thing to
do -- it'll make normal Emacs usage faster (and allow us to clean up
more ancient code at the same time).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stephen Berman <stephen.berman@gmx.net>, Stefan Kangas
>  <stefan@marxist.se>, 24774@debbugs.gnu.org
> Date: Thu, 25 Feb 2021 16:09:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm guessing that Stefan did this in a Git-versioned tree, where
> > visiting a file loads vc-git.el, which loads diff-mode.el, which loads
> > easymenu.
> 
> Right.  Even `C-h v' loads easymenu, so I think the conclusion here is
> that it's difficult to do many normal operations in Emacs without
> easymenu being loaded.  So preloading it seems like the right thing to
> do -- it'll make normal Emacs usage faster (and allow us to clean up
> more ancient code at the same time).

We never followed such logic, AFAIR.  Quite the contrary: we tried to
delay loading as log as we could.  So maybe, for example, loading
diff-mode just because a VC backend loads is not TRT.

More generally, I'm afraid that not keeping this stuff in check will
be a slippery slope, which will quickly lead to a much fatter Emacs
process.

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> More generally, I'm afraid that not keeping this stuff in check will
> be a slippery slope, which will quickly lead to a much fatter Emacs
> process.

Including easymenu allows for a slimmer Emacs process -- using easymenu
results in smaller .elc files for the .el files that use it, I think?

So I say include it in loadup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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: Thu, 25 Feb 2021 16:52:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > More generally, I'm afraid that not keeping this stuff in check will
> > be a slippery slope, which will quickly lead to a much fatter Emacs
> > process.
> 
> Including easymenu allows for a slimmer Emacs process -- using easymenu
> results in smaller .elc files for the .el files that use it, I think?
> 
> So I say include it in loadup.

Again: we never included in loadup what is not immediately loaded at
startup anyway.  I don't think we should start that way, so please
let's not.

bug#24774: 26.0.50; Menu display navigation commands

[Eli Zaretskii]

> Date: Thu, 25 Feb 2021 20:18:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: stephen.berman@gmx.net, stefan@marxist.se, 24774@debbugs.gnu.org
> 
> > Including easymenu allows for a slimmer Emacs process -- using easymenu
> > results in smaller .elc files for the .el files that use it, I think?
> > 
> > So I say include it in loadup.
> 
> Again: we never included in loadup what is not immediately loaded at
> startup anyway.  I don't think we should start that way, so please
> let's not.

Alternatively, if you think the criteria for what should and shouldn't
be preloaded should change, let's see if we can come up with some
reasonable modified criteria that will not let us slip that slope.
What I'd like to avoid is preloading something without having a clear
idea why, because then we won't be able to explain why we preload
foo.el, but not bar.el or baz.el.

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Including easymenu allows for a slimmer Emacs process -- using easymenu
>> results in smaller .elc files for the .el files that use it, I think?
>> 
>> So I say include it in loadup.
>
> Again: we never included in loadup what is not immediately loaded at
> startup anyway.  I don't think we should start that way, so please
> let's not.

The suggested patch is to use easymenu in elisp-mode.el -- which is a
file that's preloaded.  To use it there, easymenu itself also has to be
preloaded, so I'm not sure exactly what you mean here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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: Fri, 26 Feb 2021 09:48:15 +0100
> 
> > Again: we never included in loadup what is not immediately loaded at
> > startup anyway.  I don't think we should start that way, so please
> > let's not.
> 
> The suggested patch is to use easymenu in elisp-mode.el -- which is a
> file that's preloaded.  To use it there, easymenu itself also has to be
> preloaded, so I'm not sure exactly what you mean here.

maybe it's a reason good enough not to use easymenu in elisp-mode.el?
Why do we want to do that, again?

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> maybe it's a reason good enough not to use easymenu in elisp-mode.el?
> Why do we want to do that, again?

Because it's a better, more sensible way to define menus.  (And possibly
smaller .elc file, as I said.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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: Fri, 26 Feb 2021 13:07:34 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > maybe it's a reason good enough not to use easymenu in elisp-mode.el?
> > Why do we want to do that, again?
> 
> Because it's a better, more sensible way to define menus.

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.  Where
do we stop, if the criterion is "better and more sensible" (which are
highly subjective judgments)?

Or are you saying that memory footprint considerations are totally
unimportant, and we should preload everything that might possibly be
helpful?

That's why I suggested to discuss and agree on the criteria first.  If
we don't agree on some criteria, we will have this argument many times
in the future.

> (And possibly smaller .elc file, as I said.)

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.

bug#24774: [External] : bug#24774: 26.0.50; Menu display navigation commands

[Drew Adams]

> > maybe it's a reason good enough not to use easymenu in elisp-mode.el?
> > Why do we want to do that, again?
> 
> Because it's a better, more sensible way to define menus.

If that were true then it would be an argument for
getting rid of extended menu items and defining
menus using define-key altogether.  Are you arguing
for that also?  If not, why not?

IOW, how about a "better" - meaning more refined or
precise - reason for what you want to do?  "It's
better" is not what I'd call a great argument.

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Because it's a better, more sensible way to define menus.
>
> 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?

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.

easymenu.el is over-ripe for preloading since it's very hard to do much
in Emacs without it being pulled in anyway -- so you get no space
savings in practice, but just a slower Emacs.

>> (And possibly smaller .elc file, as I said.)
>
> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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.

Err.  That's counting the elisp-mode.elc size reduction twice, since
it's included in the .pdmp file, I guess.  So it's

(- 10632360 10630544) => 1816 bytes

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: [External] : bug#24774: 26.0.50; Menu display navigation commands

[Drew Adams]

> > 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?

I'm somebody, and I claimed that explicitly.
And I gave reasons why I find it superior.

You can ignore my posts, but that doesn't
annul their arguments.

You, on the other hand, haven't provided
any reason for what you want to do (except
"smaller .elc file").  An empty claim of
"it's better" is not a great argument.

> easymenu.el is over-ripe for preloading since it's very hard to do much
> in Emacs without it being pulled in anyway -- so you get no space
> savings in practice, but just a slower Emacs.

How is it "very hard to do much in Emacs"
without pulling in easymenu?  It's easymenu
that's redundant, not "the non-easymenu way".

Your claim that easymenu is a "better, more
sensible way to define menus", and your
claims that everything that can be done the
"non-easymenu way" can be done with easymenu
(and better and more sensibly), call out for
replacing the non-easymenu way altogether.
Are you arguing in favor of that?  If not,
why not?

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).

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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).

Without patch:

larsi     958039 11.5  0.3 355040 61504 pts/0    Sl   12:47   0:00 ./src/emacs -Q
larsi     958573 12.0  0.3 355036 61440 pts/0    Sl   12:48   0:00 ./src/emacs -Q
larsi     958833 11.5  0.3 355036 61364 pts/0    Sl   12:48   0:00 ./src/emacs -Q

With patch:

larsi     959730 11.5  0.3 354940 61560 pts/0    Sl   12:48   0:00 ./src/emacs -Q
larsi     959992 11.5  0.3 354940 61132 pts/0    Sl   12:48   0:00 ./src/emacs -Q
larsi     960242 11.5  0.3 355012 61704 pts/0    Sl   12:48   0:00 ./src/emacs -Q


Tested with

bash -c "./src/emacs -Q&" ; sleep 2; ps auxwww | grep "[.]/src/emacs"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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 12:50:59 +0100
> 
> Without patch:
> 
> larsi     958039 11.5  0.3 355040 61504 pts/0    Sl   12:47   0:00 ./src/emacs -Q
> larsi     958573 12.0  0.3 355036 61440 pts/0    Sl   12:48   0:00 ./src/emacs -Q
> larsi     958833 11.5  0.3 355036 61364 pts/0    Sl   12:48   0:00 ./src/emacs -Q
> 
> With patch:
> 
> larsi     959730 11.5  0.3 354940 61560 pts/0    Sl   12:48   0:00 ./src/emacs -Q
> larsi     959992 11.5  0.3 354940 61132 pts/0    Sl   12:48   0:00 ./src/emacs -Q
> larsi     960242 11.5  0.3 355012 61704 pts/0    Sl   12:48   0:00 ./src/emacs -Q
> 
> 
> Tested with
> 
> bash -c "./src/emacs -Q&" ; sleep 2; ps auxwww | grep "[.]/src/emacs"

Sounds inconsistent?  Do you understand why?

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Sounds inconsistent?  Do you understand why?

Nope -- Emacs is of different size every time I start it.  Address
randomisation leading to different malloc/free/return-to-OS patterns?

Anyway, there's no noticeable difference in mean size with or without
the patch in these runs, apparently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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 14:25:10 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sounds inconsistent?  Do you understand why?
> 
> Nope -- Emacs is of different size every time I start it.  Address
> randomisation leading to different malloc/free/return-to-OS patterns?

I'm not talking about the initial size, I'm talking about the
difference between the RSS of the two variants: it is sometimes
positive and sometimes negative.

> Anyway, there's no noticeable difference in mean size with or without
> the patch in these runs, apparently.

Yes, I think so.

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Nope -- Emacs is of different size every time I start it.  Address
>> randomisation leading to different malloc/free/return-to-OS patterns?
>
> I'm not talking about the initial size, I'm talking about the
> difference between the RSS of the two variants: it is sometimes
> positive and sometimes negative.

I'm not sure I understand you here -- there's no initial size in the ps
output, only virtual size and resident set size?  I don't get the
"sometimes positive and sometimes" negative either -- there were three
runs of Emacsen started (with and without the patch), and both
numbers varied in all instances.

>> Anyway, there's no noticeable difference in mean size with or without
>> the patch in these runs, apparently.
>
> Yes, I think so.

The mean RSS sizes were 61436 and 61465, which is not a noticeable
difference.  But I may be misunderstanding what you mean here either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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 14:49:14 +0100
> 
> The mean RSS sizes were 61436 and 61465, which is not a noticeable
> difference.

I'm not sure the average is representative here, given the variance.
But anyway, the difference is too small to invest any more energy into
this aspect.

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure the average is representative here, given the variance.
> But anyway, the difference is too small to invest any more energy into
> this aspect.

OK; applying and pushing Stefan's patch, then.

And then somebody could take a look at actually implementing the stuff
this bug report is really about.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24774: 26.0.50; Menu display navigation commands

[Lars Ingebrigtsen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

>>> think it would be a gain if Emacs-lisp menu displays navigation commands.
>> What kind of navigation commands?
>>
>
> Stuff like beginning-of-defun, up-list, forward-sexp

OK; added to Emacs 28 now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no