Re: Closing popup causes mouse event

Re: Closing popup causes mouse event

[YAMAMOTO Mitsuharu]

[The original report was posted to emacs-pretest-bug]

>>>>> On Tue, 18 Oct 2005 11:03:35 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>>>> On Sat, 15 Oct 2005 22:34:29 +0200, storm@cua.dk (Kim F. Storm) said:
>> David Reitter <david.reitter@gmail.com> writes:
>>> When a popup menu is opened (for example with C-mouse-1 or
>>> S-mouse-1) and closed by clicking somewhere else, it seems like an
>>> extra mouse event is sent.
>>> 
>>> This can cause the point to be set, the region to be removed or
>>> extended and what not - all of which is undesirable and
>>> unexpected.

>> It does not happen for me (GNU/Linux X11 non-GTK build).

> The problem is Mac-specific.  The following small patch seems to
> work for this particular case, but the general case is not so easy.
> (Repeated clicks of C-mouse-1 at non-menu position will show the
> message `<C-mouse-1> is undefined' on the Carbon port.)  I'll write
> something about this to emacs-devel.

A fix for "the general case" may require some changes to the
platform-independent part.  Let me explain the situation first.
Suppose we have a mouse-down event followed by a mouse-up event in the
main event queue of the window system, and the mouse-down event will
activate a pop-up menu.  The mouse-down event should be processed by
the read_socket_hook function to generate a Lisp-level event, but the
mouse-up event should be processed by another event loop for the
pop-up menu (e.g., PopUpMenuSelect for the Carbon port) and it should
not be read by the read_socket_hook function.

It is easy to quit the loop inside the read_socket_hook function once
a mouse-down event has been read.  But there's another loop in the
caller side, i.e., read_avail_input in keyboard.c:

      while (nr = (*read_socket_hook) (input_fd, expected, &hold_quit), nr > 0)
	{
	  nread += nr;
	  expected = 0;
	}

I'm not sure why it should loop.  Is it OK to replace these lines with
the following one?

      nread = (*read_socket_hook) (input_fd, expected, &hold_quit);

Unfortunately, the above change is not sufficient.  The mouse-up event
might be read by the read_socket_hook function through the
asynchronous input processing before the pop-up menu is activated.  I
think the situation is not so different also on other window systems.
Are other ports doing something special to avoid such a situation?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Closing popup causes mouse event

[Richard M. Stallman]

    It is easy to quit the loop inside the read_socket_hook function once
    a mouse-down event has been read.  But there's another loop in the
    caller side, i.e., read_avail_input in keyboard.c:

	  while (nr = (*read_socket_hook) (input_fd, expected, &hold_quit), nr > 0)
	    {
	      nread += nr;
	      expected = 0;
	    }

    I'm not sure why it should loop.

I think the reason for this loop is in case read_socket_hook does not
read all the events that are waiting.  The idea that there could be
events it should not touch is not part of the current design.

Whether there is a real chance that read_socket_hook might fail to
return all the pending events, I am not sure.  If it can never do so
accidentally, then this loop is unnecessary.  However, to fully
implement the idea of events that Emacs should not touch would require
more change, as you said.

      The mouse-down event should be processed by
    the read_socket_hook function to generate a Lisp-level event, but the
    mouse-up event should be processed by another event loop for the
    pop-up menu (e.g., PopUpMenuSelect for the Carbon port) and it should
    not be read by the read_socket_hook function.

Why does it matter if that up-event is processed by the menu's loop?
If it does not get to see the up-event, does something go wrong?

Or is it simply a matter of preventing this up-event from being
processed like a normal up-event by Emacs?  I think there are cleaner
ways to do that.

Re: Closing popup causes mouse event

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 18 Oct 2005 22:42:37 -0400, "Richard M. Stallman" <rms@gnu.org> said:

> However, to fully implement the idea of events that Emacs should not
> touch would require more change, as you said.

That actually interferes with the C-g handling.  So, suspending
asynchronous input on a mouse-down event was not a good idea.

> Why does it matter if that up-event is processed by the menu's loop?
> If it does not get to see the up-event, does something go wrong?

Of course, it depends on how the event loop for the pop-up menu is
created.  And nothing goes wrong at least on Mac OS X as far as I
tested.

> Or is it simply a matter of preventing this up-event from being
> processed like a normal up-event by Emacs?  I think there are
> cleaner ways to do that.

I'll try that.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp