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 12:30:33 +0300 Message-ID: <83v8vi8uyu.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31316"; 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 11:32: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 1nd7SE-0007wD-LT for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 11:32:26 +0200 Original-Received: from localhost ([::1]:47670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd7SD-0004i7-9n for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 05:32:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd7QD-0003kr-AH for emacs-devel@gnu.org; Sat, 09 Apr 2022 05:30:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47156) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd7QC-0006Fd-W8; Sat, 09 Apr 2022 05:30:21 -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=JEhP3SQ0/9VPbU5R9Ar8NlmMT5KpKnelII7U+iWh2s8=; b=mRqrBDnXrVZ+ JdYxQ7769G4M9gMl2mSgJPgcyL9w5n3ar8+juKhLahvWVJU98XRW1g/g+DgxnCuZfMbcajaLqZEp/ 3VYdIuTY7mOkWthyR0s/cEwPE+pqulzbDnrT9WE++Ot7PBB6RpF34QCxgKNl6NGEcEK5jxCXL+HBH MxLMDAlpsgB5xcQcHMmQUTlZtXxTTQ+o4dOiOxUO2c+H2AFUr1xRA2cN0iL1Sam+zWNIyLQeFUSFe LL/dim95t9XwZk4wZlGPA71myRdi1vPWETaMaQNpw3gv6AWQXFiY4bthE0z0J33ZHZ9ZCMp+UxMw8 rS2cPHDUNqEiBiawaaJfWg==; Original-Received: from [87.69.77.57] (port=2557 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 1nd7QC-00056y-8m; Sat, 09 Apr 2022 05:30:20 -0400 In-Reply-To: <8735impqw4.fsf@yahoo.com> (message from Po Lu on Sat, 09 Apr 2022 17:06:35 +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:288007 Archived-At: > From: Po Lu > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sat, 09 Apr 2022 17:06:35 +0800 > > Eli Zaretskii writes: > > > 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? > > 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? > Different keyboard might have different layouts (and input > methods want to behave differently) I don't think I understand why, see below. > or lilypond-mode might want to insert notes directly from a MIDI > keyboard while allowing typing from a normal keyboard. Again, why not implement this as special events? > > 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. > > We want to know whether a device is a mouse, trackpoint, eraser, pen, > puck, device control, keyboard, touchscreen, touchpad or MIDI keyboard, > and whether or not it's a different device from some other device, and > also tell apart a single device from anotherq whenever possible. I still don't understand why special-purpose events cannot solve the same problems. Maybe even specialized mode with the same events. > What would you think about allowing the device structure to be something > other than a string (i.e. window-system dependent, like the argument to > drag-n-drop events), that should be treated as opaque except when passed > to functions like `device-class', and probably `device-equal'? If we must. But I'm not yet convinced we must have this information. > > 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. > > 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? > > 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. > > To most programs, the graphics tablet buttons are just mouse buttons. > In Emacs, they will just send mouse-1 through 8 when clicked. 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? > 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? > > 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?). > > The simple use case of having two different keyboards behave > differently. In my own specific case, they are printed with different > layouts (one is US International, the other is Russian), but X only > allows one keyboard layout for both the keyboards to be active. 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? > So to me, it would be nice to have different input methods for each > individual keyboard, in order to not have to manually switch input > methods each time. 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.