[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Rodgers
Subject: Re: address@hidden: Kill ring leak in winemacs macros]
Date: Thu, 18 Aug 2005 10:56:33 -0600
User-agent: Mozilla Thunderbird 0.9 (X11/20041105)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]