From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 17 16:45:06 2021 Received: (at submit) by debbugs.gnu.org; 17 Oct 2021 20:45:06 +0000 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 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 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 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 Date: Sun, 17 Oct 2021 20:44:40 +0000 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== To: "bug-gnu-emacs@gnu.org" From: John Cummings Subject: 28.0.60; Meta keys broken when viper is active Message-ID: <29G5yqRp1kUTv4CVh4sUgsUrbkl3D-i2cVAuswXYDFmmmrUhf6_Q8m10xW2NmL7RC6NY-wUcEo2_ZHzFDO9I07VdUiPCBpNfT6Iunw1vuw8=@rootabega.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch 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-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: John Cummings Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 19 19:13:47 2021 Received: (at 51253) by debbugs.gnu.org; 19 Oct 2021 23:13:47 +0000 Received: from localhost ([127.0.0.1]:52224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcyIk-0007YZ-Op for submit@debbugs.gnu.org; Tue, 19 Oct 2021 19:13:46 -0400 Received: from mail-pj1-f52.google.com ([209.85.216.52]:47001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcyIj-0007YL-Kb for 51253@debbugs.gnu.org; Tue, 19 Oct 2021 19:13:46 -0400 Received: by mail-pj1-f52.google.com with SMTP id pi19-20020a17090b1e5300b0019fdd3557d3so1066174pjb.5 for <51253@debbugs.gnu.org>; Tue, 19 Oct 2021 16:13:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=lOZ10isuOYMTFm51LT8GnJo3kUfjPtAv5+9Frjt96mc=; b=pPhoTik2S0LtZUvrxX3OPk1oIX7F09eKWyIKUrL0DSNoGk1kcWv1FkCeCVKIlV0GhS cFp/5pdDzFq9NH/MZ1IeveJJ46GRG5bcuG68tHeUZHu1RrbUUN+vnDxCvILIGytUBb1A ftmGOr/SGQdmxnp3KBFP2lor8FpN20kSm22ewn3efNp/mKLycdfiAnif+RGkLyZzufZP YMh5xVnJAxiHHALqySkOv6MV698+sNDgOyKYWR0cCtVwC37oZshQXxMwZYDoNhUCQqJt Yzto26JDDOnx0BoQACp621KmCOomSAIWEbz1GBX0qjXVL9fRD3vDp/MsvQqbs3JbJXD+ Vt6Q== X-Gm-Message-State: AOAM531pdKxpnxk7XlBazPtn2VGibSzYnMUwQjVsYJBgapBnbKGFK4Jh 2wUmJcDdm9FXKCn8O0o0hUpd+CVA3f1FqkPXOZs= X-Google-Smtp-Source: ABdhPJw8NewOacxt1Z9Tulj8y8aPwtEncIzKviC4XG5Ui1YtNegp7rovbHgac4L5fCwxL0dliwzOre5gRSL2IhMCEWE= X-Received: by 2002:a17:90b:17d2:: with SMTP id me18mr3184119pjb.132.1634685219714; Tue, 19 Oct 2021 16:13:39 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Oct 2021 16:13:39 -0700 From: Stefan Kangas In-Reply-To: <29G5yqRp1kUTv4CVh4sUgsUrbkl3D-i2cVAuswXYDFmmmrUhf6_Q8m10xW2NmL7RC6NY-wUcEo2_ZHzFDO9I07VdUiPCBpNfT6Iunw1vuw8=@rootabega.net> (John Cummings's message of "Sun, 17 Oct 2021 20:44:40 +0000") References: <29G5yqRp1kUTv4CVh4sUgsUrbkl3D-i2cVAuswXYDFmmmrUhf6_Q8m10xW2NmL7RC6NY-wUcEo2_ZHzFDO9I07VdUiPCBpNfT6Iunw1vuw8=@rootabega.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Date: Tue, 19 Oct 2021 16:13:39 -0700 Message-ID: Subject: Re: bug#51253: 28.0.60; Meta keys broken when viper is active To: John Cummings Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 51253 Cc: Lars Ingebrigtsen , 51253@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) John Cummings writes: > Keys like M-x, M-:, etc., are broken in viper > vi/insert state since bug > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18182 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. Maybe that commit should just be reverted? From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 19 19:32:24 2021 Received: (at 51253) by debbugs.gnu.org; 19 Oct 2021 23:32:24 +0000 Received: from localhost ([127.0.0.1]:52264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcyam-0001ho-Bk for submit@debbugs.gnu.org; Tue, 19 Oct 2021 19:32:24 -0400 Received: from mail-4317.proton.ch ([185.70.43.17]:38688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcyai-0001ZI-Jf for 51253@debbugs.gnu.org; Tue, 19 Oct 2021 19:32:22 -0400 Date: Tue, 19 Oct 2021 23:32:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rootabega.net; s=protonmail; t=1634686332; bh=SXuXRm+o2ybpntROfMsZE0MPOuw1SevHSHF7ngtPna0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=TM/b1/41rLBs3F5dChQprEida4S4RP2rfOwIi6Xx7+treYrlWZInB0U7l7948d2Oj NuaBvRu8RU1j1AQ5/1A8zAG8XBDNTyFFWcRV/vlB5uHLnfAY9/TT6qPXEFLlRTHRAY mrbYSFJ3b0ZicUb+zQhznoAw4qOPiarwD+FPGDImGLK2PSl8CQYJPUjAbGj9Fvivr7 usyt8AymZ6PUcqlAseE0MGAq/eC1oSqtZI4+4BJfKUQp26ZSFS+30GkECe/WFBFcsO bxyzyxIzG1tAf5ElBm4CN/wDZp4f5t7rvWZuKUbBH1yX3NoFFANlxiv2cZ4rcXelwh rMQZC+IcJebJg== To: Stefan Kangas From: John Cummings Subject: bug#51253: 28.0.60; Meta keys broken when viper is active Message-ID: In-Reply-To: References: <29G5yqRp1kUTv4CVh4sUgsUrbkl3D-i2cVAuswXYDFmmmrUhf6_Q8m10xW2NmL7RC6NY-wUcEo2_ZHzFDO9I07VdUiPCBpNfT6Iunw1vuw8=@rootabega.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 51253 Cc: Lars Ingebrigtsen , 51253@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: John Cummings Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Kangas wrote: > John Cummings john@rootabega.net writes: > > > 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. > > Maybe that commit should just be reverted? I've looked into this some more, and I think reverting it is the way that the entirety of the viper ESC-handling stack was designed to function. At least on terminals. i.e., viper--tty-escape-filter is meant to translate a solitary ESC into [escape], which viper-intercept-ESC-key is meant to handle. And on graphical terminals, we have the prefix vs. direct binding conflict that seems to (in my limited but growing understanding) completely rule out binding any commands to ESC. But if this does get reverted, and it turns out that allowing ESC to exit vi insert is still important, it doesn't seem like it would be too difficult to ignore direct ESC command bindings when looking up meta prefix bindings here: https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keymap.c?id=3Df3aa6480= 93a70c8ed15e764863a16fdf7126cdc4#n343 I've been playing with it to help me get more familiar with it; maybe I'll have a proof of concept one day. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 20 04:09:00 2021 Received: (at 51253) by debbugs.gnu.org; 20 Oct 2021 08:09:00 +0000 Received: from localhost ([127.0.0.1]:52615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1md6ei-0004nj-21 for submit@debbugs.gnu.org; Wed, 20 Oct 2021 04:09:00 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1md6ef-0004nT-Rm for 51253@debbugs.gnu.org; Wed, 20 Oct 2021 04:08:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GqqGJuF/TarUGoPMEt+lc3U0WxymYTWFVx8+A/UyRPg=; b=p1ZyNMazhhrL7oEVGOXiE/eovy Q3vrAVgUbawg2p/f8DlpO9e98Hk8HGd6VEvjusCl8RTW3X2eMSlXH9dqmnU53Rcgk1c2QOl3W6EyZ YZW+DbL1gzqtGelcq6ZyEnupajHO+vbye+xfjz1vuZ7FcyASkIryZO0/ZbOVljXGCsl0=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1md6eX-0005nl-RZ; Wed, 20 Oct 2021 10:08:52 +0200 From: Lars Ingebrigtsen To: John Cummings Subject: Re: bug#51253: 28.0.60; Meta keys broken when viper is active References: <29G5yqRp1kUTv4CVh4sUgsUrbkl3D-i2cVAuswXYDFmmmrUhf6_Q8m10xW2NmL7RC6NY-wUcEo2_ZHzFDO9I07VdUiPCBpNfT6Iunw1vuw8=@rootabega.net> X-Now-Playing: The Soft Pink Truth's _Am I Free To Go?_: "Multinationella =?utf-8?Q?M=C3=B6rdare_=28Totalit=C3=A4r?= cover)" Date: Wed, 20 Oct 2021 10:08:48 +0200 In-Reply-To: (John Cummings's message of "Tue, 19 Oct 2021 23:32:09 +0000") Message-ID: <878ryop17z.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: John Cummings writes: >> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18182 was fixed in >> > 5d522b430bd5ecfb8f082906cd634883dbb68f3e. This changed viper-ESC-key >> > from to ESC, which resulted in a direct ke [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51253 Cc: 51253@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) John Cummings writes: >> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18182 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. >> >> Maybe that commit should just be reverted? > > I've looked into this some more, and I think reverting it is the > way that the entirety of the viper ESC-handling stack was designed > to function. I've now reverted it in emacs-28, and I'm reopening bug#18182. > But if this does get reverted, and it turns out that allowing ESC to > exit vi insert is still important, it doesn't seem like it would be > too difficult to ignore direct ESC command bindings when looking up > meta prefix bindings here: > https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keymap.c?id=f3aa648093a70c8ed15e764863a16fdf7126cdc4#n343 > I've been playing with it to help me get more familiar with it; maybe > I'll have a proof of concept one day. It would be nice to have it working, so if you can come up with a solution, that'd be great. (Post the solution to 18182, please. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 20 04:09:12 2021 Received: (at control) by debbugs.gnu.org; 20 Oct 2021 08:09:12 +0000 Received: from localhost ([127.0.0.1]:52619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1md6eu-0004oj-Ao for submit@debbugs.gnu.org; Wed, 20 Oct 2021 04:09:12 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44470) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1md6et-0004oT-4m for control@debbugs.gnu.org; Wed, 20 Oct 2021 04:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=m6LChGskhTRxJNY1Y/fF6aIL9uA5dADhd0AvGExEIc4=; b=bEWrV03mP0hFXf4+oRyeHXzxiV DAor+goLTG6wIS4N3u2/bH/5klV1L0MSllJFh+wLePkCWWlTURAuvn5vXYwAjaGhqaDlYbWMNc1P0 HOSysQaUHD8sqAOXqUdAYmrTxezh7ubycvR2CI7JJlA4fqemIGfa5w8EWF3glt8XhFxM=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1md6el-0005o1-Jp for control@debbugs.gnu.org; Wed, 20 Oct 2021 10:09:05 +0200 Date: Wed, 20 Oct 2021 10:09:03 +0200 Message-Id: <877de8p17k.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #51253 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 51253 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 51253 28.1 quit From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 20 04:25:05 2021 Received: (at 51253) by debbugs.gnu.org; 20 Oct 2021 08:25:05 +0000 Received: from localhost ([127.0.0.1]:52641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1md6uH-0007N0-EJ for submit@debbugs.gnu.org; Wed, 20 Oct 2021 04:25:05 -0400 Received: from mail-4018.proton.ch ([185.70.40.18]:25874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1md6uE-0007MP-DA for 51253@debbugs.gnu.org; Wed, 20 Oct 2021 04:25:03 -0400 Date: Wed, 20 Oct 2021 08:24:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rootabega.net; s=protonmail; t=1634718295; bh=n6FSfjyhkXhUkDxBV79TJ8NwokU9ggNtKkFzV1yiVlU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=DOcpt8vreLF2khWcNVeWc+UugSTJXWZLNhdD80Ljbajgat5ugj3DXnbUDWGvaWSYO AsyIEavRPaowoTtb9Auqm1Uvm9DGcG+crFMF6ZNd3S08tTgzV5VhsnAP6zFZA6/nGF DkkWHZxu5NhRkEexBrG45Hniv/3XDboz/Q04SqMczn7dpSjZ6zHkt+yw4qV5qprzwo PhPWJYMN9JQkxg6G9qHvCbQ0Dl3CclVnPybvM5Jt0GLUSV9W+TObS7kOru4GCwAev1 Zz50u7YyTd2u+B6a1L3xGkl3+0o9XGvjWvBJwYxdx7ccWP3IwyERDH4kSsqWfk1yWC EXkrlM+9FPQkA== To: Lars Ingebrigtsen From: John Cummings Subject: bug#51253: 28.0.60; Meta keys broken when viper is active Message-ID: <5enybkUDBpPl8wYH_YZAVjLUeDAyHzlXeCBuC2AeUnLt5E65YIwLvM6XHTY2XWVvaWvmiizx2lwIakNf26CgqwfK1IltK9pffP85tUhzmLU=@rootabega.net> In-Reply-To: <878ryop17z.fsf@gnus.org> References: <29G5yqRp1kUTv4CVh4sUgsUrbkl3D-i2cVAuswXYDFmmmrUhf6_Q8m10xW2NmL7RC6NY-wUcEo2_ZHzFDO9I07VdUiPCBpNfT6Iunw1vuw8=@rootabega.net> <878ryop17z.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 51253 Cc: 51253@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: John Cummings Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen wrote: > John Cummings john@rootabega.net writes: > > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18182 was fixed in > > > > 5d522b430bd5ecfb8f082906cd634883dbb68f3e. This changed viper-ESC-ke= y > > > > from to ESC, which resulted in a direct key binding of (27 > > > > . 'viper-intercept-ESC-key) while in the viper vi/insert states. > > > > > > Maybe that commit should just be reverted? > > > > I've looked into this some more, and I think reverting it is the > > way that the entirety of the viper ESC-handling stack was designed > > to function. > > I've now reverted it in emacs-28, and I'm reopening bug#18182. Thanks, it's working again on my end! By the way, it had broken both terminal and gui Emacs, just in different ways (re: the commit message). I'll see what more I can do about the keymap logic. From unknown Sat Jun 21 03:29:38 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 17 Nov 2021 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator