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 <address@hidden> 
>>>>> said:

>>>>> On Sat, 15 Oct 2005 22:34:29 +0200, address@hidden (Kim F. Storm) said:
>> David Reitter <address@hidden> 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
                                address@hidden