GNU bug report logs - #48042
26.3; Macros don't work with french-postfix input method

Previous Next

Package: emacs;

Reported by: harven <at> free.fr

Date: Mon, 26 Apr 2021 18:07:02 UTC

Severity: normal

Tags: confirmed

Found in versions 28.0.50, 26.3

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #30 received at 48042 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, harven <at> free.fr,
 48042 <at> debbugs.gnu.org
Subject: Re: bug#48042: 26.3; Macros don't work with french-postfix input
 method
Date: Fri, 14 May 2021 13:38:03 +0000
[Message part 1 (text/plain, inline)]
>
> 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.  When they are "reprocessed", they are 
added to unread-command-events, but the keys typed in by the user have 
already been recorded.

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.  Note that in 2015 you yourself described that commit as a 
"naïve attempt at fixing" the problem.

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.

>
> 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.
[Fix-key-recording-bug-when-an-input-method-is-activa.patch (text/x-diff, attachment)]

This bug report was last modified 4 years and 51 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.