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: master 3b41141708: Expose the name of an event's input device to Lisp Date: Sun, 10 Apr 2022 09:44:07 +0300 Message-ID: <83y20d7808.fsf@gnu.org> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <83ee28az95.fsf@gnu.org> <87fsmow1hz.fsf@yahoo.com> <83a6cway59.fsf@gnu.org> <87tub4uivu.fsf@yahoo.com> <83y20fakwn.fsf@gnu.org> <87o81bu7zj.fsf@yahoo.com> <83v8vjai4s.fsf@gnu.org> <87bkxbsqfl.fsf@yahoo.com> <835yniah0u.fsf@gnu.org> <8735impqw4.fsf@yahoo.com> <83v8vi8uyu.fsf@gnu.org> <871qy6o9p3.fsf@yahoo.com> <83o81a8qnd.fsf@gnu.org> <87zgkulbuu.fsf@yahoo.com> <83ilri8iag.fsf@gnu.org> <87k0by43an.fsf@gnus.org> <87bkx9lqno.fsf@yahoo.com> <8335il8p4c.fsf@gnu.org> <874k31h3kz.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9604"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 10 08:45:59 2022 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 1ndRKg-0002K0-Vc for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 08:45:59 +0200 Original-Received: from localhost ([::1]:53452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndRKf-0007m3-Gw for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 02:45:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndRJ6-0006xw-Hg for emacs-devel@gnu.org; Sun, 10 Apr 2022 02:44:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37698) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndRIx-0000s5-Tu; Sun, 10 Apr 2022 02:44:18 -0400 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=ABxjUhkNdVgXCHK7H75GTdX7GCwHI9ItBUr7Q/LkBLA=; b=OzKOo+VUQu0+ gwF2FS7P36oxYDwWeij4UyYPml445Z3h68wQvCZbSkSgXhTPf11gMVpy333TKe/fLs+eGteAdM/OS pEeymic3wqNCJgeDL4lxFHeFTZyoCs/99lx/BBjqLAAI7I7fSdA1T1/mtbAvogGxFe9ZxwyThk+6M l/TDpw+3ZRL2NGhuhTFuLThCu3OKbeWKtVIbD2DKDsQC0vNOPDWFc8nRQNpLR6ACTV3wrVtrJ20Ne 9tdttDyzUpX9eDlPjd4zXKADmY8jrBKnntVUt6CHdLprjUU8UcSQcnQe0CQ9nK/ubnoEOSZTaAsZd x5W+up0CGzN8F+GsdBGguA==; Original-Received: from [87.69.77.57] (port=2936 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 1ndRIv-0007Ug-BY; Sun, 10 Apr 2022 02:44:09 -0400 In-Reply-To: <874k31h3kz.fsf@yahoo.com> (message from Po Lu on Sun, 10 Apr 2022 14:09:32 +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:288102 Archived-At: > From: Po Lu > Cc: larsi@gnus.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > rms@gnu.org > Date: Sun, 10 Apr 2022 14:09:32 +0800 > > Eli Zaretskii writes: > > > I think the usual Emacs abstraction centers on the events, not on > > devices that emitted them. So we should be able to have devices emit > > events regardless of the device type/nature/name, and then the usual > > Emacs machinery of binding commands to key sequence will do the rest, > > and will do it according to user expectations. > > It seems to me that abstraction was built around text terminals and > legacy X windows behavior, which changed with the wide adoption of > multiple instances of different kinds of input devices in X and > elsewhere. Slapping a derogatory label on some idea or code doesn't provide any real content for intelligent and flame-free discussion of the issue. An idea doesn't magically become invalid by calling it obsolete. Let's try to avoid such "techniques" of argument as much as possible. As things stand, I still don't see why keeping our abstraction in this matter somehow doesn't fit the modern input device technologies. Please try to explain why it doesn't, by describing practical use cases where the extant abstractions and infrastructures in Emacs cannot handle some situations or features, whereas your proposed design (or some alternative design) can. So far, every example you have given can amply be handled by the existing machinery, AFAICT. > > The key doesn't have to be a device name, it should rather describe > > the general type of the event/functionality. For example, all the > > devices that have foot pedals could emit events that begin with the > > same pseudo-function key 'foot-pedal'. Even if the device is called > > something else, and even if the device is simulated by some software > > that takes input from the keyboard or the mouse. > > But we cannot determine whether a given device is a foot pedal without > the help of the user. Who is "we" in this context? What level of Emacs input processing does this "we" allude to? My point is that the level on which devices could be important is below the code which inserts the events into the main Emacs event queue from which we read events as part of our main loop. If we agree on that, we can stop arguing about making Emacs aware of the device types, because the only aspect that worries me in your design is that the device type should be exposed to, known by, and actively acted upon on much higher levels, like the commands bound to respective input events. That is something we should IMO try hard to avoid. > > Users cannot customize the low-level layers of event production in > > Emacs, that level must be coded by us. We shouldn't try aiming for > > this goal, because it is basically unattainable, certainly as long as > > we use the window-system messages as triggers for producing events > > eventually exposed to Lisp. > > Then we won't be able to know what a foot pedal is, because presumably > foot pedals just name itself something we cannot guess, like "USB USB > Keyboard (1)" or "FlexMatrix HID Keyboard Controller", since it's > pretending to be a keyboard. I don't yet understand why we _should_ know or care about that. If a device pretends to be a keyboard, but emits events that "normal" keyboards cannot, we can still process such a device by pretending those additional events are some special function keys. Like we do with several window-system messages already, and even with SIGUSR2 signal. Is anything wrong with doing the same for those devices you are talking about? If so, what exactly is wrong and why? Once again, please reply by presenting specific use cases where this paradigm cannot work well.