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

[Kevin Rodgers <ihs_4664@yahoo.com>]

Stuart D. Herring wrote:
 > 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.

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?

In that case, start-kbd-macro should also respect the proposed new
option (by setting the interprogram-*-function variables) and
end-kbd-macro should restore them (which means start-kbd-macro would
need to save their original values).  But that can't be done with simple
let bindings, as it can 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)?

Where did he say that?

-- 
Kevin Rodgers