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.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
