|
From: | Christoph Arenz |
Subject: | Severe regressions in context of keyboard macros |
Date: | Thu, 19 Sep 2019 10:17:17 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
I think I have found
two regressions that were introduced some time ago by commit
30a6b1f81412044a, affecting keyboard macros. One is severely
affecting calc to the point of leading to completely wrong results
-- if not stopped by an error first. The other is affecting how
dribble writes out recorded keys. 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. It seems all macros that involve calc's prefix keys (e.g. "I" or "H") have the following key recorded twice in last-kbd-macro. E.g. "IHP" is recorded as "IHHPP", pushing GAMMA and PI on the stack instead of one constant, namely PHI. Hopefully, the calculation breaks due to an error -- otherwise, you get nonsense results which might be hard to debug, if noticed at all. 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. I am not suggesting that reverting commit 30a6b1f81412044a is the final and right solution, but it does resolve the two issues in calc and dribble in emacs-26.3. I stumbled across the mail thread https://lists.gnu.org/archive/html/emacs-devel/2015-08/msg00193.html where there were some doubts whether the quick fix could break something else. Keyboard.c seems highly complex and magic to me. I first thought that sit-for in subr.el might have something to do with it as it has fixme comments mentioning unread-command-events. Just a wild guess... |
[Prev in Thread] | Current Thread | [Next in Thread] |