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: Sun, 10 Apr 2022 08:48:48 +0800 Message-ID: <87tub1kbkf.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> <8735impqw4.fsf@yahoo.com> <83v8vi8uyu.fsf@gnu.org> <871qy6o9p3.fsf@yahoo.com> <83o81a8qnd.fsf@gnu.org> <87zgkulbuu.fsf@yahoo.com> <83ilri8iag.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27995"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: Richard Stallman , Lars Ingebrigtsen , 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 Sun Apr 10 02:50:06 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 1ndLmG-00072q-UL for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 02:50:05 +0200 Original-Received: from localhost ([::1]:36980 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndLmF-0005HD-KA for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 20:50:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndLlG-0004Gr-Jf for emacs-devel@gnu.org; Sat, 09 Apr 2022 20:49:02 -0400 Original-Received: from sonic310-25.consmr.mail.ne1.yahoo.com ([66.163.186.206]:44193) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndLlC-0003vw-T7 for emacs-devel@gnu.org; Sat, 09 Apr 2022 20:49:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649551736; bh=7OOT//YMajx752x0KyoY/i/c5a8eqfAvGjYzue7LM6A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=SIeJsFj60hc8d7fMZ4kfOE8QvpdZptA3KxEJ0Ezq0m3Ji1S4ZqRJ/Cy17MIXH0LFqaO/qgy15SSs7L4rDDSjJqkDUonP/RAJ0JUxpx9zys1tJnoUpCSHLHnELx+BoL01lHDXdpOaMKojPOepmjY+Y/9PjoJ9TpR/JyNTdz9FEhRhjeVKYynsdf5fmEiXgzJPTmS2mftnTCwLnJkhWVcKl7voLyKCfLHM576yrj+p9F54DO4vnKXii8AoCuM9o7LMIZJOdjScU4hGMTHWlqMTwwnIptkwFLs/oK4pwMjKgD5hYvCj9TlZl2UQYfFGx25gkBjlD2eUNSv/MyY+K2a3nQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649551736; bh=R1lpBfKXgKPt8cEJPojPoWde0PtP3u9WNi5LVZmRIOz=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=pR49qDQg96VEdh6jZBm3ChV3ShxAKaT+zb9YMojp/dDLKhpUHJPpyDfQ8VmtQ5B3rqe07HrG0Lg65u5OPhXbNwdRfVsoCo2YxtyRf9BtLUc04zvIVCRBpvOszr8ZuUZdBDZ25YPiUcwClgCpE+q8oC376oznmYZSt14TTe9GpyWOD/yHSFS+afaiIq/ALKCXuotQUc4WirCYyqS7SvZCtqhFu0qB25lapB4kNNEr72eB+HM43gtpO3K3nzPP1iPAOS2fM0np9g9cObXy3OcK0t1Cl6gEd09QE04/uOD2IrnK99UkjYT9HuYrZDtBAQuPdFftv4aNlAy52g4Sic+qwQ== X-YMail-OSG: h.sEE1AVM1nVvEe6JNpBw_ipfD1WcOwxXCJPFvuztRj0nvCWcFDbqyUgitHTh5w j2.iTpoUVBJyJDDpWx0n_bbYD7jXbGiPPPCYgvZjSA7eN7j_9NQGsnmYSDxmOjWUYMeyPeybwg6_ UtyFa4xg7Ey4Jq0q5MQCfN29RWXRnwRhBUap7aW7CMo9FQ8bsgLGdTZImGU4NncTC.dgV.PYtmZT 5geyOC2xTd.fJGZUyIAgL41YaMtnaDjv0q3.4cztfU3hdBZxqWfow9mK3LRJr7hmpiu2pMPtDw3e R_eaxx01gFy018XhMxpTcTD1HOMdvhvXLBZuiOgBsPbF_CReAZ4SMHL5DJDND9rofHTPmh2_P8FO KLR9YH3NgnAVdzBiS8uTueLp5XsZpa2D8hepC0SNx9WLze3ALlMM9nLsr0VWBhoaaC554b8_sy8p WZ3YLIWOInvA4XLfFmItYiy78_hZxA92Ni2gxa1VvEtaCPKH8b6xlcoFzrFz6Sg8T4BKnuBdm92W .QNtDF5681PE.maligazOmFkOHosIdBha6HvAxqyPUgIzs9rzZDftuZ.ohZTVVGKRr7sR5BOE9uT FgD0aM2FTyF32bC4uAu8pscmRzAeB3YBHGClndwBUOrDsFt.aq1OHWJzKO2W2MnfHPIFqdqVupHC DsndtIRt2hqX6wfIQjNv8vNSZLS8gUYzqK7W2LdZMpOYD1STVaA1_bvQjPcZYzbd7vntiS9dV2u2 ZQu_kPcQmW5XwkIP3.wZK1rx1l5xM7.Dr9mlsNBYBQAYZCFzattCP2t0bHzeYR9mTNa3KLPhgPvs OFqw8Xtzkgj7iVjI1nFe11_cWWBl7mmdm0Zqs9dXS1 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Sun, 10 Apr 2022 00:48:56 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-5w6fp (VZM Hermes SMTP Server) with ESMTPA ID 90d05835f4df92c1af84c62942c34d06; Sun, 10 Apr 2022 00:48:53 +0000 (UTC) In-Reply-To: <83ilri8iag.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Apr 2022 17:04:23 +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.186.206; envelope-from=luangruo@yahoo.com; helo=sonic310-25.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=unavailable 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:288074 Archived-At: Eli Zaretskii writes: >> From: Po Lu >> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org >> Date: Sat, 09 Apr 2022 19:44:57 +0800 >>=20 >> Eli Zaretskii writes: >>=20 >> > No, only for events that are specific to the device and not available >> > in other devices. >>=20 >> But the point is that they aren't specific to the device. The device >> will in the general case behave like any other device (a touchpad will >> scroll just like a mouse, and an eraser will move the pointer like any >> other stylus), but inside specific use cases, such as precision >> scrolling and artist-mode, they will have to behave differently. > > If the events are to be interpreted as usual in some situations and > differently in others, we could have a special mode or variable to > change the produced events only when we want that to be. > > Alternatively, we could always produce special kinds of events, and > have them mapped to the same commands as the "normal" events. For > example, touchpad-button-1 could be mapped to the same command as > mouse-1 in most cases, but when we want to treat those touchpad events > specially, we could rebind them to other commands. Similar to how we > usually make shifted keys to invoke the same commands as unshifted > keys, unless there's actually a binding for the shifted key. What if the buttons we want to change are not part of a specific kind of device? We would then still have to expose the name of the device via the events, like such: "Logitec USB Optical Mouse (2)-mouse-1" "Logitec USB Optical Mouse-mouse-1" These are events from two different mice, that are otherwise identical. > That's exactly what I was afraid of: that commands will need to care > about devices. Next we will have N devices for X Windows, M different > devices for NS, Y devices for MS-Windows (some of them similar to X, > others similar to NS), etc. -- and commands will have to dispatch on > all those devices, right? Not exactly. Only commands that operate on devices by name (in which case the user will be setting the name, see my reply to Lars), or on devices that aren't explictly supported in `device-class' will have to care about the window-system specific device name. > What does it matter who personally will write the code -- it will need > to be written, and sooner or later will find its way into the core. > "Please accept this patch that adds the device I have here and would > like to be able to use with Emacs, but it is not yet in the list of > devices Emacs supports." Sounds familiar? > Yes, and then someone develops another compositor and provides names > that are identical to Wayland for different devices, or different > names for the same devices. Each team of toolkit developers might be > consistent with itself, but why should we believe they are consistent > with each other? On GNU/Linux systems the names are nearly always consistent with each other. On other window systems, that's why functions like `device-class' exist: the porting process will deal with the identification of devices. >> (cond ((eq draw-how 'artist-do-continously) >> - (artist-mouse-draw-continously ev)) >> + (artist-mouse-draw-continously ev >> + (when (eq (device-class= last-event-frame >> + = last-event-device) >> + 'eraser) >> + 'erase-char))) > > Do you really believe this is how Emacs's application code should be > written? We don't distinguish between different devices in file I/O, > although different filesystem definitely support different features. > Instead, where abstractions could be devised that could express > different underlying implementations, we have such abstractions in > Emacs. Example: file-extended-attributes, which allow us to > transparently support several variants of Posix-style and NTFS-style > ACLs. And where no such abstractions can be made or make sense, we > have specific features supported only by some filesystems, while > others just error out or return trivial values. But we never-ever ask > the filesystem what is its type and use that to change application > code. > > Why should input event be any different? File systems are not the best anology. We have many places where we look to see if a frame is capable of various features: displaying grayscale, colors, true color, variable-width fonts, etc. That would IMHO be a closer example. (I think shr checks `display-graphic-p' before trying to insert images, for example.) `device-class' also fits an area rather close to `file-extended-attributes', I think. > I don't need the name, I only need its number. The number is the same, the only part that is different is the name. We could make the C code number them differently, but it will need to identify that device, and that identification must be provided by the user through Lisp. > Yes, and where we produce the lispy keystroke event, we can convert > that to "=D1=8F", given the low-level information about the keyboard which > emitted the key. This way, no Lisp will need to know anything about > the device. The user will at least have to make the device which produced the lispy event known to Emacs, using the language in which customizations are written, which happens to be Lisp. Thanks.