You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During recording, I noticed certain last-input-events such as:
(file-notify ((30 . 0) (modify) "2024-12-29 21-00-31.mkv" 0)
file-notify--callback-inotify
These are not so helpful, but since I don't immediately know the range of other
such inputs, it was better to relax the checks.
C-g is supported. Most users should know it and it will stop errant macros from
proceeding to destroy the system.
The comprehensive solution is to prevent fat-finger inputs in the first place.
It would be better to also support having the macro just dump remaining events
into unread-command-events whenever direction keys are called during playback.
I might still want to bind in the special map to block unwanted fat fingers. It
is the only way to ensure that they don't corrupt the recorded sequence.
Copy file name to clipboardExpand all lines: NEWS.org
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,7 @@ Fixing bugs and filling some gaps in new features.
29
29
- ~dslide-deck-forward~ no longer no-ops in some circumstances
30
30
- kmacro action properly skips over non-matching directions when both forward and backward elements are present in a slide
31
31
- 🚧 kmacro playback of =M-<return>= and =M-<backspace>= and others is now correct. There are likely more events that don't round trip nicely from ~last-kbd-macro~ through ~key-description~ and back through ~read-kbd-macro~. *File issues*.
32
+
- 🚧 kmacro playback no longer aborts when inputs from file-notify etc occur. It can be quit with =C-g=. A more comprehensive solution is being developed.
0 commit comments