Re: address@hidden: Kill ring leak in winemacs macros]

[Stuart D. Herring]

> I think you mean it should be checked while defining a macro, as well as
> when executing one, because the first time a macro is executed is when
> it is defined -- right?

The idea is that a macro running without user interaction -- one that may
take minutes to run (repeatedly) -- shouldn't interact with the window
system clipboard because the user may be doing so concurrently.  I think
it's more than a bit strange to use the system clipboard (presumably using
windows other than Emacs) while defining a keyboard macro that itself uses
kill-ring commands, since the interaction with the window system (and/or
other applications) can't be included in the macro.

In other words, it doesn't make much sense to define a macro while you're
copying text between windows.  It does make sense to run a macro while
you're copying text, and the two operations shouldn't interfere. 
Moreover, while defining a macro the user is in control and the clipboard
is thus in control; while running a macro there's no such connection.  So
I think that doing this separation during macro execution is sufficient.

>  > One point, remains, though: Richard said he wanted the kill-ring
>  > re-synchronized with the external world at the end of a keyboard macro
>  > that desynched them; I guess that would have to go in
> execute-kbd-macro.
>  > But what should happen if both Emacs and the window system have new
> text
>  > at that point (where no ordering exists between them)?
>
> Where did he say that?

http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00108.html

Jason Rumney made a reasonable suggestion in
http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00778.html, but
I'd like to hear Richard's answer to the question (if he has a
preference), since he raised the issue.

Davis Herring

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.