Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros]

["Stuart D. Herring" <herring@lanl.gov>]

> I'm not convinced this change is a good one. What if your macro involves
> a call-process call to an external program that interacts with Emacs via
> the [clipboard]?

What kind of keyboard macro could communicate asynchronously with another
program, via the clipboard or otherwise?  Something like that would seem
to require real Lisp anyway.  Moreover, this whole change would be
optional (customizable), so the user of any such macro could turn off that
option (maybe even temporarily and within the macro to make it
self-contained).  So I don't think this change can hurt anything.

...I realize, reading the previous paragraph, that this answers the
question of which implementation to pursue.  The obvious value of a macro
that temporarily enables (or disables) clipboard communication means that
the customize option should be checked within the macro, not in
execute-kbd-macro.

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)?

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.