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