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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, harven <at> free.fr, 48042 <at> debbugs.gnu.org
Subject: bug#48042: 26.3; Macros don't work with french-postfix input method
Date: Sat, 15 May 2021 18:47:00 +0000

[Message part 1 (text/plain, inline)]

I attach the updated patch.

Some comments below:

>
> To tell you the truth, I'm a bit worried that you inhibit recording 
> everywhere in quail.el, which seems to contradict my analysis from back 
> when I made the inhibit--record-char.  How many different input methods 
> did you try with macros and "C-h l" to make sure this change indeed 
> causes Emacs to record each produced character just once, and nothing is 
> either omitted or recorded more than once?  Did you try some CJK input 
> methods, for example, which offer several alternatives for each key 
> sequence the user typed?
>

I tried french-postfix, russian-computer, ucs, TeX, arabic, japanese and 
chinese-py.  From what I can see, everything works as expected, but I 
don't speak or read these languages, and there are more than 200 input 
methods, I cannot test them all.

>> +When RESET is non-nil, the events in `unread-command-events' are first
>> +discarded."
>
> I'm not sure we need this as part of the function: it makes the function 
> more complicated for no good reason.  Why not reset 
> unread-command-events "by hand" in the one place where that is needed? 
> Or maybe even explicitly use (no-record . 7) in that one place, and then 
> you can avoid calling this function, since that one place does something 
> very different from the rest.
>

I did this to simplify future debugging sessions.  Having Quail interact 
with unread-command-events in a single place will make that easier.  And 
the added complexity is really small.

>> @@ -883,6 +882,9 @@ terminal-init-xterm
>>    (xterm--init-bracketed-paste-mode)
>>    ;; We likewise unconditionally enable support for focus tracking.
>>    (xterm--init-focus-tracking)
>> +  ;; Clear the lossage to discard the responses of the terminal emulator
>> +  ;; during initialization (Bug#44908)
>> +  (clear-this-command-keys)
>
> Btw, what happens if while this code runs, the user types something? We 
> don't want those events to be cleared.
>

It's quite hard to type something at that moment AFAICS, the whole 
terminal initialization typically takes at most 50 ms.  I tried to type 
something as fast as possible during the terminal initialization, and what 
happens is this (visible in *Messages*):

q is undefined
M-] is undefined
; is undefined
r is undefined
g is undefined
b is undefined
: is undefined
f is undefined [4 times]
/ is undefined
f is undefined [4 times]
/ is undefined
f is undefined [4 times]

or this:

q is undefined
M-[ > is undefined
; is undefined [2 times]
c is undefined

The first key is the pressed key ("q"), the other keys are some of the 
keys of the terminal initialization process (the digits are bound to 
digit-argument in the *GNU Emacs* buffer and are therefore not undefined):

ESC [ > ESC [ > 4 1 ; 3 6 6 ; 0 c ESC ] 1 1 ; r g b : f f f f / f f f f / 
f f f f ESC \

IOW, if the user presses something at that moment, the terminal 
initialization process does not work as expected.

(FWIW, I would have closed bug#44908 as a wontfix, seeing a few unwanted 
keys in the lossage after starting Emacs is a really minor annoyance.)

[Fix-key-recording-bug-when-an-input-method-is-activa.patch (text/x-diff, attachment)]

Previous Next

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