bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

[Drew Adams]

emacs -Q

C-h k

As one example, choose from menu-bar: Options > Line Wrapping in This
Buffer > Wrap at Window Edge

Buffer *Help* shows this:

 <menu-bar> <options> <line-wrapping> <window-wrap> runs the command #[nil "\b\203\b\0\300\303!\210\304
 \205\0\305\306!\207" [visual-line-mode word-wrap truncate-lines 0
 nil toggle-truncate-lines -1] 2 nil nil] (found in global-map), which
 is an interactive compiled Lisp function.

 It is bound to <menu-bar> <options> <line-wrapping> <window-wrap>.

 (anonymous)

 Not documented.

That's nearly useless.  It doesn't take advantage of Emacs or Lisp.

1. Please provide named commands for all Options menu choices.
2. Please try to have *Help* point to the file that defines those
   commands.
3. Please keep byte-compiler gobbledygook out of Emacs help.

Consider this reasonable question, as one point of departure:
https://stackoverflow.com/q/60468217/729907

Yes, there's no satisfactory one-word answer to that user's question,
but s?he should at least be able to more easily track down the code that
provides the option behavior for the current buffer.
As it is now, it's not even obvious that the code is in menu-bar.el.




In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.18362
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

[Eli Zaretskii]

> Date: Sat, 29 Feb 2020 16:46:39 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> emacs -Q
> 
> C-h k
> 
> As one example, choose from menu-bar: Options > Line Wrapping in This
> Buffer > Wrap at Window Edge
> 
> Buffer *Help* shows this:
> 
>  <menu-bar> <options> <line-wrapping> <window-wrap> runs the command #[nil "\b\203\b\0\300\303!\210\304
>  \205\0\305\306!\207" [visual-line-mode word-wrap truncate-lines 0
>  nil toggle-truncate-lines -1] 2 nil nil] (found in global-map), which
>  is an interactive compiled Lisp function.
> 
>  It is bound to <menu-bar> <options> <line-wrapping> <window-wrap>.
> 
>  (anonymous)
> 
>  Not documented.
> 
> That's nearly useless.  It doesn't take advantage of Emacs or Lisp.

This is already fixed in Emacs 27.

bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

[Stefan Kangas]

unarchive 13841
forcemerge 13841 39848
thanks

Eli Zaretskii <eliz@gnu.org> writes:

> This is already fixed in Emacs 27.

Indeed, so I'm merging this bug with the previous one.

Best regards,
Stefan Kangas

bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

[Drew Adams]

> unarchive 13841
> forcemerge 13841 39848
> thanks
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is already fixed in Emacs 27.
> 
> Indeed, so I'm merging this bug with the previous one.

Yes, thanks.  I didn't realize this is essentially
a duplicate.

Is this taken care of _generally_, as requested
in #39848, or is it just taken care of for items
in this menu?

If fixed generally, then I guess it can be closed.

---

However, I do have a remark about what I see in
Emacs 27 (a dev snapshot from 2019-12-28):

 <menu-bar> <options> <line-wrapping> <window-wrap> runs the command
 menu-bar--wrap-long-lines-window-edge (found in global-map), which is
 an interactive compiled Lisp function in 'menu-bar.el'.

 It is bound to <menu-bar> <options> <line-wrapping> <window-wrap>.

 (menu-bar--wrap-long-lines-window-edge)

 Wrap long lines at window edge.

Command `menu-bar--wrap-long-lines-window-edge'
is precisely the kind of command that a user
might use, either directly or in lisp code.

So I really don't see why it's considered
"internal" (double-hyphen name).

I also don't see why it's in menu-bar.el or
it has prefix `menu-bar-'.  There's nothing
menu-specific about it.

Not only that, but unlike what menu `Options'
has generally been for, this item does not
just toggle a single user option value.  It
toggles two options and turns off a minor
mode.

Perhaps there are other considerations, but
at least on the face of it this command (and
its sister commands here) doesn't seem to
belong in menu-bar.el, and it may not belong
in menu `Options' either.

bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

[Eli Zaretskii]

> Date: Sun, 1 Mar 2020 09:34:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 39848@debbugs.gnu.org
> 
> Command `menu-bar--wrap-long-lines-window-edge'
> is precisely the kind of command that a user
> might use, either directly or in lisp code.

Why would they, when commands like visual-line-mode exist?

bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

[Drew Adams]

> > Command `menu-bar--wrap-long-lines-window-edge'
> > is precisely the kind of command that a user
> > might use, either directly or in lisp code.
> 
> Why would they, when commands like visual-line-mode exist?

Same reason they'd use it from a menu.

bug#39848: 26.3; Provide better help for menu-bar, e.g., Options > Line Wrapping in This Buffer

[Eli Zaretskii]

> Date: Sun, 1 Mar 2020 13:50:16 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: stefan@marxist.se, 39848@debbugs.gnu.org
> 
> > > Command `menu-bar--wrap-long-lines-window-edge'
> > > is precisely the kind of command that a user
> > > might use, either directly or in lisp code.
> > 
> > Why would they, when commands like visual-line-mode exist?
> 
> Same reason they'd use it from a menu.

Invoking a command from the menu doesn't involve naming the command,
it just involves clicking with the mouse and selecting the menu item.
By contrast, invoking commands by name involves typing that name.  And
we already have commands that perform the same operation as this menu
item.  So having yet another advertised command which subtly differs
from those we have already (the differences make sense when you invoke
a command from the menu) makes little sense to me.