unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer]
@ 2006-07-22  4:38 Richard Stallman
  2006-07-22  5:39 ` Nick Roberts
  0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2006-07-22  4:38 UTC (permalink / raw)


Would someone please investigate this?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Fri, 21 Jul 2006 07:20:36 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
In-Reply-To: <MEEKKIABFKKDFJMPIOEBIEIIDCAA.drew.adams@oracle.com>
Subject: RE: tooltip-mode disabled prevents messages in minibuffer
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

Any news on this bug?

    -----Original Message-----
    From: Drew Adams [mailto:drew.adams@oracle.com]
    Sent: Sunday, June 25, 2006 9:08 AM
    To: Emacs-Pretest-Bug
    Subject: tooltip-mode disabled prevents messages in minibuffer


    Evaluate this:

     (require 'easymenu)
     (defvar my-menu (copy-tree facemenu-menu) "")
     (defalias 'my-menu my-menu)
     (define-key global-map [C-down-mouse-2] 'my-menu)
     (easy-menu-do-add-item my-menu ["TEST" test t])
     (defun test () "" (interactive) (message "TTTTTTTTTTTTTTTTT"))
     (tooltip-mode 1)

    Use `C-mouse-2' to bring up the facemenu and then click TEST. The
    message TTTTTTTTTTTT appears in the minibuffer, as it should.

    Now, do this: (tooltip-mode -1)

    Try menu item TEST again: no message appears in the minibuffer. The
    message TTTTTTTTTT appears in *Messages*, however.

    I don't know if an empty tooltip message in the minibuffer is somehow
    overwriting the message or what. If that is the problem, how can I
    control that?  I tried binding tooltip-mode to 1 around the call to
    `message', but that didn't help.



    In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
     of 2006-03-20 on W2ONE
    X server distributor `Microsoft Corp.', version 5.1.2600
    configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

    Important settings:
      value of $LC_ALL: nil
      value of $LC_COLLATE: nil
      value of $LC_CTYPE: nil
      value of $LC_MESSAGES: nil
      value of $LC_MONETARY: nil
      value of $LC_NUMERIC: nil
      value of $LC_TIME: nil
      value of $LANG: ENU
      locale-coding-system: cp1252
      default-enable-multibyte-characters: t

    Major mode: Emacs-Lisp

    Minor modes in effect:
      encoded-kbd-mode: t
      tooltip-mode: t
      auto-compression-mode: t
      tool-bar-mode: t
      mouse-wheel-mode: t
      menu-bar-mode: t
      file-name-shadow-mode: t
      global-font-lock-mode: t
      font-lock-mode: t
      blink-cursor-mode: t
      unify-8859-on-encoding-mode: t
      utf-translate-cjk-mode: t
      line-number-mode: t

    Recent input:
    n u <tab> <return> <help-echo> <help-echo> <help-echo>
    <switch-frame> <down-mouse-1> <mouse-movement> <mouse-1>
    <down-mouse-2> <mouse-2> <return> <return> <down-mouse-1>
    <mouse-movement> <mouse-1> <down-mouse-2> <mouse-2>
    <down-mouse-1> <mouse-1> C-x C-s M-x e v a l - b u
    f f e r <return> <down-mouse-1> <mouse-1> <down-mouse-1>
    <mouse-1> <return> <return> <down-mouse-1> <mouse-1>
    ( r e q u i r e SPC ' e a s y m e n u ) C-e C-x C-e
    <down-mouse-1> <mouse-1> M-x e v a l - b u <return>
    <C-down-mouse-2> <TEST> <down-mouse-1> <mouse-1> <backspace>
    C-e C-x C-e <C-down-mouse-2> <TEST> <down-mouse-1>
    <mouse-1> <backspace> <help-echo> <help-echo> <help-echo>
    <help-echo> <help-echo> <help-echo> <menu-bar> <help-menu>
    <report-emacs-bug>

    Recent messages:
    Loading dired...done
    (New file)
    Mark set [2 times]
    Wrote c:/drews-lisp-20/foo.el
    eval-buffer: Symbol's function definition is void: easy-menu-do-add-item
    easymenu
    TTTTTTTTTTTTTTTTT
    t
    TTTTTTTTTTTTTTTTT
    Loading emacsbug...done




_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer]
  2006-07-22  4:38 [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer] Richard Stallman
@ 2006-07-22  5:39 ` Nick Roberts
  2006-07-22 10:23   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Nick Roberts @ 2006-07-22  5:39 UTC (permalink / raw)
  Cc: emacs-devel

 >     Evaluate this:
 > 
 >      (require 'easymenu)
 >      (defvar my-menu (copy-tree facemenu-menu) "")
 >      (defalias 'my-menu my-menu)
 >      (define-key global-map [C-down-mouse-2] 'my-menu)
 >      (easy-menu-do-add-item my-menu ["TEST" test t])
 >      (defun test () "" (interactive) (message "TTTTTTTTTTTTTTTTT"))
 >      (tooltip-mode 1)
 > 
 >     Use `C-mouse-2' to bring up the facemenu and then click TEST. The
 >     message TTTTTTTTTTTT appears in the minibuffer, as it should.
 > 
 >     Now, do this: (tooltip-mode -1)
 > 
 >     Try menu item TEST again: no message appears in the minibuffer. The
 >     message TTTTTTTTTT appears in *Messages*, however.

I can't reproduce this on GNU/Linux.

 >     I don't know if an empty tooltip message in the minibuffer is somehow
 >     overwriting the message or what. If that is the problem, how can I
 >     control that?  

I don't think so.  The item TEST has no help-echo.  Messages disappear
when Emacs receives further input.  Perhaps this is the case on Windows
after test has executed e.g C-mouse-2 vs. C-down-mouse-2

 >     	       		I tried binding tooltip-mode to 1 around the call to
 >  `message', but that didn't help.

tooltip-mode is a minor-mode, not just a variable like buffer-read-only.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer]
  2006-07-22  5:39 ` Nick Roberts
@ 2006-07-22 10:23   ` Eli Zaretskii
  2006-07-22 23:03     ` Nick Roberts
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2006-07-22 10:23 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 22 Jul 2006 17:39:59 +1200
> Cc: emacs-devel@gnu.org
> 
>  >     Evaluate this:
>  > 
>  >      (require 'easymenu)
>  >      (defvar my-menu (copy-tree facemenu-menu) "")
>  >      (defalias 'my-menu my-menu)
>  >      (define-key global-map [C-down-mouse-2] 'my-menu)
>  >      (easy-menu-do-add-item my-menu ["TEST" test t])
>  >      (defun test () "" (interactive) (message "TTTTTTTTTTTTTTTTT"))
>  >      (tooltip-mode 1)
>  > 
>  >     Use `C-mouse-2' to bring up the facemenu and then click TEST. The
>  >     message TTTTTTTTTTTT appears in the minibuffer, as it should.
>  > 
>  >     Now, do this: (tooltip-mode -1)
>  > 
>  >     Try menu item TEST again: no message appears in the minibuffer. The
>  >     message TTTTTTTTTT appears in *Messages*, however.
> 
> 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?

Also, what is your Emacs configuration?  (The toolkit, if any, is the
most interesting detail.)

>  >     I don't know if an empty tooltip message in the minibuffer is somehow
>  >     overwriting the message or what. If that is the problem, how can I
>  >     control that?  
> 
> 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.

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?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer]
  2006-07-22 10:23   ` Eli Zaretskii
@ 2006-07-22 23:03     ` Nick Roberts
  2006-07-23  3:21       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Nick Roberts @ 2006-07-22 23:03 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

 > > 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer]
  2006-07-22 23:03     ` Nick Roberts
@ 2006-07-23  3:21       ` Eli Zaretskii
  2006-07-23  7:28         ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2006-07-23  3:21 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 23 Jul 2006 11:03:21 +1200
> Cc: emacs-devel@gnu.org, drew.adams@oracle.com
> 
>  > 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.

Thanks for trying.  However, until someone explains what is wrong with
what I see on Windows, I won't know how to fix it.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer]
  2006-07-23  3:21       ` Eli Zaretskii
@ 2006-07-23  7:28         ` Eli Zaretskii
  2006-07-23 11:18           ` Nick Roberts
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2006-07-23  7:28 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

> > From: Nick Roberts <nickrob@snap.net.nz>
> > Date: Sun, 23 Jul 2006 11:03:21 +1200
> > Cc: emacs-devel@gnu.org, drew.adams@oracle.com
> > 
> >  > 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.

How about if you insert calls to sleep before and after the call to
message(0), to have the code pause long enough for you to see the echo
area as it's been wriiten/cleared, but short enough to prevent the
window manager from freezing?

All I want to know is (1) whether message(0) is called and clears the
echo area message, and (2) whether the TTTTTTTTTTTTTTTTT message gets
restored after that somehow.

TIA

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer]
  2006-07-23  7:28         ` Eli Zaretskii
@ 2006-07-23 11:18           ` Nick Roberts
  0 siblings, 0 replies; 7+ messages in thread
From: Nick Roberts @ 2006-07-23 11:18 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

 > How about if you insert calls to sleep before and after the call to
 > message(0), to have the code pause long enough for you to see the echo
 > area as it's been wriiten/cleared, but short enough to prevent the
 > window manager from freezing?

OK, I found a couple of ways to stop the window manager from freezing, the
best being not to use gdb in Emacs :-(

 > All I want to know is (1) whether message(0) is called and clears the
 > echo area message, and (2) whether the TTTTTTTTTTTTTTTTT message gets
 > restored after that somehow.

I set one breakpoint at set_help_echo and another at Fmessage.  I then selected
the TEST menu-item using C-down-mouse-2:

  Echo Area           Stopped location
  C-down-mouse 2 -    show_help_echo       from  command_loop_1 keyboard.c:1535

cont:

  (clear)             show_help_echo       from  command_loop_1 keyboard.c:1535

cont:

 C-down-mouse 2 TEST  Fmessage             from  command_loop_1 keyboard.c:1790

stepping within Fmessage:

 TTTTTTTTTTTTTTTTT    Fmessage             from  command_loop_1 keyboard.c:1790

cont:

 TTTTTTTTTTTTTTTTT

Emacs doesn't hit show_help_echo presumably because execution has advanced
in command_loop_1 from line 1535 to 1790.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2006-07-23 11:18 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-22  4:38 [drew.adams@oracle.com: RE: tooltip-mode disabled prevents messages in minibuffer] Richard Stallman
2006-07-22  5:39 ` Nick Roberts
2006-07-22 10:23   ` Eli Zaretskii
2006-07-22 23:03     ` Nick Roberts
2006-07-23  3:21       ` Eli Zaretskii
2006-07-23  7:28         ` Eli Zaretskii
2006-07-23 11:18           ` Nick Roberts

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).