Re: Severe regressions in context of keyboard macros

[Christoph Arenz <tiga.arenz@web.de>]

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!