Re: Severe regressions in context of keyboard macros

[Eli Zaretskii <eliz@gnu.org>]

> From: Christoph Arenz <tiga.arenz@web.de>
> Date: Thu, 19 Sep 2019 10:17:17 +0200
> 
> Calc:
> I stumbled across the following bug using calc -- see also
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37057:
> 90 <RET> S <f3> I S <f4>
> This calculates the sine and inverse sine of 90 -- with a result of 90.
> It also records "IS" as a keyboard macro.
> Now, let's use the macro to complete the same calculation:
> 90 <RET> S <f4>
> This worked until emacs-24.5 but is broken since emacs-25.1 where "ISS" is recorded as a keyboard macro
> -- now leading to a result of 1.

Calc seems to have various tricks related to keyboard macros (e.g.,
search for "kbd-macro"), so someone who knows Calc should go over that
and adapt what Calc does there to the new method of recording and
replaying keyboard macros.  I expect the fix to be simple.

> Dribble:
> According to the documentation in open-dribble-file, this starts 'writing all keyboard characters to a dribble
> file'. 
> However, the keys being recorded changed with commit 30a6b1f81412044a when a keyboard macro is
> involved.
> 
> Prior, the key "<f4>" was recorded when a macro was replayed. With the patch, the recording contains "<f4>"
> and additionally all characters that were replayed by the macro. This gets ugly quickly, e.g. when <f3> was
> used in the macro to insert a counter.

Why is that a problem?  I think the current dribble is more accurate,
as it shows what was injected into the Emacs keyboard event queue.

Thanks.