Re: Severe regressions in context of keyboard macros

[Christoph Arenz]

On 28.09.19 11:46, Eli Zaretskii wrote:
> > I spent some more time on this. The problem is bigger than stated in the
> > original bug report:
> > Any function key that follows a digit and is not separated by a <spc> or
> > <return> is recorded twice in calc when defining a keyboard macro, e.g.
> > `1 <return> <f3> 2 + <f4>' records "2++".
> Is this while using Calc, or is this in some other situation?
Just in Calc. I should have been a bit clearer what I meant with
`function' key:
While calc is reading digits, it recognizes it has rad a complete number
when reading <spc> or <return>.

Calc also recognizes a number when reading a calc function key when
reading digits. This is one path when calc reads this key a second time.


Here is lossage for such a case:
 1             ;; calcDigit-start
 <return>      ;; calcDigit-nondigit
 1             ;; calcDigit-start
 2             ;; calcDigit-key
 +             ;; calcDigit-key
 +             ;; calc-plus


Note the `+' being read twice. With the proposed patch, lossage looks
just the same -- just in case of keyboard macro recording, we avoid the
`+' being recorded twice. Lossage in this case looks like this:
 <f3>         ;; kmacro-start-macro-or-insert-counter
 1            ;; calcDigit-start
 <return>     ;; calcDigit-nondigit
 1            ;; calcDigit-start
 2            ;; calcDigit-key
 +            ;; calcDigit-key
 ;; calc-plus
 <f4>         ;; kmacro-end-or-call-macro
> > I am getting more confident that the patch below fixes this bug.Itfixes
> > a severe issue with macros in calc, does not make things worse and does
> > not interfere in case no macro is being defined.
> >
> > Your thoughts?
> If it works well for you in Calc, I will install it.
>
> Thanks.
Yes, the patch definitely improves the situation. Thanks!
> P.S.  I'll look into the other bug, regarding input methods, when I
> have time.  Thanks for filing it.
Thanks for that as well!