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: Fri, 08 Apr 2022 15:36:05 +0800 Message-ID: <87tub4uivu.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19698"; 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 Fri Apr 08 09:37:57 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 1ncjBt-0004uz-DS for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 09:37:57 +0200 Original-Received: from localhost ([::1]:35408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ncjBs-0008WG-0g for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 03:37:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncjAK-0007hs-9R for emacs-devel@gnu.org; Fri, 08 Apr 2022 03:36:20 -0400 Original-Received: from sonic309-22.consmr.mail.ne1.yahoo.com ([66.163.184.148]:34762) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ncjAH-00005k-Ga for emacs-devel@gnu.org; Fri, 08 Apr 2022 03:36:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649403372; bh=6dlrR4AYP7ba4V/ZteJA7S0NKODJBnA2QkQFzKUjLUw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=c9OIBYjVwLimOttOqC852f9sQJ3/O8zM8HV2+2BYuaEAKOLasbli/n5QEZSUC0OMq+ByJeflZjz+lNCos30HsP8ZtZ6H4h8SVfccdCdZ0sIZbDTHPdBXsn/vOxFmz0O+wXAqpQqAGwIQIMfsIwVlwyu6yaflvxplg6UJdaUMFpwWSuROVA3NARLvGQuaASSqD00VniT7tqFhE7agoDm1XibzeQwiwx8KxirWLU+oNUjYxy+jg9HmN2FvLciFVJDX5PB9cpbmdOEZ3OnEI82GSWy7Saktql8dpGQnPUJzvMb+hpvbnC87Pcnj7DUpt5VH9/jW8hrzvb9b7PmjKU/NDA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649403372; bh=T20j0CzFHzeIbf77HDxuFnYlDX0XVTVJOQPrgEoLGGg=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=l8D6l+ez5lipUZYvZpOsdqZnn5qDiRdrbrgH1uVxGuwE/wffI4fsgOeO8g9V+435hacKKVVnc5aYMnQIBp0sp6chgFynJrmTQlq1IUjT99fD6JmdGVJ14evnj0TuQb5Tqh+0wt54Dn0ZQNcltDpIA7T1KJn5xmC/tqyj/CrpUqZ3pVt411Kc0d7tZGcR+tIPAFkYBFtD24fdoN8mYDxxqGA6MNQO7sjUTLu/IoNVsIO8/b/S9TUVxbwA8pAoFe6GkeayrUZldi8by+Qx+92GbtdgrjHn2SDg3Xjp8RxlE4w56SnXC0/D01+ClbuUxK/C/f+UGmhpIbAj/30S3h8dqA== X-YMail-OSG: mA7HwtkVM1mTsWt44hVbBIS4JlXtmnmmg2Cm9zL.fOEmofsKAL5iNYQw3PpB7F0 13ZWa1sIRzcHaePRDqo3..XeTZ_M4JUfurzMZBZvWvpdQYzS0xuqiY8zcfu7N8Cmjqmh6o0Ivj4N 00Gi7xYKkhs8QRpkfW4mg.xa6IfZK4ye6dmj81vpUHcKX6cPl3bVKD5OSlXgJe0sJAq2E5N_9pjz CfOqum6ZmkI7bxaS7btI.K7hY4K5ggF6JYSVjuLRYGLpwArITB9JaknDIvg_Qzsi3U6BF2ocAl4C QxS_ovCf_b3VrjgC_8mRuSmE2.xtRahxNRygvyHybGKPs2YI_dfJZnW.iaCfCi1SBJAXctc2G9CF v.IIjQsWeK.dv45sfz2nHa6sob8RmllRjwBulaXxbmggecDH1riCDJ4KJq_JJVvpQqUBWbhKFbvh ghGH2lHP4lhLolIxmHSt2I5Mer177Ff78T8pNlw78UqHgMvq42QCP7qEajeygkBGGMwE6YX0UmX4 TZbJmwJg4pgVcumHaRI96ytX9V41UpPj.am6wS5OCHvG9G0F99uqHF6A9BQ7RDqZVJNo51ZDVODH b8Swc8sETopAM1AKjI_OZbG3aYgSYvktie5.zUYmu0PyfMlnmKwX08Vy3FfAf03rdgcjMkuhEVHa 0MdQNxrPSIRPceai.mOsEBTnEIqbfgAIXMEncpTlwugqyYCU8m7SMRvyQc68aI8Iis_qdruWOvxC TvdF_H8xDTPzMYw.fi69cv7BLSdJgm6EZR4tOhCMBDsU43danvdnP5xSqe6iDp9T4thpHBt3cEFx 8RhhSU.iDl3NNeWnq13PT.5q2ykluTfyT8mL0Y_ryh X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 07:36:12 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-p7hgv (VZM Hermes SMTP Server) with ESMTPA ID c2ecaff6502dc42d0fc35e432d64254a; Fri, 08 Apr 2022 07:36:10 +0000 (UTC) In-Reply-To: <83a6cway59.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Apr 2022 09:26:42 +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.184.148; envelope-from=luangruo@yahoo.com; helo=sonic309-22.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:287932 Archived-At: Eli Zaretskii writes: > I wouldn't have asked if the commit message explained this enough for > me to understand. I see no rationale in the commit message. Sorry, I will try to be more clear on that next time. > What for? Why do we care in Emacs which device generated a scroll > event? Emacs was always transparent regarding that, and did the same > regardless of the particular device which caused the event. Why do we > suddenly need to distinguish between them? This could add complexity > to Emacs's application level that we don't particularly want. So if > we do add this, it had better be a very good reason. Basically, precision scrolling comes in two forms: the first immediately scrolls the screen by the deltas given, while the second "animates" a scroll from the original position to the position with the deltas. All the major programs and toolkits today seem to be converging on using the first strategy for touchpad devices and tablets, and the second for mice. The ability to distinguish between different input devices is important to be able to implement that behavior according to what users expect. > Most input events nowadays come from the window-system, which > typically hides the device level from the application. For example, > there are programs that allow you to inject mouse events by typing on > the keyboard, and vice versa. There are also programs that inject > keyboard events programmatically. Etc. etc. Why would we want to > know or care exactly what device generated an event? That's not hidden under X Windows and GTK, where we see that many other applications are relying on that information as well. For example, Firefox-based browsers and WebKit both use it to determine which form of "precise scrolling" strategy to use. NS doesn't expose the device name, but it does expose the kind of device which generated the event. On macOS, GTK uses that information to compute an artificial device name, which works well enough. > The question is why it is useful for Emacs to know which keyboard > device generated a key sequence. I can imagine an input method behaving differently depending on which keyboard is being used, since individual keyboards can have different layouts convenient for typing in separate languages. > In any case, if we do agree to have this information in Emacs, the > definition of a "device" should be abstract enough to allow its > implementation on systems other than X. It has already been implemented on Wayland, and the implementation on NS is waiting for a machine on which it can be tested. (I don't have access to a real Mac, and GNUstep doesn't even try to implement what I talked about correctly, to it everything is a mouse.) > And then I will ask a question similar to that Stefan asked: why not > make the device part of event object we have on the event queue? It's already part of the `struct input_event', but compatibility requirements prevent it from being made part of the Lisp events itself, so we store it as one of the last-event-* variables instead.