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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 48042 <at> debbugs.gnu.org, harven <at> free.fr
Subject: Re: bug#48042: 26.3;
 Macros don't work with french-postfix input method
Date: Fri, 14 May 2021 14:09:34 +0300

> Date: Fri, 14 May 2021 09:29:08 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: 48042 <at> debbugs.gnu.org
> 
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -3098,7 +3098,11 @@ read_char (int commandflag, Lisp_Object map,
>    /* When we consume events from the various unread-*-events lists, we
>       bypass the code that records input, so record these events now if
>       they were not recorded already.  */
> -  if (!recorded)
> +  if (!recorded &&
> +      /* However, don't record events when a keyboard macro is being
> +         defined and an input method is activated (Bug#48042).  */
> +      ! (! NILP (KVAR (current_kboard, defining_kbd_macro)) &&
> +         ! NILP (Fsymbol_value (Qcurrent_input_method))))

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?

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).

Stefan, any comments?

Also, please avoid quoting a bug number in comments as a replacement
for explaining the code, unless the explanation would need a very long
and convoluted text.  We should strive to make our comments
self-explanatory.  (That some code was added/modified to fix a certain
bug is very easy to find out using "git log -L" and similar commands,
so a bug number is almost always redundant in comments.)

Thanks.

Previous Next

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