[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: echo area message after selection of menu-bar item
From: |
David Reitter |
Subject: |
Re: echo area message after selection of menu-bar item |
Date: |
Thu, 22 Dec 2005 15:12:46 +0000 |
t may perhaps be the show-help-function variable, though it
defaults to tooltip-show-help-function or tooltip-show-help
which won't echo such a message. Does this help?
Nope, doesn't make a difference.
But Drew's suggestion to bind `echo-keystrokes' to nil helps.
Interestingly, the following menu item shows the problematic echo
message. When I bind `echo-keystrokes' to nil, I get the "One-Buffer-
One-Frame-Mode dis/enabled" message which is output by what menu-bar-
make-mm-toggle produces. So it seems like the keystroke echo message
even overwrites the previous (much better) message.
The menu item I'm talking about is defined like this:
(define-key-after menu-bar-options-menu [oneonone]
(menu-bar-make-mm-toggle
one-buffer-one-frame-mode
"Display Buffers in Separate Frames"
"Open a new Frame (window) for each new buffer."
(:visible (boundp 'one-buffer-one-frame-mode)))
'edit-options-separator)
Other entries, e.g., save-place, behave differently. Here, the "en/
disabled" message appears after the keystrokes echo. This one is
defined with `menu-bar-make-toggle' (in menu-bar.el) rather than with
the minor-mode version.
Note that the minibuffer must be empty to reproduce this (see use of
Vecho_keystrokes in the code).
Of course, the echo-keystrokes solution can't be the final word for me.
Echo-keystrokes is meant to be for unfinished keyboard commands. The
menu item selection is a finished command, however.
Does it behave like this in other ports (I'm a Mac guy) as well?
Sounds almost like a bug in either the Carbon port or even in the
general implementation.