Yes, there are a number of hits for "kbd-macro". However as far as I understand, calc relies on emacs' normal keyboard macro functions to record the macro in the first place.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"),
hmm... who would that be? It seems that Jay Belanger stepped down as maintainer of the calc package 4 years ago, putting in emacs-devel as contact...so someone who knows Calc should go over that
So, with regard to keyboard macros, is the following change intentional?and adapt what Calc does there to the new method of recording and replaying keyboard macros. I expect the fix to be simple.
I see your point. The other aspect is which keys were 'pressed'? The documentation of open-dribble-file (mentioning 'keyboard characters' and 'all characters you type') seems not very precise regarding this...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.