emacs-devel
[Top][All Lists]
Advanced

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

Re: Severe regressions in context of keyboard macros


From: Christoph Arenz
Subject: Re: Severe regressions in context of keyboard macros
Date: Thu, 26 Sep 2019 12:46:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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
     cua-base.el:cua--prefix-override-replay)

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:

french-prefix:
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!

french-postfix:
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!

french-azerty:
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...


Thanks!




reply via email to

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