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 14:03:50 +0300 Message-ID: <83o81a8qnd.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> <835yniah0u.fsf@gnu.org> <8735impqw4.fsf@yahoo.com> <83v8vi8uyu.fsf@gnu.org> <871qy6o9p3.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27055"; 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 13:06: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 1nd8vY-0006tm-Ru for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 13:06:49 +0200 Original-Received: from localhost ([::1]:57422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd8vX-0002Fk-R0 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 07:06:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38712) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd8sT-0008In-S5 for emacs-devel@gnu.org; Sat, 09 Apr 2022 07:03:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48168) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd8sT-0002xc-HU; Sat, 09 Apr 2022 07:03:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=AIFKLYRTEqCsbFsocRPYbssFPOLrrU54qI6TnwPo96Y=; b=AXuXcfvkfmkP15tO2Di/ vP3mzlxDN1538S22SmpLPQciYqS72yXIGEXgNBFeObEoWhsGfzYfpom4xBETUHzFx9iC/l3JhqD/W AiuoZWclcXX7s8q36yB8pFXH+/A+y5CF8ckOl6w/soy3MHwlPag/18cOCxekNN7mH/zWRj3cJVYUP rs1Z4qFDECJdvpkVrGiJLSbtFYETJ79yKeZ0BTIJD096gMg76Q8l8824dQHeo+SEh8TrPJDTjmFNK tABq8H4/MIqU/zuYsaMfJHADl6ogrERa3FqKm5ziR3gQNmuVlJqVqoZW12kKEZrwN+cAlRF85y4/K 1z6eLVoXS3H+xg==; Original-Received: from [87.69.77.57] (port=4630 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 1nd8sS-0006T4-TS; Sat, 09 Apr 2022 07:03:37 -0400 In-Reply-To: <871qy6o9p3.fsf@yahoo.com> (message from Po Lu on Sat, 09 Apr 2022 18:03:20 +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:288019 Archived-At: > From: Po Lu > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sat, 09 Apr 2022 18:03:20 +0800 > > 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. No, only for events that are specific to the device and not available in other devices. > 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. So, with your current design and implementation, what level will deal with the device type and decide how to handle each event with the device type in mind? Events are bound to commands in Emacs, so does this mean each command will need to know about the device to DTRT? > >> 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. > > > > 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. And what would happen instead under your design and implementation? won't we need to add code to recognize the new device? > The device names are guaranteed to reliably identify a device on > GNU/Linux and other systems that run X Windows or Wayland. I don't see how can you so sure about this. A name is just a string. With devices development these days, chances are what is a unique name today will cease to be that tomorrow. In general, I have hard time imagining that modern systems let you access the precise and detailed device information, because (AFAIK) modern systems typically hide this information from applications. > > 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. How will this different behavior implemented, under your current proposals? Which code will deal with the device information, and how will that eventually affect behavior? Please show code examples if possible. > >> 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? By appropriate numbering of their buttons, for example? > > 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 "завод" from the Russian 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 > "афсещкн". > > 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. Instead of doing this on the level of input methods, why not do this where we produce keyboard key events, by converting the keys to what they are supposed to mean from the user's POV? Then none of the higher-level code will need to change, and moreover, users will be able to use these different keyboards with input methods unrelated to the keyboard type handling, whereas if this is done in an input method, one cannot have another input method active at the same time to use the characters that come from the "translation" input method. > > 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. No, we just need a mapping from this event to an Emacs command that will do whatever is needed for the event. And users can customize that command if they need.