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: Sat, 09 Apr 2022 17:06:35 +0800 Message-ID: <8735impqw4.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> <87bkxbsqfl.fsf@yahoo.com> <835yniah0u.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="38684"; 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 Sat Apr 09 11:08:00 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 1nd74a-0009u1-0c for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 11:08:00 +0200 Original-Received: from localhost ([::1]:35904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd74X-00044R-Ll for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 05:07:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd73T-0003Jb-HT for emacs-devel@gnu.org; Sat, 09 Apr 2022 05:06:51 -0400 Original-Received: from sonic313-56.consmr.mail.ne1.yahoo.com ([66.163.185.31]:34724) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nd73R-0002iG-AY for emacs-devel@gnu.org; Sat, 09 Apr 2022 05:06:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649495207; bh=fj+/bkdal1vFAC4rrazlYliFNYciNL3yRkFCMiUJjds=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=qrJvUnnNjYT+TLKJAuPbeibAVoENNudRi+AucQLS/pZHPqOqCXN/aTzSaf0S2IgqDu6QG8WvTZvi4Mrk4mGb1rdFxksfele1D2coii6i2mdqLFCv1dLsTPceQ1zbA8lFEgliuodtmnQ8PEuV/SmadQ8OppAmy59jZmquJJ+c3Fz+XPo0UPjro8UP0BEkZFvv9fxhZvotUDqpo0FRkI2rOgbJKKmQPgeYnBFj4o+7QHNh9MRKm1Kx2TRTBE9jpbgjE7Dm6O13WbvVKCIFPKfOgB6ZbjhJ15DrPF97/Du8z02tMgV9HuTsV0kk3VMQP2Vge/qGpqo9N4GJMN91oU6b7w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649495207; bh=PD221BEqtBJqydxNRAX6+o1TOUMXfQDk9018qK9Ebr9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=jRE77fjBJ6oJpqbAcrfjDke0oQWkQVfnhZ5wacS1wTQr0Vi71assBH/VAJq4lAKNU7XYGaPMyDZ7XEDOR1YZQ+Er3R8JVuiMRIMms1u6Xe/v3RoGWkbKBa4ntzItLmaZmWm3lS6qSJtYcGSMkQLA0iRb2e1p+k2lN9S1I1w0kpTNvKVFgNeuVGQK81ZMnCnM5n7iN1P5FvqJ13JSXM0ZfH6PPpEh+59Oc2FmEnQFwiI6hdvHATZ015MLKYT0rTVYmVk9o92SK7stn9UzGL2MXq4/Jevr4y9TqfeSBIzHbLBl24xzP+t83ZUD00ZUiTPlt9P6E5KHXV6D/oeH01JLWA== X-YMail-OSG: e.bFQT4VM1lBmYcQgfEgtboVs2ltCYQzydb0HcUpyX7.fQyPGsffhPhDd2ton57 82I_uxgIkuRY.LecFHJG7Enh3oYkOCjWhIaGl5bQ.knJLLqrui9sUVE1J6LhEqJRxcUd84saZI7q yrto51YWh8a4l.KiBsg7CJ1Lh03Olod3mOjg31TO8DSOv3pSu0r.lItCYX2dVj.QoqmaGHMKwUlK ZVTg2x1DPyxEAPIOyKXOUsGWjhi4wNaoHA3yawFR5Bw3IrIxS6dSCJgBPZ2dtNYPYu_waeW3c7SY kHpIln6oWYr5m2TplOda9JCWYpm_CcENK0fio.Cqm8Lc_iBj8U7KtZ3W.swnr2LG_CDwpw7y9jEf J_oNieNH2.MlCN85.vOMMuWDdrpvPdaf25nRUWGaxx_NAcW2GZ0BJHM5su0fodBIZZ0PP2CN0HpP Ox.iozAQfAzewaQ4C9VHRjWKdg2Z7HP.QUqoN5kV0LRf0UFTTF8rtAtpPs193KmiLt06y7wR.NpX _GfxdjeKM8aGj28y9d1FneplysZ9Bsr9soJjFpt2gA1rFW8emuFDlCdHhYirqHSkIA6wxVqwVNHe 5PMY.89vm5W7SyOEVuNQ6xu6wBp6WUblFFGDK2RgBPT8hskAwmNP4iecBK6THoD4i2Fn4jVE7hK2 djtSUlm1xYHxONT4wEAPJibXdjwLjaU9z47WYUbAmndGgWHXLKAYKmfL2XRFfHSHu6VjSzSwDOYk d1dEXrda3zLjeZRx5j93N_waTLTO6Jph1MWO2SL85SJTRFU6z4xdKBYFS5Yzv6ojrE4NzeUDug1s sLFi0En97DrBEshgWp_BdFoQjmgAUgeWFxkgtEMbcm X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Sat, 9 Apr 2022 09:06:47 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-rvrjv (VZM Hermes SMTP Server) with ESMTPA ID 0c03886929b527945d057fbfdc664d47; Sat, 09 Apr 2022 09:06:40 +0000 (UTC) In-Reply-To: <835yniah0u.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Apr 2022 09:48:49 +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.185.31; envelope-from=luangruo@yahoo.com; helo=sonic313-56.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:288003 Archived-At: 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. Different keyboard might have different layouts (and input methods want to behave differently), or lilypond-mode might want to insert notes directly from a MIDI keyboard while allowing typing from a normal keyboard. > 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. 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'? > 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. No, I was thinking of different kinds of devices as well. The list I chose to document in `device-class' should be a fairly exhaustive union of what the window systems we currently support have. They are (in no particular order) keyboards, mice, joysticks, erasers, styluses, pucks, device controls, touchscreens, tablet buttons, MIDI keyboards and test devices. Emacs currently doesn't have support on the C level for getting events from devices outside those categories, at least on X and PGTK. > 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. > 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. To most programs, the graphics tablet buttons are just mouse buttons. In Emacs, they will just send mouse-1 through 8 when clicked. 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? > 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. 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. But I'm sure this feature will be much more generally useful as well. Thanks.