[The original report was posted to emacs-pretest-bug]
>>>>> On Tue, 18 Oct 2005 11:03:35 +0900, YAMAMOTO Mitsuharu <[EMAIL
>>>>> PROTECTED]> said:
>>>>> On Sat, 15 Oct 2005 22:34:29 +0200, [EMAIL PROTECTED] (Kim F. Storm) said:
>> David Reitter <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
