From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Cummings Newsgroups: gmane.emacs.bugs Subject: bug#51253: 28.0.60; Meta keys broken when viper is active Date: Sun, 17 Oct 2021 20:44:40 +0000 Message-ID: <29G5yqRp1kUTv4CVh4sUgsUrbkl3D-i2cVAuswXYDFmmmrUhf6_Q8m10xW2NmL7RC6NY-wUcEo2_ZHzFDO9I07VdUiPCBpNfT6Iunw1vuw8=@rootabega.net> Reply-To: John Cummings 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="20811"; mail-complaints-to="usenet@ciao.gmane.io" To: 51253@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 17 22:46:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mcD2s-0005AC-B3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 22:46:14 +0200 Original-Received: from localhost ([::1]:35818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mcD2q-0001yz-3l for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 16:46:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcD2h-0001xW-Br for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 16:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33790) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mcD2g-0008IR-Ub for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 16:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mcD2g-0005tE-Lr for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 16:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: John Cummings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Oct 2021 20:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 51253 X-GNU-PR-Package: emacs X-Debbugs-Original-To: "bug-gnu-emacs@gnu.org" Original-Received: via spool by submit@debbugs.gnu.org id=B.163450350622554 (code B ref -1); Sun, 17 Oct 2021 20:46:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 17 Oct 2021 20:45:06 +0000 Original-Received: from localhost ([127.0.0.1]:45336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcD1m-0005rf-3K for submit@debbugs.gnu.org; Sun, 17 Oct 2021 16:45:06 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:39084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcD1j-0005rX-5f for submit@debbugs.gnu.org; Sun, 17 Oct 2021 16:45:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40730) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcD1i-0001lj-93 for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 16:45:02 -0400 Original-Received: from mail-0301.mail-europe.com ([188.165.51.139]:36020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcD1e-0007F4-J6 for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 16:45:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rootabega.net; s=protonmail; t=1634503484; bh=mgx+Tgl3Oxtehxn9X71glsHM38kN85OzYs9lqSuKYJ4=; h=Date:To:From:Reply-To:Subject:From; b=fbl8pjzngTKaS1cYZhJtWFUjrLnL/owDAx+EJINuBcffLdDzW67eJTlrslABUYbB0 DGnEt0DGL0D6v8VOBw7GYlbgtT6gmSoE3JLtglexkua8n8VwcROzQrjcEVdfBH3Zxz 6qudTLRbkPpa9O5HNndWik4pZsmxgp9kmWOt7fA1mDWyxoeFo+sCyWEADvDFD8CvC0 l5bWtbGSHQwQroUwdbsXtGaSgx1FRUfk4R7yQflQo1EHGZqNo4M5hvCrcTtNaImdz6 +zVbXMS99u6dp7OAToCpsVuPbX6iFrEZHw2RL/H/nTswDyQx+Nns3uiXvioOM9nQyO JhQAlMWfMxVrg== Received-SPF: pass client-ip=188.165.51.139; envelope-from=john@rootabega.net; helo=mail-0301.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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:217436 Archived-At: This is a break introduced in 2020 after the 27.2 release. emacs -Q recipe: (setq viper-inhibit-startup-message 't) (setq viper-expert-level '5) (setq viper-mode t) (require 'viper) ;only if/when testing this variant ;default is t ;(setq viper-no-multiple-ESC nil); In vi state or vi insert state, press M-x, M-s, M-:, etc. In terminal sessions, it will be like you pressed ESC and x separately and slowly. In graphical sessions, you will see a message like "M-x is undefined". SUMMARY This is is the latest wrinkle in a series of changes and bugs related to viper. Let me know if you want me to update a previous bug report instead of having this new one. I also have not included the report-bug diag info for the Emacs versions and builds I tested with, since this is pretty clearly fundamental to Emacs key handling and viper functionality. More detail is below, but I'll try to summarize it very briefly first: Keys like M-x, M-:, etc., are broken in viper vi/insert state since bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18182 was fixed in 5d522b430bd5ecfb8f082906cd634883dbb68f3e. This changed viper-ESC-key from to ESC, which resulted in a direct key binding of (27 . 'viper-intercept-ESC-key) while in the viper vi/insert states. In a terminal, the ESC and x events encoding M-x are processed like two separate key sequences. This is because that direct ESC binding makes viper-intercept-ESC-key consume the ESC event greedily, and then the x is processed after that. On a graphical display, the direct ESC binding prevents Emacs from finding ESC prefix mappings that provide bindings for M- sequences when it gets events like #x8000078 for M-x. Since the latest change that causes this behavior was meant to make ESC, aka ^[, work to exit vi insert state on graphical displays (as Eli pointed out, it already worked on terminals at the time), would an acceptable compromise in the short term be to let ^[ remain broken for this purpose so that M- keys may work? In that bug, the reporter was OK with the workaround Stefan suggested: (define-key input-decode-map [?\e] [escape]) Maybe that could also be added to all graphical sessions? HISTORY Rough timeline of changes that contribute to this viper behavior: f5e1b6804dc2307983e4c55d4d6530549ddccbb7 Emacs ~24, Feb 2013 This is the starting point, where everything seemed to work in harmony. git: 99d0d6dc23f0fd2ee6d64f0f18a33f2b791c642d bzr?: 11521f1228e447bb68ff7a48a30148b99323c04e Emacs ~24, Feb 2013 Changes were made to keymap handling functions in C. Prior to this change, Even if there was direct ESC keybinding, Emacs could still properly find the ESC prefix mappings that define M- bindings. i.e., you could map a command to ESC and use M- keys at the same time. After this commit, the direct ESC binding meant that M- keys would be undefined in graphical Emacs. So graphical Emacs could not use M-x in viper vi/insert state, instead seeing 'M-x is undefined'. Terminal emacs still worked OK, since that ESC binding was the viper ESC key handler, and it could correctly identify ESC-as-meta event sequences from their timing. A recipe to see this specific change in behavior in graphical sessions: (local-set-key [27] (lambda () (interactive) (insert " command "))) Prior to this change, you could run this and still be able to run M-x. After this change, you will get "M-x is undefined" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D13793 24.3.50; M-x broken in viper and X Feb 2013 Frank Fischer noticed this problem and reported it, and provided some analysis that helped me confirm the change to the keymap behavior I mentioned in the previous paragraph. The fix for this bug was the next change: f1e6674bb32058c7ef683d5f8f8ac67f99e96dd2 Emacs ~24, Jul 2013 The key element of this change was to change viper-ESC-key from ESC to . Since the (27 . 'intercept-viper-ESC-key) mapping changed to (escape . 'intercept-viper-ESC-key), Graphical Emacs was no longer blocked from finding the ESC prefix mappings for M- keys. But this is where ^[ stopped working to exit vi insert state in graphical Emacs. Since viper--tty-ESC-filter doesn't run in graphical sessions, and the viper mappings were now on , ^[ was just treated as a pending ESC- prefix. In termainal sessions, viper--tty-ESC-filter translates the ^[ to an after the timeout, and viper handles it as designed. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18182 reported (to be fixed later) 24.3.92; C-[ does not work as ESC in viper-mode iquiw noticed this break and reported it Emacs 27.2 This release behaves the same as the previous Emacs version in this timeline. 5d522b430bd5ecfb8f082906cd634883dbb68f3e Emacs 28.0.50 Fixes bug#18182 by reverting a part of f1e6674bb32058c7ef683d5f8f8ac67f99e96dd2: viper-ESC-key gets set back to ESC, which puts the direct ESC mapping for viper-intercept-ESC-key back in the viper minor maps. This is where the current broken behavior comes from with keys like M-x. This is the first time we see this bug in terminal sessions (AFAIK). (I believe this is because the changes in f1e6674 changed the points at which manual ESC events were distinguished from ESC-as-meta events, from the original "envelop-style" to the newer style.) In the terminal, ESC is processed immediately by viper-intercept-ESC-key, which either exits insert state or does nothing if not in insert state, and then the x event is processed. (There is one exception: when viper-no-multiple-ESC is nil and you are in vi state, the viper-ESC function does successfully interpret ESC x in Emacs-style as an M-x. This appears to be the only case when that happens.) In graphical sessions, the direct ESC binding means M-x is undefined like it was in 99d0d6dc23f0fd2ee6d64f0f18a33f2b791c642d ANALYSIS It seems like the behavior in v24/git f1e6674 and Emacs 27.2 was the most stable in recent history. As suggested earlier, since the only viper bug (that I know of) was that ^[ wouldn't exit insert state in graphical sessions, would tolerating that bug be an acceptable worst-case scenario for now, as opposed to all M- keys being broken in viper terminal/graphical? And if you do want to fix that behavior, would it be as simple as the workaround Stefan offered: (define-key input-decode-map [?\e] [escape]) for all graphical sessions? It doesn't seem like there are many other options, since having a binding for ^[ will break M- keys. But on that note, as Frank Fischer wondered, wouldn't fixing that original 2013 change to the keymap C code be the best fix? Since ESC keybindings conflict with M- keybindings in the keymap formats, it seems right that graphical Emacs would have had a way to process them separately. Was that behavior deliberately removed, or could it return some day? I'll note that, in the timeline I looked at here, it's only graphical Emacs that ever had the inherent ability to resolve M- bindings even when there were direct ESC bindings. Terminal Emacs would always invoke whatever the ESC binding was, which is why the viper interceptors had to do the timeout checks. I doubt that would change.