GNU bug report logs - #32108
27.0.50; Insertion of char from input method during macro invocation duplicates the char

Previous Next

Package: emacs;

Reported by: Filipp Gunbin <fgunbin <at> fastmail.fm>

Date: Mon, 9 Jul 2018 22:42:02 UTC

Severity: normal

Tags: confirmed

Merged with 34248

Found in versions 25.1, 27.0.50

Fixed in version 27.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: rgm <at> gnu.org, fgunbin <at> fastmail.fm, 32108 <at> debbugs.gnu.org
Subject: bug#32108: 27.0.50; Insertion of char from input method during macro invocation duplicates the char
Date: Wed, 11 Jul 2018 18:23:39 +0300
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Glenn Morris <rgm <at> gnu.org>, fgunbin <at> fastmail.fm, 32108 <at> debbugs.gnu.org
> Date: Wed, 11 Jul 2018 08:58:25 -0400
> 
> I haven't taken the time to look at the details of why read_char sees
> the character twice, but maybe we can use the (t . EVENT) format of
> events which says that EVENT shouldn't be recorded (tho I'm not sure
> it's the same form of "recording" and I'm not sure either that we can
> apply this trick to the right "copy" of the two).

I think I'm missing something: how does (t . EVENT) help us in this
case?  What we need is a way to distinguish between a character that
gets re-processed by quail.el from the use case described in the
reference mentioned in the log message of commit 30a6b1f, which was
the reason why we added the second call to record_char to read_char,
where previously there was none.  Don't both of these use cases use
the same machinery?

Thanks.




This bug report was last modified 6 years and 117 days ago.

Previous Next


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