From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp Date: Sat, 09 Apr 2022 18:03:20 +0800 Message-ID: <871qy6o9p3.fsf@yahoo.com> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <20220407133623.9C209C009A8@vcs2.savannah.gnu.org> <87ee28xyg2.fsf@yahoo.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25410"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 09 12:05:27 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 1nd7y9-0006RP-TZ for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 12:05:26 +0200 Original-Received: from localhost ([::1]:35784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd7y8-0000LN-Jb for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 06:05:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd7wM-0007Kr-PK for emacs-devel@gnu.org; Sat, 09 Apr 2022 06:03:34 -0400 Original-Received: from sonic314-20.consmr.mail.ne1.yahoo.com ([66.163.189.146]:35896) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nd7wK-00027j-Nn for emacs-devel@gnu.org; Sat, 09 Apr 2022 06:03:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649498609; bh=B64vBzFDe8CaFleDN83vA6xMeQYlAVNKNE6KcCNy/14=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Ka7BRDCdszxIxoEZz32T8m4Q6Bp+Z0BoV5YBzMqbS09OGEZ7gf8kdxghVTg2FaOs8hJA3fx4X0RdpbKtZ8BGuWZJ+r5jc/BARNkNXTqEs1SItNdBztxKBhrQp7BAt1khG5jr4kVXiGqdrBi1A5/zc/7MilnXsc8mSp3yJQkmo1wLZGOwKc6Y49XkywqNAN737rY2lKGRYTspnIgMHRuZ0raDu62WYmzIK9c8GZAbMI6Jl4blb85SvEC9u1nL9fXXRCWAGIVr33CPDr5CFSSTkDV6Gr8lOHoOF//IqUZhQi+1j4DcPW/rT28H0aSc/ubHgvVz8k45ijEfDPVQRxcrsQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649498609; bh=dscT0R7VtgZRJ8p2XHxmS98RbjP9LDZSsib2usVza8E=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=UnqBrZ9LI0onNqNycS2hzeGbYVV/4D/79fceS9K/fg6leAzc2F4pGSGrGnlr7i2qGpCHW7Vj7QkI+TYxnYl2/OZbhLG8k00q2WWmG2X0Kbqu4k2IbHHiJnBpcCyC2MtvgSsgFu8LqKcSNC+dy1QOVbG/4HLfLBU17OIVgABjAJ1m7PplUTNJ0ltDpGf6KRLOGVjnrnslEJ75rF2s+Pg/GbYOBzMmCaeDgZvorizq8DFEoks3GDxnsSdUJa6Ihj2nY4Ag7NmJ2dPjQPgKb68OpN42gM8I6HM6J5vNsaP8TjfeT4KGvEyjl3g2aXqp/QfKK47hQ+KKS+t+1p9i7iIvbQ== X-YMail-OSG: Y0Td3S8VM1lz.eOMTY8V4j3vBMg7S1wRuYTczWi5Yb8Vg9hRQE4fzbafNDQC6ed IMXe6yb1AVV6ydy4bse5VIWOQ2dSRS1.Y4XEhgjcltFz4xPaAru55jJIX9nArteypC2mjZrabDZ3 1lS8n1nDfjTA.xLj5dZuWsYNjtUu2YWQx5NrOiaPzEVMv9Yzi2VTJqkpwom.VE3I41g7KsOtT8im WN1bXm8ZTM.gJe5eyeIQYYSHe2P6LfCeP.3nW7idVce5Ppl6NtLDXf.Qhe5fiq8AFFNxn0ex7kD1 IUwjGqiL59UrBF8RmMQ3yF4I1NZ2o3LQRX8M2AlWvzSiA_MHUQRj24K1OBpoprIkcqBqFGUgr.AI 0AGMqdGzoHmzlxaix5.CbNKP.t122HyCjmB0XBSpB_Kl5jFVKILsXOuU7E1UPkEj5Gwf3_mk.hKV XTMeAvItzupUOFkLZeL44c5HqgV7EeCkeBqWqNytE8eytq7Y95tvgH67v.4xXkMhJdxygeldE5y. MixjkGD8PegOJb53Sls5HmhHTYi_dv0jG6oQWtmZFvliesBObJjKrnNr4d2hd3X1K0uSCWGZJuDM aJmmkKELf3UoX7Ey_XuJ8LqV5m.Mdmqw1gtJuAuGJgm55njNbDOrQ1bfkw_z3kUCvHZj_3usdyFz nqNvIElURvk59IV5aKl1cjXbxMuPwdSCpQafOprP54833H8jjjQQ.2IuEvwndN9FVA08TwkvQ9aG fmxUiQD47HaYpF0NLOpakvTRvQ53UN41Wb.iTznS0xT0RsVh.IG327InI3ze0SYg1OMgoc.pCIPC M3QGn0LO.rOEnxc.dTciE86XoCjbnlO5G7EBeRVL.L X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sat, 9 Apr 2022 10:03:29 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-8hnzk (VZM Hermes SMTP Server) with ESMTPA ID 09583db1e56b0498eff1f4082a768763; Sat, 09 Apr 2022 10:03:25 +0000 (UTC) In-Reply-To: <83v8vi8uyu.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Apr 2022 12:30:33 +0300") X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.189.146; envelope-from=luangruo@yahoo.com; helo=sonic314-20.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:288011 Archived-At: Eli Zaretskii writes: >> Well as another example, artist-mode might want to behave differently >> with an "eraser" pointer, removing pixels from the picture instead of >> adding them. > > Why cannot this be handled by producing special events that erase > pixels? Because this puts us on the very inflexible path of adding special events for every single input device that users might want. Besides, the erasers send ordinary button and motion events, specifically so that programs can better consume input they generate without needing to handle a special new kind of event. > I still don't understand why special-purpose events cannot solve the > same problems. Maybe even specialized mode with the same events. >> That won't be very flexible, and it'll be very difficult for the user to >> write customizations for some new kind of device (or just a different >> device) without adding an entirely new kind of input event for it.=20=20 > > Please explain these two counter-arguments in more detail. Why "not > very flexible" and why it will make customizations more difficult? Let's say the developers come up with a special input device for entering notes. Such a device would have a special name, and send either key or button presses. Without exposing slightly low level information about the device itself to Lisp code, users of such a device would be forced to ask us to add an event specifically for that device, in order to use it in Emacs simultaneously with other keyboards or mice. We would have to add events for every device users want to use with Emacs (and there are many, ranging from electronic keyboards to foot pedals), or we could simply expose the information necessary for their own customizations to identify the device. The device names are guaranteed to reliably identify a device on GNU/Linux and other systems that run X Windows or Wayland. If the feature does not completely work on other systems, too bad, but I think it can be made to work on NS with sufficient coaxing, and probably on MS Windows too, via the "wintab" and "winpointer" APIs that GTK and Firefox seem to be using. > And why is that a problem? We already interpret mouse-4 and mouse-5 > as the wheel, so why not have mouse-8 be interpreted in some special > way? Because mouse-8 is already the horizontal scroll wheel on normal mice. The point is, the graphics tablet buttons send the exact same events that ordinary mice do, but users might want them to behave differently. So there has to be a way to identify each device connected to the computer. And with some use cases, we simply want different devices of the same type (ordinary computer mice) to behave differently. >> And what if the user has two ordinary mice connected, and wants one to >> behave differently from the other, in effect giving him an extra set of >> mouse buttons? > > What about it? Why does this require to know about the device, and > cannot be expressed as special events? How would you decide from which mice ordinary button events should come, and what others without knowing their names? Or some other unique identifier, A.K.A a name? > Please tell more: how do they behave differently? If you press a key > that is labeled with some character, doesn't Emacs receive a keyboard > input event with that character? Let's say I want to insert "=D0=B7=D0=B0=D0=B2=D0=BE=D0=B4" from the Russia= n keyboard. If I don't manually switch the active keyboard layout on the X server-side when I start typing, the characters the X server sends to Emacs are in the US International keymap, so that becomes "pfdjl". Similarly, if I want to type "factory" in English, I have to switch the active keyboard layout to US International, or otherwise what is sent to Emacs is "=D0=B0=D1=84=D1=81=D0=B5=D1=89=D0=BA=D0=BD". While with the feature to retrieve device information as it is currently implemented, I could eventually configure the input method to be `russian-computer' when the device which sent the keyboard input is named "Innovation HID usb keyboard" instead of "AT Translated Set 2 keyboard", the built-in US International keyboard on my laptop. > We could have a keyboard-layout switch event, which would change input > methods automatically. (On MS-Windows, we already have such an > event.) Once again, low-level code does know about these details, and > that is not a problem IMO; it is exposing that to Lisp as "device" > that I don't like. That would still have to expose some way to uniquely identify each keyboard to the user. At the very least, we would need an alist of keyboard device names to the correct keyboard layout. Thanks in advance.