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: Fri, 08 Apr 2022 15:12:35 +0300 Message-ID: <83v8vjai4s.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11031"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Fri Apr 08 14:14:49 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 1ncnVp-0002i5-7U for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 14:14:49 +0200 Original-Received: from localhost ([::1]:36802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ncnVj-0007GE-IE for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 08:14:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncnTW-0006UR-Tj for emacs-devel@gnu.org; Fri, 08 Apr 2022 08:12:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58190) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncnTV-0005oY-UE; Fri, 08 Apr 2022 08:12:25 -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=HSoGJNzml04DcJ8PIub246yT8LtFVb0J5X6RD1q7zMk=; b=f4C/KxPPjdeO wQPZ75NvPN1HUAvlYS9PXHSjiGxGeD3coSzChD8SkNnwH7Ajqa30IbRxqXWb2DYc0uv85+u8vsf+E N2qPdb+1koyimAG4/grrRMVsRDL0rpSEUgEtK6DSl0gTx/TTvU3Am+L77RJXZfjlmH6/wv6PNvJQg mdtOAPmdecK612+kEHTnD7DJm7Ymq56Z3DcF/0o0fYr1MB9GQ1VS1nmZZaHuRSm7KTRO/817oiLyC bPQ7/MiI1D67hgdRYPBSz7rVN72pae8/xhW4lv7QEuZH3py4Yj3ppAx67fr9my9PXnmH3B9ij/pe5 UDfY0FuxO+PjyzcgAmYmrA==; Original-Received: from [87.69.77.57] (port=2556 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 1ncnTU-0003in-3p; Fri, 08 Apr 2022 08:12:25 -0400 In-Reply-To: <87o81bu7zj.fsf@yahoo.com> (message from Po Lu on Fri, 08 Apr 2022 19:31:28 +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:287953 Archived-At: > From: Po Lu > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 08 Apr 2022 19:31:28 +0800 > > Eli Zaretskii writes: > > > That suggests a different strategy: produce different input event > > types from each such device. That'd leave the device dependency to > > low-level code, and let the application level deal with event kinds > > and not with device types. I think this is a better abstraction, if > > it's possible/feasible. > > I don't think it's feasible, especially since there are too many > different kinds of events, and with some of them those dfferent kinds of > events simply cannot work. (Think single character keyboard events.) 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. > > We have been burned by modeling the application-level features on the > > particular X implementation and low-level details. It took us > > literally decades to get rid of X-specific code and features, let > > alone API names, and move to exposing more general and more adaptable > > APIs to applications. I was there when this hard lesson was learned, > > and I'd rather we didn't repeat those mistakes. > > This API is not X specific at all; in contrast, an X-specific API would > be to expose the list of device valuators and "classes", containing > various flags. It is X-specific in that it's modeled on what X exposes. > When designing this feature, and why I purposely didn't design it based > on the X concepts of device axises and classes, I worked from two > directions: it should be possible to extract the type of a device > (i.e. tell between a touchpad, a keyboard, a pointer, and a piano), and > when possible (i.e. supported by the window system), it should be able > to tell individual devices apart. The current API achieves the first > goal by giving each device a "name", which contains enough information > to determine the device type, and it also achieves the second goal by > guaranteeing that the device names are unique to each device on window > systems which support that, such as X and Wayland. > > Each window system can then define a function for `device-class', which > returns the type of a device based on the name given to it. 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. 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. > This feature was already implemented not just on X, but also on PGTK, > which means it also works well with the very different input subsystems > of Wayland and Broadway. I also wrote the code to make it work with NS, > but it hasn't been tested yet. I appreciate the hard work, but I still think the design principles should be discussed. They should have been discussed before you started working, for such a non-trivial new feature, but that's water under the bridge. > > That doesn't mean you want to know about the device, it rather means > > you want to know the keyboard layout: an entirely different aspect, > > and not specific to any OS. > > You would still need to be able to identify the keyboard in order to > know its keyboard layout, at least on X. 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. > > IMNSHO, it's too bad we rush into implementing such features without > > any discussion. See above about the alternatives that, at least at > > this time, seem much better to me than dragging the low-level device > > type information to the application level, and in global stateful > > variables on top of that. > > > Which once again favors the alternative that would work by defining > > new kinds of events. That alternative has no compatibility issues. > > IMHO we cannot simply define new kinds of wheel events that purposely > separate touchpads from mice, or mouse-movement events which separate > trackpoints from mice. That would mean, from the perspective of the > user, mice would continue to "work as before", but trackpads would not. 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. > Or a keyboard with a Greek layout would not work as it used to, while a > keyboard with an English one would. ??? As long as Emacs reads characters, I don't see how this could happen. Please elaborate. > 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? > 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.