From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Trey Peacock Newsgroups: gmane.emacs.devel Subject: Re: PGTK-related misconceptions Date: Wed, 20 Apr 2022 07:52:56 +0000 Message-ID: <87bkww9ooc.fsf@treypeacock.com> Reply-To: Trey Peacock Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="------87f788415f2fb9bfef6b77bdc3740a3934905b32f42c68fdefe408e5b6d12fce"; charset=utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21153"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Morgan Smith , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 20 09:54:08 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 1nh5A7-0005HC-58 for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Apr 2022 09:54:07 +0200 Original-Received: from localhost ([::1]:39454 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nh5A5-0008Nj-L5 for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Apr 2022 03:54:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57000) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nh59E-00071S-TK for emacs-devel@gnu.org; Wed, 20 Apr 2022 03:53:13 -0400 Original-Received: from mail-0201.mail-europe.com ([51.77.79.158]:37946) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nh59C-0007HA-4x for emacs-devel@gnu.org; Wed, 20 Apr 2022 03:53:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=treypeacock.com; s=protonmail2; t=1650441185; bh=3xluxdgPw1tc1SrM2ZqvlQlxUAXUPdueKJ7U7ZameBI=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:Feedback-ID:From:To: Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; b=nYxNcMB0ciusANNFVH0EDrEHflG7MXqJA8E1XPt315AeXlJBuZ6sls13YMh1coiVR CBedf8whT3JtONo4ZqNoqY/T0XhWHiKrdSi6TTQGdVevJ2aGlzdqwC1RjA/f3Onoaw g3DGfr1sxW9XAB5vm4q201jImUYDJgr12+w14bWo+yTZDRxpGculPt+9DTHiGg7zZj zbkDAmm59arvQ+QsqeKbuXWwQ3NdP7DKGwReqyBrHzAgpx3SbecCe+rNLCGV1/9vTD Ly9hA63bpcxvKakB5CdNcnY6azYs0kj+Ja3QL+hFlSgWtnV+h6UG589iSRQ/mXhb1G 2mckOjRVIT4+A== Feedback-ID: 17020329:user:proton Received-SPF: pass client-ip=51.77.79.158; envelope-from=gpg@treypeacock.com; helo=mail-0201.mail-europe.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, 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:288699 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------87f788415f2fb9bfef6b77bdc3740a3934905b32f42c68fdefe408e5b6d12fce Content-Type: multipart/mixed; boundary=8d99155776e3f757300944687912e303b0d4c50b5fd45e2a0f05a0e5ae43 From: Trey Peacock To: Po Lu Cc: Morgan Smith , emacs-devel@gnu.org Subject: Re: PGTK-related misconceptions In-Reply-To: <87mtggcscu.fsf@yahoo.com> Date: Wed, 20 Apr 2022 00:52:51 -0700 Message-ID: <87bkww9ooc.fsf@treypeacock.com> MIME-Version: 1.0 --8d99155776e3f757300944687912e303b0d4c50b5fd45e2a0f05a0e5ae43 Content-Transfer-Encoding: Content-Disposition: Content-Type: text/plain; charset=UTF-8 "Po Lu" writes: > Trey Peacock writes: > >>> See https://docs.gtk.org/gdk3/flags.ModifierType.html, which says: >>> >>> Since 2.10, GDK recognizes which of the Meta, Super or Hyper keys are >>> mapped to Mod2 - Mod5, and indicates this by setting GDK_SUPER_MASK, >>> GDK_HYPER_MASK or GDK_META_MASK in the state field of key events. >> >> The capability to do something is not the same as a requirement. > > It's the documented behavior of GDK, and Emacs holds GDK to its > documentation. Nowhere does the documentation say this is a > "capability", "recognizes" is in the third-person present tense, which > makes it a requirement. > >> I would be happy to help. Granted, this is only my second interaction on >> the mailing list, but I do want to contribute how I can. > > Great, one step forward would be to bring up the issue with either the > GTK or Wayland compositor developers. Since you've already talked with > the latter, and they say it's not their problem, please contact the > former. > >> It is not GDK that is responsible for this. Further, since this is not >> required, I don't think its proper to deem it a bug. > > It is, as specified in its documentation. > >> Your change seems to have removed a fallback in case there were no >> virtual modifiers and reverses the previous logic: > > As you can see by the name of the function, it was directly ported over > from X (the current version is in xterm.c), and is yet another example > of the PGTK port translating X Windows code to GDK verbatim, duplicating > what GDK is supposed to do itself. > > I will not change Emacs because the GTK developers, yet again, forgot to > follow their own documentation when implementing some feature. It just > makes Emacs code bloated, hard-to-follow and liable to break at the > slightest whim of the GTK developers, who then respond that we're not > using GTK "properly", because we try to work around their problems. You have already changed Emacs from accepting both MOD4 and SUPER_MASK as its Super key modifiers to only accepting SUPER_MASK. I imagine this response is born of more than just this issue but I would not let it cloud an easy solution. GTK 3.24.33 still accepts Mod2-5 masks, recognizes them separately from the virtual modifier masks, and unlike the x11 implementation does not contain the logic to set convert Super_L or Super_R to GDK_SUPER_MASK. So what you have done is actually held Emacs to GDK's x11 implementation and documentation rather than looking at the code itself. https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/wayland/gdkkeys-wayland.c#L249-316 https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/x11/gdkkeys-x11.c#L396-398 If the PGTK branch is meant for "alternative window systems available on GNU/Linux and some Unix systems, such as Wayland" then I do think there should be more consideration taken compositors that do not share Mutter's workaround. Had you been using any other compositor, surely you would not have made this change. Perhaps even filing a bug yourself. This will be my last comment on the matter as I don't think its productive for either of us to belabor our points. --8d99155776e3f757300944687912e303b0d4c50b5fd45e2a0f05a0e5ae43 Content-Transfer-Encoding: base64 Content-Disposition: attachment; name="publickey - gpg@treypeacock.com - da008078.asc"; filename="publickey - gpg@treypeacock.com - da008078.asc" Content-Type: application/pgp-keys; name="publickey - gpg@treypeacock.com - da008078.asc"; filename="publickey - gpg@treypeacock.com - da008078.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IEdvcGVuUEdQIDIu NC4xCkNvbW1lbnQ6IGh0dHBzOi8vZ29wZW5wZ3Aub3JnCgp4ak1FWVRVVCtSWUpLd1lCQkFIYVJ3 OEJBUWRBd2Q1cUwyVkRyREJ4R2RVUnp1T09xZGpraEZjbU9VUUhrdkxRClU5Q2EvZ1BOS1dkd1ow QjBjbVY1Y0dWaFkyOWpheTVqYjIwZ1BHZHdaMEIwY21WNWNHVmhZMjlqYXk1amIyMCsKd284RUVC WUtBQ0FGQW1FMVJhY0dDd2tIQ0FNQ0JCVUlDZ0lFRmdJQkFBSVpBUUliQXdJZUFRQWhDUkRJNUlj QgpKOVBEYlJZaEJOb0FnSGlxQzNRVW5OTDZoY2praHdFbjA4TnRtUndBL2o2ZWZFRzAvUmU5Z2ln UFVCWm5KZ0NCCm5DSU1JVzhGd2hDL04rMVQ1OVVZQVA0L0tMcGhWSVh3Zzh5TUpRYTM1aWZzendS TncvakpPQjRXcjFienlaMHEKQXM0ekJHRTFGQzRXQ1NzR0FRUUIya2NQQVFFSFFLVzE1Q093WWMw bE9zR2hCWE1IR3drcWNLRHoraHhCZ0ZiWgprSFAwQzVGMHdzQXZCQmdXQ2dBSkJRSmhOVVduQWhz Q0FKZ0pFTWpraHdFbjA4TnRkaUFFR1JZS0FBWUZBbUUxClJhY0FJUWtRMlNWQmhnZmRIYlFXSVFU LzVqZjRnYTR4N203MnBnblpKVUdHQjkwZHRIejRBUDltVEdUa09FWGEKYU4vZmR4ZTgrak5CZk11 R01hR3BoMzJteWRzT1NiS1pRZ0VBOElvSWlKc2ZTVWtmZDc3d0lKUVBGM1AxSTlOdAppZFluYWhO bXY5Qnlkd1FXSVFUYUFJQjRxZ3QwRkp6UytvWEk1SWNCSjlQRGJWNDhBUUNIaFVxbWVPRFBMcERj CjJKN0hxcHhINTRUZG9xclRobHdoN01jbnBSZWs4d0Q3QldhcjNqVEhCY2pIK0cyM0Vvc0VaVGQ5 RCtUWXcxVU4KbHlSaysxcVJTQXZPT0FSaE5SUlhFZ29yQmdFRUFaZFZBUVVCQVFkQTg2WUpoMHkz cW5LV2l0bW5Rc2hHYlhoRQppdmlmWEthbGpXK2dPM3BUUEhZREFRZ0h3bmdFR0JZSUFBa0ZBbUUx UmFjQ0d3d0FJUWtReU9TSEFTZlR3MjBXCklRVGFBSUI0cWd0MEZKelMrb1hJNUljQko5UERiWnJZ QVFDeHBTWUlkMkd3WFZzR1lMSFNiMXRnd1cyeUZoRVMKT2lvZXpDYkhmMmhvT1FFQTByMm1XUU1I RXlCaGl3TldUL3VTcFJZa0NJU1dNQzhuUFlDdlo3a3FUUVRPTXdSaApOUlJwRmdrckJnRUVBZHBI RHdFQkIwRHZLRmpFTkRGUy9YSENxVWR6aml6RnFleVVlWjJrLys5K3BQQXpGNnlWCklzSjRCQmdX Q2dBSkJRSmhOVVduQWhzTUFDRUpFTWpraHdFbjA4TnRGaUVFMmdDQWVLb0xkQlNjMHZxRnlPU0gK QVNmVHcyMk1xUUVBMXNEYVovUEVpOGNPUFBMMllWUE5HY2R6MkdyaUY1bEVFVVQ4cU1YNmpKd0Ev Um16VEJNbQpCNTRqcldEZTdjSzJFTEtQM3JtM2JGM0hQZUovMFFWbUxlRUMKPUZhYVEKLS0tLS1F TkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ== --8d99155776e3f757300944687912e303b0d4c50b5fd45e2a0f05a0e5ae43-- --------87f788415f2fb9bfef6b77bdc3740a3934905b32f42c68fdefe408e5b6d12fce Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wnUEARYIACcFAmJfu9YJkNklQYYH3R20FiEE/+Y3+IGuMe5u9qYJ2SVBhgfd HbQAAHwVAP9Zu/MHjkcoyY+XPPnJpv5Ika3Eu2lTbL1QnH+fWYGnBgEAv3sp XxGnsyC0ETJjElx+q89eyRjiBqt8VSt7AE9oMwk= =soaq -----END PGP SIGNATURE----- --------87f788415f2fb9bfef6b77bdc3740a3934905b32f42c68fdefe408e5b6d12fce--