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: Fri, 08 Apr 2022 20:35:58 +0800 Message-ID: <87bkxbsqfl.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10948"; 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 Fri Apr 08 14:37: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 1ncnsF-0002gf-0N for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 14:37:59 +0200 Original-Received: from localhost ([::1]:51024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ncnsD-0001DN-Sc for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 08:37:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47182) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncnqX-00089d-SU for emacs-devel@gnu.org; Fri, 08 Apr 2022 08:36:13 -0400 Original-Received: from sonic304-21.consmr.mail.ne1.yahoo.com ([66.163.191.147]:36836) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ncnqV-0001O4-Qd for emacs-devel@gnu.org; Fri, 08 Apr 2022 08:36:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649421369; bh=fwGw1U6NyzUV/vJ8chR6etUOUGhliwmTVUc4pvBzOE0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=ng9oYwH51d0w6nwEZlW3TBn6PZL+a9B0RTzAfqFDZfPBU8+c4t6L7DnoJdqUpUQJM9x778lAiHUwFucHxnwfcT1EOxQ1SqhCaMc6GJntPGMFABXhQdHCWikE4uh+c5A3pVqwK/HExSl341spnGExNLDXxyT4z7iKy2fa1xX+JPhPHfGLtLVQPCq+kGk49fGtHeZRsH0A0aMDvOAZJpiFCWxxjs1O+lzHHKHoGgMMrBg+uwfJc5TqRMFoFo1hzs9AoAsSpKfllfE56WuXC7la19aC/ov43CRuOk8zzViQtF1ahtNl4k51Lq419s18Xv7YGomXUsA/GlQii9bpEhwd0g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649421369; bh=IOHe4VF4OpDZFjJ+nwMuiZRykcFT8GIgUxenBPSXOnw=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=IUN+lY8clQjU4yURhkLzV9IRwNV0FBPyxjFuUCS9FRS1Bw9ZS4waW0I9j7bCXtV84ALYNgq0oyODqlDeBv8lC87xQgRy23oexyTwUHS4E6uEDq52c4sf0vOXRuJz7p7ULSCeH6q7/FyFXNq5mACYdGq+4Sdu6KFtH5Q7Xejt3D+fNpl9XaghW3sl0ECvF5NEI89oPY2suYBw1kh7WrB2Qa5LyNnKCd3enK7EON+Tcsvo8eLi3OLnFy72IUq82NCbECxf5ZIXZGUfYFR8s+ylHOrXgfxM2r+eskNXZAVdxH3Gid9ejEtk1x94hZpVeZJnoHgWD57/zDIUtCcQdy9nzQ== X-YMail-OSG: rykqtt4VM1lhVxxVITnnAXl8RQva4ylgmyQLsxsdpcy2jluJngeiIly4NewOC5k tzGGe9JcnJYVSK6xWTABqm3U3I9eIUe_1clNZmeLkyy8Q3ljDgbjixZg_3M67xkzGVi3v.a0Ojpj NHTmKon4PrXrTRaIPVo.9kqRGoQwC1L8MhbrL_WPqbU_dM.g2Qf_sXQ4BAdBIePPUcXMyfN5IpgH Psidob34N.8aKcPpKd1EUTmSdE7ul4KEA2JRNoYKiaK4kvMCKhNCYiSU8YNVB.TubqB_6ZKSXzam rdr.warBZID9_Dm5r0RH83W6nxPEabKh5KqWWPnvkm0XaxDHORgfOrbKdYBAl5EYWRN3cHe8cmNp mxK9oIvBOdXwhy2Hu0JzJh0EoijCs8Gz.nCYvXau.EOhIhwB_ImR9EAHuvcpB5ptQ5H8g31lILRD Rus9ZENdtDDaw._9CAtSKa1Fz4Gdhvpb_Gj2dOJGhOp0qd_Y34BMgHocc6PpvMvqKnmH0jJX3rqT a5vsXDi_BUYSkea1186rIh1KUrvihw3wlrY1yPdo6qUhyvvs5_OajjLdL3tzfoNVvf5c12yF5yOD kL0aD9Ykj9793BrL1W_2eHKpSs4SWrDgAwdWGZDYPcuwjybs4zpTWZIcYte8MV3CN_fvY_5OHmCY nZJp4GKtSCT8GuuEPYJpfsOoIa7jKZbc6Og7ZDovTXliiqoT2UXUkhJRhGHQ.c.FGOG9Ab7HZzot yOAJbnUWWyypwPWC28D_uGZBLXn81AaljTMkUBGda50XLch7kIalJg7htkHRP_7Ja8BZL0iUVSgh VNzQQUbOpZk9HGKdJLM4qumIXyz_S59q1oLfv274V0 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 12:36:09 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-srcdp (VZM Hermes SMTP Server) with ESMTPA ID 1449e1be73d26b56918c260fe674a3b5; Fri, 08 Apr 2022 12:36:03 +0000 (UTC) In-Reply-To: <83v8vjai4s.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Apr 2022 15:12:35 +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.191.147; envelope-from=luangruo@yahoo.com; helo=sonic304-21.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=ham 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:287954 Archived-At: Eli Zaretskii writes: > We were talking about pixel-scroll events, not about character > events. If keyboard events also depend on the device, that's a > separate discussion. > > Let's not make the issue harder than it must be by lumping together > all the possible complications. Okay, but please keep in mind that this feature was developed to work with all events, not just pixel-scroll events. > It is X-specific in that it's modeled on what X exposes. But it's also exposed by every other window system (or at least can be trivially synthesized from the information they expose.) > I'm not sure I agree with this design, sorry. E.g., having a name for > a device doesn't necessarily mean we can know its type. The type should either be inherent in the name (as on X), or the name should be computed to include the type (as on Wayland). Otherwise, the device should just be set to the special value which says "I don't know what the device is". IOW, the platform-specific code is responsible for ensuring that `device-class' works correctly by defining the meaning of "name". > More importantly, as I already said, I'm not sure Emacs should care > about the type of the device that produced an event. We need to > discuss what kinds of decisions a Lisp program would want to make that > depend on the device information, and design the information based on > those decisions. I listed several: the pixel-scroll events are one such example, and Tetris is another. ThinkPads come with these funny joysticks that normally scroll or move the mouse pointer, but inside Tetris they might be used to control the blocks instead. Let's skip the keyboard-related discussion for now, since they're a somewhat special case. > I'm talking about what kind of information is exposed to the > application level, where we interpret the events. That on X and maybe > other platforms we'll need to have low-level code that looks at the > device is secondary. The current code exposes the device type/name to > the application level, and that is what worries me. I don't think giving too much information to the Lisp level is that big of a problem, as long as its use cases are carefully evaluated, and recommended procedures documented. Basically, there are two situations in which this information should be available: when we want some feature to behave differently based on the type of device, and when the user wants something to behave differently based on the device that is being used. The user could, for example, have a graphics tablet with buttons and an ordinary mouse connected to Emacs at the same time, and want the buttons on those two devices to behave differently. Writing such a customization would be impossible without exposing the device type and/or name to Lisp code. For the former situation, I think it's not a good idea to have code that might be used by other Lisp programs to depend on the type or name of the input device used. But it should be fine for interactive commands like pixel-scroll-precision to depend on that information, and perhaps even input methods. > That's easy to fix: we can add entries in relevant maps to remap > trackpad events to mouse event by default, or when some minor mode is > in effect. Hmm... I will try that. > ??? As long as Emacs reads characters, I don't see how this could > happen. Please elaborate. Sorry, I misunderstood what you said there. >> It's also not possible to consistently give an individual keyboard a >> different keyboard layout under X, since the part of the keyboard >> extension for that only works with the obsolete version of the input >> extension, not the new one that some programs such as Emacs and most of >> the modern toolkits now support. > > Sorry, I cannot understand what this means in practice. Please tell > more. In particular, what are those "keyboard extensions" that you > mention, and how are they relevant to the issue at hand? The X Keyboard Extension (Xkb) is the component of modern X servers that handles keymaps, and how it couples with other server extensions is orthogonal to having different keyboard layouts for different physical keyboards implemented on the server-side. In other words, if Emacs is to support such configurations, it will have to learn to understand them by itself. >> I'm sorry if I rushed things, and I'd be happy to listen to any >> suggestions you might have. > > Well, I did suggest several things. Thanks.