From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#48042: 26.3; Macros don't work with french-postfix input method Date: Fri, 14 May 2021 17:04:59 +0300 Message-ID: <83y2chxvg4.fsf@gnu.org> References: <86pmyghqf1.fsf@upmc.fr> <425cd7715bc9fae8b39a@heytings.org> <831ra9zi4x.fsf@gnu.org> <425cd7715bda5353110e@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15025"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, harven@free.fr, 48042@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 14 16:06:13 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 1lhYSC-0003jq-39 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 May 2021 16:06:12 +0200 Original-Received: from localhost ([::1]:51534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhYSB-0008AH-5z for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 May 2021 10:06:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49970) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhYS3-00087k-5e for bug-gnu-emacs@gnu.org; Fri, 14 May 2021 10:06:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35191) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lhYS2-0006KO-Tp for bug-gnu-emacs@gnu.org; Fri, 14 May 2021 10:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lhYS2-0007Y9-PB for bug-gnu-emacs@gnu.org; Fri, 14 May 2021 10:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 May 2021 14:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48042 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 48042-submit@debbugs.gnu.org id=B48042.162100111628933 (code B ref 48042); Fri, 14 May 2021 14:06:02 +0000 Original-Received: (at 48042) by debbugs.gnu.org; 14 May 2021 14:05:16 +0000 Original-Received: from localhost ([127.0.0.1]:46733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lhYRI-0007WZ-3q for submit@debbugs.gnu.org; Fri, 14 May 2021 10:05:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lhYRE-0007WG-HN for 48042@debbugs.gnu.org; Fri, 14 May 2021 10:05:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50946) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhYR8-0005hW-QP; Fri, 14 May 2021 10:05:06 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4144 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhYR7-0005qA-By; Fri, 14 May 2021 10:05:06 -0400 In-Reply-To: <425cd7715bda5353110e@heytings.org> (message from Gregory Heytings on Fri, 14 May 2021 13:38:03 +0000) 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:206521 Archived-At: > Date: Fri, 14 May 2021 13:38:03 +0000 > From: Gregory Heytings > cc: Stefan Monnier , harven@free.fr, > 48042@debbugs.gnu.org > > > Bother: AFAIK, current-input-method non-nil means the user activated an > > input method, it doesn't mean we are in the middle of typing a key > > sequence that will yield a character via the input method. That is, a > > user could activate an input method, but still keep typing just ASCII > > characters. So why is this condition correct here to avoid recording > > input more than once? > > I'm not sure I understand your question. With an input method is > activated and characters that are not "reprocessed" by the input method > are typed, they are not added to the unread-command-events list, so this > part of the code (which is entered with the goto reread_for_input_method > above) is simply not executed. If you search the Lisp files for unread-command-events, you will see how many features unrelated to input methods do add stuff to unread-command-events. What if an input method were active while one of those unrelated features does that? > Until commit 30a6b1f814, that part of the code (if (!recorded)...) did not > exist, and my patch simply restores the behavior that quail.el expects by > skipping it. That part didn't exist because once upon a time we recorded everything immediately as it happened. When that changed (for a good reason, as described in the discussion cited by the commit log message), we needed to keep track of what was and what wasn't recorded. So restoring the behavior back to what it was then doesn't help me to gain confidence in the correctness of the patch, sorry. Going back to what we had there is certainly not something we should do. > Note that in 2015 you yourself described that commit as a "naïve > attempt at fixing" the problem. Every change in keyboard.c is "naïve" nowadays, since no one among us really understands all of its intricacies. Of course, if you do have a clear understanding of what's going on there, it'd be splendid, but I hope you will then be able to convince in the correctness of what you propose. > I attach an even better patch, which removes the condition that a keyboard > macro is being defined. Now the keys displayed in C-h l are also correct. Hmm... but the from_macro label seems to indicate that this code runs for macros as well, even when input method is not active? > > This is why I tried to have a variable that quail.el binds while > > actually processing keys. I'd appreciate some explanation for why that > > didn't work 100% in the case in point (it still avoided recording twice > > some of the keys, so it isn't entirely wrong). > > I don't claim to understand everything, but what I see is that > unread-command-events is also used (set) in quail-update-translation, > quail-next-translation, quail-prev-translation, > quail-next-translation-block, quail-prev-translation-block and > quail-minibuffer-message. So you are saying we should bind the variable there as well? If that works, I'd be much happier, since in that case we will be sure we only bypass recording exactly where that's needed. However, ISTR that at the time I tried adding the binding at least in some of those places, and it didn't work well, or maybe didn't have any effect. I think I then convinced myself that only the first event needs this protection (but I might be misremembering). So it would be good to have a clear understanding why this particular use case evades the current protection against duplicate recording. Thanks.