[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: Severe regressions in context of keyboard macros

From: Christoph Arenz
Subject: Fwd: Re: Severe regressions in context of keyboard macros
Date: Fri, 27 Sep 2019 16:58:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

FYI -- the bug regarding the input methods and keyboard macros is now filed in a separate bug report:
bug#37526: 27.0.50; double-recording of keys with input-methods and keyboard-macros


-------- Forwarded Message --------
Subject: Re: Severe regressions in context of keyboard macros
Date: Thu, 26 Sep 2019 12:46:20 +0200
From: Christoph Arenz <address@hidden>
To: Eli Zaretskii <address@hidden>
CC: address@hidden

On 9/24/19 10:45 AM, Eli Zaretskii wrote:
How about the following patch? It solved the calc bug for me and I could not find other regressions so far.
Running make check showed no difference.
As mentioned, I do not understand all potential effects, so it should be given some thoughts and tests.
Thanks, but I'd like to avoid changes in keyboard.c on behalf of input
recording issues, unless such changes are really a must. In this
case, we already have 2 facilities to deal with unwanted repeated
recording of keys:
Thanks for the pointers!
. a Lisp program can bind inhibit--record-char to a non-nil value to
avoid recording input events while some Lisp form is executed (you
can see an example of using this in quail.el:quail-start-translation
. a Lisp program can push onto unread-command-events a cons cell of
the form '(no-record . KEY) to avoid recording KEY more than once
(you can see an example of using this in

Can you use one of these facilities to solve the issue in Calc? Note
that you will need to build Emacs from the Git master branch to be
able to use these facilities, they are not available before Emacs 27.
I think we are on to something here!
The sample in quail.el sounded fitting for me at first, but I could not get it working for the calc case.
So I took a closer look at input-methods -- that is what quail is used for, right?

I tried some simple tests using the french word for brother (`frère' -- the first `e' is with a ``' on top of it -- hopefully my mailer does not screw this up...)
using various french input methods: french-prefix, french-postfix and french-azerty -- all in context of keyboard macro recording and playback.
The calc case should fit nicely with the -postfix case, I thought.

However, on master branch 07367e5b95fe31f3d4e994b42b081075501b9b60, I got this:

keys pressed: <f3> f r ` e r e , <spc> <f4> <f4> <f4>
text inserted in buffer: "frère, frère,  frère  "
last-kbd-macro: "fr`ere,  "
--> Note the two(!) <spc> recorded after the `,' though only one was typed in!

keys pressed: <f3> f r e ` r e , <spc> <f4> <f4> <f4>
text inserted in buffer: "frère, frèrre,, frèrre,, "
last-kbd-macro: "fre`rre,, "
--> Note the double recording of `r' and `,' !
--> This closely resembles the reported symptoms for the calc package!

keys pressed (on US keyboard-layout): <f3> f r e 7 r e m <spc> <f4> <f4> <f4>
text inserted in buffer: "frère, frère, frère, "
last-kbd-macro: "fr7rem "
--> This looks as I would expect it.

A quick check on emacs-24.5 showed that all cases were handled correctly back then.
So, some of the new ways of handling this are not covering all corner cases, and work wrong with -postfix and calc prefix handling.

Does this give any clues what still needs to be fixed? I am lost in the complexity of how the code should handle this...
N.B. For what it's worth, I am physically using a german keyboard with a US layout in GNOME.
Probably this should not matter and be equivalent to a US keyboard...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]