Re: Severe regressions in context of keyboard macros

[Christoph Arenz]

[re-sending -- sorry, forgot to cc: emacs-devel the first time]

Thanks for your response!

On 9/20/19 9:23 AM, Eli Zaretskii wrote:

From: Christoph Arenz <address@hidden>
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"), 

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.

so someone who knows Calc should go over that

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...

and adapt what Calc does there to the new method of recording and
replaying keyboard macros.  I expect the fix to be simple.

So, with regard to keyboard macros, is the following change intentional?
Having a scratch buffer with
(push ?a unread-command-events)
the key presses <f3> C-x C-e <f4> resulted in an "a" being inserted, and a keyboard macro being recorded.
The behavior before 30a6b1f81412044a was that last-kbd-event was set to "^X^E" and afterwards to "^X^Ea".

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.

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...
My thinking was that the new semantics makes it harder to interpret an occurrence of "<f3>" in dribble file: Is it a start of a new macro recording or is it an insertion (and incrementation) of a macro counter?
I guess it is as one cannot 'see' in the dribble file, where the macro-caused events inserted after a "<f4>" end.

However, I have not fully thought this through... maybe it is that prior behavior was to write out the meta-level only with regard to keyboard macros and now have meta-level and results mixed together.

Thanks,
Christoph