Re: Severe regressions in context of keyboard macros

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

[-- Attachment #1: Type: text/plain, Size: 3141 bytes --]

[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<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"),
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

[-- Attachment #2: Type: text/html, Size: 4555 bytes --]