bug#16565: 24.3.50; x-popup-menu just returns nil

bug#16565: 24.3.50; x-popup-menu just returns nil

[Michael Heerdegen]

Hello,

in emacs -Q, I eval the following:

--8<---------------cut here---------------start------------->8---
(defun foo (event)
  (interactive "e")
  (message "%s" (x-popup-menu event (mouse-menu-bar-map))))
 
(global-set-key
 [(meta control mouse-3)] ;just some free key
 #'foo)
--8<---------------cut here---------------end--------------->8---

Now, I hit M-C-mouse-3 somewhere.  The menu appears at the right place.
I select any item, and FOO messages "nil" instead of a list of events.
This is the bug.

However, when I redefine FOO so that it uses t instead of EVENT as first
argument of `x-popup-menu', it works as expected!

The problem seems to be system specific.  I see it on Debian Linux with
X, Drew Adams doesn't see it under Windows.

I use openbox, but the behavior is the same in an X session without any
window manager.


Regards,

Michael.



In GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.6)
 of 2014-01-27 on drachen
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description:	Debian GNU/Linux testing (jessie)

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix

bug#16565: 24.3.50; x-popup-menu just returns nil

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> (defun foo (event)
>   (interactive "e")
>   (message "%s" (x-popup-menu event (mouse-menu-bar-map))))
>  
> (global-set-key
>  [(meta control mouse-3)] ;just some free key
>  #'foo)
>
> Now, I hit M-C-mouse-3 somewhere.  The menu appears at the right place.
> I select any item, and FOO messages "nil" instead of a list of events.
> This is the bug.

Let me add two notes:

1.  The problem doesn't happen here if I call `x-popup-menu' with a
(TITLE PANE1 PANE2...) list instead of (mouse-menu-bar-map).

2.  I think the problem exists at least since several weeks.


Michael.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Mon, 27 Jan 2014 03:50:37 +0100
> 
> 
> (defun foo (event)
>   (interactive "e")
>   (message "%s" (x-popup-menu event (mouse-menu-bar-map))))
>  
> (global-set-key
>  [(meta control mouse-3)] ;just some free key
>  #'foo)
> --8<---------------cut here---------------end--------------->8---
> 
> Now, I hit M-C-mouse-3 somewhere.  The menu appears at the right place.
> I select any item, and FOO messages "nil" instead of a list of events.
> This is the bug.
> 
> However, when I redefine FOO so that it uses t instead of EVENT as first
> argument of `x-popup-menu', it works as expected!
> 
> The problem seems to be system specific.  I see it on Debian Linux with
> X, Drew Adams doesn't see it under Windows.

Popup menus are toolkit-dependent, and you are using GTK3.  If you
want to try other toolkits, try Lucid or no-toolkit configuration.
(I confirm that the problem doesn't happen on MS-Windows.)

To find out what is going on, step with a debugger int x-popup-menu,
and see why it returns nil.  My guess would be that the menu callback
is not called for some reason, or maybe some other calamity.

Alternatively, if older versions don't show this behavior, try
bisecting.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Popup menus are toolkit-dependent, and you are using GTK3.  If you
> want to try other toolkits, try Lucid or no-toolkit configuration.
> (I confirm that the problem doesn't happen on MS-Windows.)

Ok, first I tried all Emacs versions available from Debian.  The GTK
built of Emacs 24 shows the problem.  The GTK built of Emacs 23 shows
it, too.  The lucid built of Emacs 24 works ok.

> To find out what is going on, step with a debugger int x-popup-menu,
> and see why it returns nil.  My guess would be that the menu callback
> is not called for some reason, or maybe some other calamity.

Will try to do that today, thanks.

Michael.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Will try to do that today, thanks.

Ok, I tried to do my best to understand the C code and GUD.

If I understand correctly, this is executed for me:

    selection = xmenu_show (f, xpos, ypos, for_click,
			    keymaps, title, &error_name);

In the good case, SELECTION is bound to different integers, in the bad
case, it is always the same integer, which seems to mean "nil".

But there is a difference in the arguments of the xmenu_show call.  In
the bad case calling with an event:

  (x-popup-menu event (mouse-menu-bar-map))

FOR_CLICK is bound to true.  In the good case with

  (x-popup-menu t (mouse-menu-bar-map))

FOR_CLICK is bound to false.

That made me wonder what happened when I bind `foo' to a mouse-down
event.  Then the bug doesn't happen, `foo' doesn't return nil.


HTH,

Michael.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 16565@debbugs.gnu.org
> Date: Tue, 28 Jan 2014 04:11:42 +0100
> 
> Ok, I tried to do my best to understand the C code and GUD.
> 
> If I understand correctly, this is executed for me:
> 
>     selection = xmenu_show (f, xpos, ypos, for_click,
> 			    keymaps, title, &error_name);
> 
> In the good case, SELECTION is bound to different integers, in the bad
> case, it is always the same integer, which seems to mean "nil".

If you start GDB in the src directory, or let it otherwise read the
file src/.gdbinit, you can know for sure: the "xtype" command will
tell you what kind of Lisp data is in 'selection':

  (gdb) p selection
  (gdb) xtype

If "xtype" says it's a Lisp symbol, another command "xsymbol" will
tell you what symbol is that, it will say "nil" if it is nil.

> But there is a difference in the arguments of the xmenu_show call.  In
> the bad case calling with an event:
> 
>   (x-popup-menu event (mouse-menu-bar-map))
> 
> FOR_CLICK is bound to true.  In the good case with
> 
>   (x-popup-menu t (mouse-menu-bar-map))
> 
> FOR_CLICK is bound to false.
> 
> That made me wonder what happened when I bind `foo' to a mouse-down
> event.  Then the bug doesn't happen, `foo' doesn't return nil.

In general, as long as the menu pops up, you should see the selection
made by the user.  The binding should only determine whether the menu
pops up or not, AFAIK.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> If you start GDB in the src directory, or let it otherwise read the
> file src/.gdbinit, you can know for sure: the "xtype" command will
> tell you what kind of Lisp data is in 'selection':
>
>   (gdb) p selection
>   (gdb) xtype
>
> If "xtype" says it's a Lisp symbol, another command "xsymbol" will
> tell you what symbol is that, it will say "nil" if it is nil.

I don't have a command xtype, only ptype.  What do I miss?  Anyway, the
mouse tooltip over Qnil shows the same integer.

So I think xmenu_show returns nil in the bad case.

I continued debugging xmenu_show and found that after the call to
`create_and_show_popup_menu', `menu_item_selection' is only != 0 in the
good case.

I tried to step through `create_and_show_popup_menu' as well, but that
makes any input from X impossible at some point, I had to kill gdb from
the console.

Michael.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 16565@debbugs.gnu.org
> Date: Tue, 28 Jan 2014 06:39:59 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you start GDB in the src directory, or let it otherwise read the
> > file src/.gdbinit, you can know for sure: the "xtype" command will
> > tell you what kind of Lisp data is in 'selection':
> >
> >   (gdb) p selection
> >   (gdb) xtype
> >
> > If "xtype" says it's a Lisp symbol, another command "xsymbol" will
> > tell you what symbol is that, it will say "nil" if it is nil.
> 
> I don't have a command xtype, only ptype.  What do I miss?

The first part of my instructions: either invoke GDB from the src
directory, or type this inside GDB:

  (gdb) source /path/to/src/.gdbinit

(It is possible that automatic loading of .gdbinit failed because
latest GDB versions refuse to load these init files by default.)

> Anyway, the mouse tooltip over Qnil shows the same integer.
> 
> So I think xmenu_show returns nil in the bad case.

Yes.

> I continued debugging xmenu_show and found that after the call to
> `create_and_show_popup_menu', `menu_item_selection' is only != 0 in the
> good case.

Perhaps Jan could help us out, then.  Jan, it sounds like GTK doesn't
like what we do with the menu, for some reason.

Thanks.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Jan Djärv]

Hello.

2014-01-28 17:31, Eli Zaretskii skrev:
>> From: Michael Heerdegen <michael_heerdegen@web.de>
>
>> I continued debugging xmenu_show and found that after the call to
>> `create_and_show_popup_menu', `menu_item_selection' is only != 0 in the
>> good case.
>
> Perhaps Jan could help us out, then.  Jan, it sounds like GTK doesn't
> like what we do with the menu, for some reason.
>

The Gtk+ assumtion is that popup is done on key down, not key up, i.e.:

(global-set-key
  [(meta control down mouse-3)] ;just some free key
  #'foo)

It is very strange to popup a menu on key up.  From the Gtk+ point of view, 
that corresponds to popping up without a mouse click, hence the error.  I have 
checked in a fix in trunk.

	Jan D.

bug#16565: 24.3.50; x-popup-menu just returns nil

[Michael Heerdegen]

Jan Djärv <jan.h.d@swipnet.se> writes:

> The Gtk+ assumtion is that popup is done on key down, not key up, i.e.:
>
> (global-set-key
>  [(meta control down mouse-3)] ;just some free key
>  #'foo)
>
> It is very strange to popup a menu on key up.

Generally I agree.  My use case is not that trivial.  I use mouse3 from
Drew, that pops up a menu after the second mouse click, but only when
it was not double click (it depends on the time between).  He does that
by redefining `mouse-save-then-kill', which makes sense.  So when we pop
up the menu, the up event has already happened.

> From the Gtk+ point of view, that corresponds to popping up without a
> mouse click, hence the error.

Makes sense, in general.

> I have checked in a fix in trunk.

Great.  That fixes the problem in general, as well as for mouse3.
Thanks!


Regards,

Michael.