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: Sat, 09 Apr 2022 09:48:49 +0300 Message-ID: <835yniah0u.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> <83v8vjai4s.fsf@gnu.org> <87bkxbsqfl.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4371"; 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 Sat Apr 09 08:49:56 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 1nd4uy-0000wL-9X for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 08:49:56 +0200 Original-Received: from localhost ([::1]:40430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd4uw-00057P-RO for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 02:49:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37840) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd4th-00047L-2I for emacs-devel@gnu.org; Sat, 09 Apr 2022 02:48:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40384) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd4tg-0000mo-LP; Sat, 09 Apr 2022 02:48:36 -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=epAFALDDM8IDbMJW3MyZ1u2nnfkFp4G6H0XdWR7dzS8=; b=AOWEHJgKbNia yCGyKdj00pCGrTVxVjdPttU85oGK34umHInMVBUsuOPDYoDqzNErYfMDE9a785l+fVcuX/jKhNlbV ook7ALiggxJd4dCGFsd3k713oeMdDSLAbRFB/e4mKTXHcWr4IDTvaGcZLqBb5+MnIMAvNvppGl81V psz2FMwMWyxcTM3fQZOpkWNTJWhECQ1jNSm3h8aukYcbG6hOADcjc0e2IjM/WBdUo5uhD8hESqXsc yNQlP1r7muK/schkQRGlSER4o4C+Urw7rFvwnWeUBFYLPGGM4SUw004ASmKvEgvR++1dqdTtIK8Iy WQ4gU998/tdIebg8yLICyg==; Original-Received: from [87.69.77.57] (port=4233 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 1nd4tg-0004bg-4f; Sat, 09 Apr 2022 02:48:36 -0400 In-Reply-To: <87bkxbsqfl.fsf@yahoo.com> (message from Po Lu on Fri, 08 Apr 2022 20:35:58 +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:288000 Archived-At: > From: Po Lu > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 08 Apr 2022 20:35:58 +0800 > > 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. And you never explained in enough detail why we would need to know about "devices" when we use other event types. You said something about keyboards, but I still don't understand why we would care about the type of a keyboard. What other kinds of input could need this information, and why? > > 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.) That was not yet demonstrated. Though every system has some notion of "input device", the information they expose could be utterly different and not necessarily appropriate for us. Your additions express devices as strings, and strings don't necessarily carry any useful information to explain the significance. And I don't think you have explained anywhere what aspects of the "devices" we'd want to know about, and why. That is why I maintain that we should first think about the functionality we'd like to implement, and then see how best to allow Emacs to do that, instead of designing that bottom-up from the hardware level. > > 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". I'm sorry, but this just repeats what you said already, and what I see in the code you installed. It doesn't get me closer to understanding the real issues. What is the "device type" and what is its significance? Are you again thinking only about regular mice vs touchpad? if so, I already suggested an alternative way to implement that. If "device type" is about something more general, please describe those more general aspects, and please try making that description as close to exhaustive as possible, because we need to see the general picture, not just its few isolated corners. > > 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. And I suggested an alternative for dealing with these differences: new kinds of input events. AFAIU, going that way will completely avoid introducing the notion of a "device" into input events. > > 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. I cannot disagree more. This leaky abstraction will soon enough be all over the place, just like with colors or mouse decades ago, where Lisp programs ended up testing for X as the only condition to assume support for mouse or colors or multiple frames. Telling Emacs Lisp programmers not to do something is not a good way of preventing them from doing that. They will do what's easy and possible, disregarding our advice as they see fit. We will be unable to control that efficiently, not even in core, because we cannot be omnipresent and omniscient. > 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. I'm still waiting for enough examples of this to even agree that it's an issue, let alone an issue we want to solve in Emacs. > 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. We do? why? I think we definitely DON'T. Emacs is not a GUI toolkit, it is a client of such toolkits. We use toolkits because we do NOT want to deal with device-dependent behavior, we want to use device-independent abstractions. If some device is unable to do something, it will not produce events that express that functionality, and the corresponding Emacs commands will not be invoked. That is all I think Emacs needs to support each input device as appropriate. > 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 don't think I understand. What would you like Emacs to support in conjunction with Xkb, and what will Emacs have to learn about that for it to "understand" those "configurations" (and what are those "configurations", btw, i.e. what discerns one "configuration" from another?).