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

[Kevin Rodgers]

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