Ben, I believe one of your changes to kill-line broke its execution in macros. For some time now I've been witnessing a strange discrepancy in the behavior of keyboard macros during recording and execution. Finally I've narrowed it down to `kill-line' misbehaving. The problem is that the variable `kill-whole-line' is not respected when `kill-line' is executed as part of a keyboard macro. TO REPEAT: Start `xemacs -vanilla', set `kill-whole-line' to t. See that kill-line at BOL kills the entire line. Now record a macro solely consisting of C-k: C-x ( C-k C-x ) Try executing it with `C-x e' and you'll see that it no longer kills the whole line, but only the part up to the newline, as if kill-whole-line were set to nil. I haven't had the time to investigate this properly, but I suspect the problem is in this change: If called interactively, may kill the entire line when given no ^^^^^^^^^^^^^^^^^^^^^^^ argument at the beginning of a line; see `kill-whole-line'. Apparently functions bound to keys executed in keyboard macros get call non-interactively[1]. In the case of kill-line, it makes a big difference, thus causing the macro weirdness. I'm working around the problem by redefining kill-line in my .emacs, but a real fix would be to make macro execution execute commands with `call-interactively', as God intended. (But this may cause other side effects.) [1] This is easy to test by creating a dummy command that prints a message if (interactive-p) and binding it to a key. And indeed, I confirmed that such a command prints its message on a key press, but not when invoked as part of macro execution!

Ben Wing <ben(a)666.com&gt; writes: > i hereby withdraw my change, and the associated news file entry: Hmph. Why? Shouldn't we just fix the macro thing? kill-line is not the only function that behaves differently depending on whether you call it interactively.