[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Closing popup causes mouse event
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: Closing popup causes mouse event |
Date: |
Tue, 18 Oct 2005 11:35:37 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
[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
- Re: Closing popup causes mouse event,
YAMAMOTO Mitsuharu <=