all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 24596@debbugs.gnu.org
Subject: bug#24596: 25.1; `f10' behavior
Date: Mon, 3 Oct 2016 09:33:47 -0700 (PDT)	[thread overview]
Message-ID: <c37596f6-47bc-4624-b948-c938c87bc74e@default> (raw)
In-Reply-To: <<838tu5pg0x.fsf@gnu.org>>


> > `f10' used to just be bound to `tmm-menubar', for both TTY and
> > graphic-display Emacs.  Now it is bound to `menu-bar-open'.
> 
> Not true: F10 in a GUI session, at least on Windows, always activated
> the GUI menus from the menu bar.  I just tried that in Emacs 23.1.
> 
> What you say is only true for a TTY frame.  It was changed when
> text-mode frames learned to display menus.

You're right about that.  I was thinking of M-`, I guess (which is
still `tmm-menubar' by default).

> > 1. User option `tty-menu-open-use-tmm' makes `f10' use `tmm-menubar'
> > instead, but only on TTY.  Why not also on graphic displays?
> 
> Because F10 never invoked tmm on GUI frames, at least not on
> MS-Windows.  If you are asking for a new feature, then I guess it
> could be added if enough people want it, but then the variable's name
> will need to change, of course.

Yes.

> > 2. Why can you not exit `menu-bar-open' (with nil
> > `tty-menu-open-use-tmm')?  Why is ESC the only way to cancel (at least
> > on MS Windows)?  Why are not the canonical Emacs ways of canceling
> > implemented here (`C-g' and `ESC ESC ESC')?
> 
> ESC ESC works for me on MS-Windows GUI frames.

For me, with emacs -Q, a single ESC cancels.  A second ESC acts as
a prefix key for the next key sequence.

> ESC ESC ESC and C-g
> work for me on TTY frames.  C-g doesn't work on a GUI frame because
> the menu is controlled by Windows, not by Emacs, and Windows doesn't
> know about C-g.  IOW, this is a limitation we can do very little
> about.

OK.  Then the fix is to fix the doc, which says something quite
different from what the behavior really is.

> > 4. The doc in the Emacs manual (node Menu Bar) is not too bad.  But
> > AFAICT, `C-g' does NOT work (in MS Windows), as it says it does.  It
> > also says that you can cancel using `ESC ESC ESC'.  But the doc of
> > `w32-menu-bar-open' (correctly) says that a single `ESC' cancels.  Dunno
> > whether this is a doc bug or the behavior (on Windows) is bugged.
> 
> You are trying to apply the description of what happens with TTY menus
> to GUI menus.  They don't behave the same.

Where do you see that that doc says that what it is describing is
limited to TTYs?  In fact, the faulty description (for MS Windows, in
any case) is in the paragraph _before_ the paragraph that starts
talking about the behavior in a text terminal:

  Instead of using the mouse, you can also invoke the first menu bar
  item by pressing <F10> (to run the command ‘menu-bar-open’).  You can
  then navigate the menus with the arrow keys.  To activate a selected
  menu item, press <RET>; to cancel menu navigation, press ‘C-g’ or ‘<ESC>
  <ESC> <ESC>’.

The part about `C-g' and `ESC ESC ESC' is wrong, for Windows.  And if
`C-g' is Emacs only and `menu-bar-open' passes the behavior off to a
toolkit, then perhaps `C-g' is also incorrect for other toolkits/window
managers?

> > 5. Overall, it looks a bit like someone wrote `menu-bar-open',
> > `x-menu-bar-open', and `w32-menu-bar-open', and it was decided to
> > replace `tmm-menubar' as the binding of `f10'.  But I don't really see
> > the advantage, especially considering the lack of good doc.
> 
> The advantage is unified behavior across frame types, at least by
> default.  The tty-menu-open-use-tmm was added later by popular demand;
> initially I didn't imagine someone would want it when true menus are
> available.

I am not requesting it for myself.  (I use La Carte to access menus
using the keyboard.)

But, as you point out, I was mistaken in thinking that f10 was
`tmm-menubar' in the past.  I was thinking of M-`.

I think that the doc could be improved a bit, but the default behavior
is fine by me.





       reply	other threads:[~2016-10-03 16:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<ef8ce118-4fc8-4bc1-9606-468839196ffb@default>
     [not found] ` <<838tu5pg0x.fsf@gnu.org>
2016-10-03 16:33   ` Drew Adams [this message]
2016-10-03 17:23     ` bug#24596: 25.1; `f10' behavior Eli Zaretskii
     [not found] <<<ef8ce118-4fc8-4bc1-9606-468839196ffb@default>
     [not found] ` <<<838tu5pg0x.fsf@gnu.org>
     [not found]   ` <<c37596f6-47bc-4624-b948-c938c87bc74e@default>
     [not found]     ` <<834m4tpcsb.fsf@gnu.org>
2016-10-03 17:45       ` Drew Adams
2016-10-03 18:14         ` Eli Zaretskii
2016-10-06 18:49         ` Eli Zaretskii
2016-10-03 15:41 Drew Adams
2016-10-03 16:13 ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=c37596f6-47bc-4624-b948-c938c87bc74e@default \
    --to=drew.adams@oracle.com \
    --cc=24596@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.