From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.help Subject: Re: echo area message after selection of menu-bar item Date: Thu, 22 Dec 2005 15:12:46 +0000 Message-ID: <84D4880B-E081-47BD-8326-16561B2120DD@davids-welt.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1135277423 18377 80.91.229.2 (22 Dec 2005 18:50:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2005 18:50:23 +0000 (UTC) Cc: yamaoka@jpl.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 22 19:50:22 2005 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EpVW0-00068c-QZ for geh-help-gnu-emacs@m.gmane.org; Thu, 22 Dec 2005 19:50:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpVX1-0007vs-79 for geh-help-gnu-emacs@m.gmane.org; Thu, 22 Dec 2005 13:51:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EpS8r-0007da-Eg for help-gnu-emacs@gnu.org; Thu, 22 Dec 2005 10:14:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EpS8n-0007bs-80 for Help-gnu-emacs@gnu.org; Thu, 22 Dec 2005 10:14:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpS8m-0007bE-4U for Help-gnu-emacs@gnu.org; Thu, 22 Dec 2005 10:14:00 -0500 Original-Received: from [212.227.126.171] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EpS7u-0008Nt-BC for Help-gnu-emacs@gnu.org; Thu, 22 Dec 2005 10:13:06 -0500 Original-Received: from [82.41.74.89] (helo=[10.0.0.100]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1EpS7a497P-0008AZ; Thu, 22 Dec 2005 16:12:47 +0100 Original-To: Emacs help X-Mailer: Apple Mail (2.746.2) X-Provags-ID: kundenserver.de abuse@kundenserver.de login:f3c9a04d49beab9fcce37ffcb55ebfb9 X-Mailman-Approved-At: Thu, 22 Dec 2005 13:50:48 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:32167 Archived-At: > 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.