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 #78 received at 48042 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 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: Sat, 15 May 2021 21:52:24 +0300
> Date: Sat, 15 May 2021 18:47:00 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: monnier <at> iro.umontreal.ca, harven <at> free.fr, 48042 <at> debbugs.gnu.org
> 
> > 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.

No one can test all of them, that's not what I meant.

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

So maybe we shouldn't discard the input if the initialization fails?
Otherwise we leave no traces that could allow understanding what
happened.

Thanks.




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

Previous Next


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