unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>, Po Lu <luangruo@yahoo.com>,
	Lars Ingebrigtsen <larsi@gnus.org>
Cc: "52870@debbugs.gnu.org" <52870@debbugs.gnu.org>
Subject: bug#52870: [External] : bug#52870: Is displaying <menu-bar> bindings in describe-function useful?
Date: Sun, 16 Jan 2022 02:59:18 +0000	[thread overview]
Message-ID: <SJ0PR10MB548867AD4C76F333A730DCBEF3569@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CADwFkmk+LjneTuFEnocmsJFSL=j=e7r5qthRToSB+K=SszDZFA@mail.gmail.com>

> Drew Adams <drew.adams@oracle.com> writes:
> 
> >> FWIW I think it would be a good idea to do something like this:
> >>
> >>   It is bound to C-h f, <help> f, <menu-bar> <help-menu> <describe>
> >>   <describe-function> (which means it can be invoked from the menu:
> >>   "Help Menu" -> "Describe" ...).

You give the impression that Drew Adams said
what you quoted.  A careful reader might
notice that the quoted text is not from me;
others might not.  Why do that?

> IMO, that would be a step backwards.  This bug report started out with
> me saying that this information is already confusing and distracting,
> and this would make it even more so.

Why would providing additional information
about where that menu command can be found
in the menu be confusing?

To be clear, as I said, no change is needed.
Nothing is broken, confusing, or distracting.

But if someone wants to add more info, that's
OK too.

> I don't think we should pretend that menu items are key bindings, because
> they are not.

They certainly are - for Emacs.  Always have
been, ever since we've had menus.

> That is just an implementation detail.

No, it's not.  It's the way Emacs itself
talks about menu-item key bindings. 

> Our user manual correctly contrasts the two:
> 
>     "Each Emacs frame normally has a 'menu bar' at the top which you can use
>     to perform common operations ...
> 
>        "On a display that supports a mouse, you can use the mouse to choose
> a
>     command from the menu bar ...
> 
>        "Some of the commands in the menu bar have ordinary key bindings as
>     well; if so, a key binding is shown after the item itself."

Nothing there contradicts Emacs's treatment
everywhere of these as key bindings.  Yes,
that last sentence would be clearer if it
said "keyboard key bindings" instead of
"ordinary key bindings".

"Keyboard key bindings" is _very_ clear.
"Ordinary" means nothing here - that wording
is a bug.

Is a function-key binding an "ordinary" key
binding?  What about a function-key that's
not associated with a physical keyboard key?

Please don't try to change the longstanding
and very clear Emacs nomenclature about key
bindings.

Is the _text_ of a menu item the same as the
menu item?  If so, then your uses of "menu
item" above are incorrect - the text is not
bound.  But if not, then yes, menu items are
key bindings.  They're bound in a menu keymap.

And yes, it's important that Emacs itself,
when it speaks to users, use the same terms
as when it talks about Elisp entities.  Emacs
users are very often Elisp users.

And Elisp and its entities are not just
"implementation details".  Far from it, thank
goodness.

  reply	other threads:[~2022-01-16  2:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-29 12:40 bug#52870: Is displaying <menu-bar> bindings in describe-function useful? Stefan Kangas
2021-12-29 13:08 ` Lars Ingebrigtsen
2021-12-29 13:28 ` Eli Zaretskii
2021-12-29 14:49   ` Stefan Kangas
2021-12-29 16:51     ` Eli Zaretskii
2021-12-29 20:19       ` Stefan Kangas
2021-12-29 21:01         ` bug#52870: [External] : " Drew Adams
2021-12-30  7:15         ` Eli Zaretskii
2021-12-30 15:43           ` bug#52870: [External] : " Drew Adams
2022-01-15 10:09           ` Lars Ingebrigtsen
2022-01-15 10:28             ` Eli Zaretskii
2022-01-20 11:02               ` Lars Ingebrigtsen
2022-01-15 10:29             ` Stefan Kangas
2022-01-15 12:09             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-15 22:50               ` bug#52870: [External] : " Drew Adams
2022-01-15 23:44                 ` Stefan Kangas
2022-01-16  2:59                   ` Drew Adams [this message]
2022-01-15 22:37             ` Drew Adams
2021-12-29 15:25 ` Drew Adams
2022-04-25 19:15 ` Lars Ingebrigtsen
2022-04-28  6:49   ` Juri Linkov
2022-04-28 10:17     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB548867AD4C76F333A730DCBEF3569@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=52870@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=luangruo@yahoo.com \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).