From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Touchscreen support Date: Mon, 20 Dec 2021 17:18:19 +0200 Message-ID: <831r272tl0.fsf@gnu.org> References: <87czlxkntg.fsf.ref@yahoo.com> <87czlxkntg.fsf@yahoo.com> <87mtkziwhi.fsf@yahoo.com> <87wnk3h0hn.fsf@yahoo.com> <877dc2xsjn.fsf@gnus.org> <83y24i9diw.fsf@gnu.org> <877dc1cug5.fsf@yahoo.com> <834k759fkp.fsf@gnu.org> <8735mp9cch.fsf@yahoo.com> <83y24h7xdz.fsf@gnu.org> <87o85d7x49.fsf@yahoo.com> <83pmps96gt.fsf@gnu.org> <87czls7rdk.fsf@yahoo.com> <83mtkw79y4.fsf@gnu.org> <87r1a85c5i.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10934"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 20 17:05:54 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzLAf-0002Yb-Nn for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Dec 2021 17:05:54 +0100 Original-Received: from localhost ([::1]:49376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzLAc-0001Su-FD for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Dec 2021 11:05:50 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38952) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKRS-00025a-Qn for emacs-devel@gnu.org; Mon, 20 Dec 2021 10:19:17 -0500 Original-Received: from fencepost.gnu.org ([209.51.188.10]:53242) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKRA-0006u5-Dt; Mon, 20 Dec 2021 10:19:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gROPEpejYox3MI/iDSQlogg4Beojec8TM27j6uk5/yo=; b=Be6kKj0a4mlh /fw79GRio+1IyR6tO4yiZDZzPzp6SbYSyuFhRcR2RqTxeJFW3XxEQZRTkvXT3+JTvNLImDEVFkc6X PIUjYC7/12f10L4VkkfVKK26v0EHdg2m9W95ETtJjT8Zti2jdKBw7BiY0wlgscut+E4SoxP9XB9tO JjQhMJgH21C+2v7w5O+azi03gGf2Yzo49Re7URmB3BqcGqy4oRjxtoXDuI0eQJ5xe7J1bQm3xRnnF 45M1nopA82HiQQVkdJxL1mOmP+LpHHSP8VPoU065eOjYRcE3sasqcrNn2mdKXpSDFUC4+W0t0dQ2+ zuhqoocWlOKRy57pRcwmrg==; Original-Received: from [87.69.77.57] (port=2762 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKQf-0002Ar-2n; Mon, 20 Dec 2021 10:18:24 -0500 In-Reply-To: <87r1a85c5i.fsf@yahoo.com> (message from Po Lu on Mon, 20 Dec 2021 08:54:17 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:282510 Archived-At: > From: Po Lu > Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Mon, 20 Dec 2021 08:54:17 +0800 > > Eli Zaretskii writes: > > >> From: Po Lu > >> 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.