Re: Touchscreen support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 20 Dec 2021 08:54:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: larsi@gnus.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> >> Date: Sun, 19 Dec 2021 19:42:31 +0800
> >> 
> >> > I'm not opposed to having parts of this in Lisp, but I do want to see
> >> > the events placed in the normal Emacs input queue, which probably
> >> > means that Lisp will be called from C.  Not sure if such design will
> >> > make sense in practice, though.  But OTOH, having events coming in
> >> > from another source, not through the input queue read by
> >> > read_socket_hook, is a complication I'd very much prefer to avoid (if
> >> > it's even feasible).
> >> 
> >> We could have an API that allows Lisp to push some kinds of input events
> >> to that queue, which is then read by the various read_socket_hooks.
> 
> > How would the low-level events, from which you want to construct
> > higher-level events, get to Lisp in the first place?
> 
> Through the usual event system (though probably as special events in
> special-event-map).

So the events from X will be delivered via read_socket_hook, then the
code which reads these events will call Lisp, and then it will turn
around and feed the synthetic events it produces back into the input
queue?  That's exactly what I prefer to avoid, since there's no way in
the world you will be able to pretend that the synthetic events were
delivered in the same place as the real ones: some additional events
could have arrived meanwhile.