> 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?
The idea is that a macro running without user interaction -- one that may take minutes to run (repeatedly) -- shouldn't interact with the window system clipboard because the user may be doing so concurrently. I think it's more than a bit strange to use the system clipboard (presumably using windows other than Emacs) while defining a keyboard macro that itself uses kill-ring commands, since the interaction with the window system (and/or other applications) can't be included in the macro. In other words, it doesn't make much sense to define a macro while you're copying text between windows. It does make sense to run a macro while you're copying text, and the two operations shouldn't interfere. Moreover, while defining a macro the user is in control and the clipboard is thus in control; while running a macro there's no such connection. So I think that doing this separation during macro execution is sufficient. > > 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? http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00108.html Jason Rumney made a reasonable suggestion in http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00778.html, but I'd like to hear Richard's answer to the question (if he has a preference), since he raised the issue. 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
