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
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
