From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer] Date: Sun, 23 Jul 2006 11:03:21 +1200 Message-ID: <17602.44729.127250.330091@kahikatea.snap.net.nz> References: <17601.47663.608500.475165@kahikatea.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1153609503 19731 80.91.229.2 (22 Jul 2006 23:05:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 22 Jul 2006 23:05:03 +0000 (UTC) Cc: drew.adams@oracle.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 23 01:04:59 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G4QWp-0000mx-KB for ged-emacs-devel@m.gmane.org; Sun, 23 Jul 2006 01:04:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4QWp-0007kG-7R for ged-emacs-devel@m.gmane.org; Sat, 22 Jul 2006 19:04:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4QWd-0007jo-6p for emacs-devel@gnu.org; Sat, 22 Jul 2006 19:04:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4QWc-0007jc-Ll for emacs-devel@gnu.org; Sat, 22 Jul 2006 19:04:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4QWc-0007jZ-J3 for emacs-devel@gnu.org; Sat, 22 Jul 2006 19:04:46 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4QXJ-00064b-Oi; Sat, 22 Jul 2006 19:05:30 -0400 Original-Received: from kahikatea.snap.net.nz (p202-124-112-45.snap.net.nz [202.124.112.45]) by viper.snap.net.nz (Postfix) with ESMTP id 8F03F7764A0; Sun, 23 Jul 2006 11:04:42 +1200 (NZST) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 4F6981D3547; Sun, 23 Jul 2006 11:03:21 +1200 (NZST) Original-To: Eli Zaretskii In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.42 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:57481 Archived-At: > > I can't reproduce this on GNU/Linux. > What do you see on GNU/Linux? Do you see the TTTTTTTTTTTTTTTTT > message in the echo area? Yes. It works as expected > Also, what is your Emacs configuration? (The toolkit, if any, is the > most interesting detail.) GNU Emacs 22.0.50.42 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) > > I don't think so. The item TEST has no help-echo. Messages disappear > > when Emacs receives further input. > > This is not entirely accurate, see below: no help-echo causes Emacs to > clear the echo area, probably to erase the previous help-echo. I see I was wrong now. No help-echo must clear the echo area otherwise the old help text would remain visible while over a new menu item. > Anyway, I looked into the code, compared the X version with the w32 > version, and frankly, I'm baffled. > > Here's what I see in the code: if a menu item doesn't have an > associated help-echo string, both X and w32 versions call > kbd_buffer_store_help_event with nil as its second argument. (For the > w32 version, see w32menu.c:w32menu_display_help; for the X version, > see xmenu.c:menu_highlight_callback.) This nil eventually winds up in > keyboard.c:show_help_echo, which explicitly calls message(0) if its > HELP argument is nil. The call message(0) should clear the echo area, > AFAIU. > > In the w32 version, if I put a breakpoint inside show_help_echo, it > breaks after I click on TEST in the menu. If I then step through the > function, I clearly see the TTTTTTTTTTTTTTTTT message in the echo area > until Emacs calls message(0), at which point the echo area is cleared. > > I don't have access to a GUI version of Emacs on GNU/Linux where I'm > typing this--could someone please see which part of the above > description works differently on GNU/Linux, and why? If I put a breakpoint inside show_help_echo and click C-down-mouse-2 the window manager freezes. If I instrument the function test with edebug and step through it, the message doesn't appear. The problem with debugging these situations is that it changes the behaviour. -- Nick http://www.inet.net.nz/~nickrob