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

[Gregory Heytings]

> 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
Description: Text Data