* Re: Closing popup causes mouse event [not found] ` <wlpsq3h98o.wl%mituharu@math.s.chiba-u.ac.jp> @ 2005-10-18 2:35 ` YAMAMOTO Mitsuharu 2005-10-19 2:42 ` Richard M. Stallman 0 siblings, 1 reply; 3+ messages in thread From: YAMAMOTO Mitsuharu @ 2005-10-18 2:35 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Closing popup causes mouse event 2005-10-18 2:35 ` Closing popup causes mouse event YAMAMOTO Mitsuharu @ 2005-10-19 2:42 ` Richard M. Stallman 2005-10-19 4:11 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 3+ messages in thread From: Richard M. Stallman @ 2005-10-19 2:42 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Closing popup causes mouse event 2005-10-19 2:42 ` Richard M. Stallman @ 2005-10-19 4:11 ` YAMAMOTO Mitsuharu 0 siblings, 0 replies; 3+ messages in thread From: YAMAMOTO Mitsuharu @ 2005-10-19 4:11 UTC (permalink / raw) Cc: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-10-19 4:11 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <7072A90D-5D49-4D76-97B8-0E2A66EA54D0@gmail.com> [not found] ` <m3k6ge8qp6.fsf@kfs-l.imdomain.dk> [not found] ` <wlpsq3h98o.wl%mituharu@math.s.chiba-u.ac.jp> 2005-10-18 2:35 ` Closing popup causes mouse event YAMAMOTO Mitsuharu 2005-10-19 2:42 ` Richard M. Stallman 2005-10-19 4:11 ` YAMAMOTO Mitsuharu
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).