|Subject:||Re: Severe regressions in context of keyboard macros|
|Date:||Fri, 20 Sep 2019 17:43:13 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0|
[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:
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 <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"),
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.
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".
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.
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|