[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Kim F. Storm
13 Feb 2004 17:15:12 +0100
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50
Luc Teirlinck <address@hidden> writes:
> Revision 1372 of subr.el drastically changed the behavior of
> `insert-for-yank', but made no supporting changes in `kill-new'.
Good catch, Luc!
> further changes, the patch below would keep all yank handlers of the
> old string in place, whereas the new string would get no yank-handler.
> This independently of whether the new string got prepended or
> appended. That behavior might actually make more sense, given the new
> "philosophy" of `insert-for-yank'.
Yes, that seems to be the logical choice.
> If desired, I could, of course, commit the trivial patch below.
> _However_, without further changes, the UNDO specified by the _last_
> yank-handler region always seems to win for the _entire_ yank. I do
> not feel comfortable at all about this, although I know of no concrete
> bugs resulting from it.
I don't think there are any uses of the yank-handler undo feature yet.
Actually, table.el seems to be the only usage of yank-handlers, and it
doesn't even seem to use more than very basic features of it.
In any case, as long as we haven't made a final 22.x release, we are
free to fix it anyway we feel necessary.
> I suspect the latter might just be due to the
> fact that 4-part yank-handlers are not used very often in the Emacs
> source code. I can not immediately think of _any_ safe way to handle
> competing UNDO's however.
I think it is necessary to build a list of undo functions and the
region they apply to, rather than just a single yank-undo-function.
I don't have time to work on it though.
Still, the yank-handler functionality may need more general rework (I
recall Stefan making some comments about it a while back).
> Maybe one just will have to be extremely
> careful when specifying 4-part yank-handlers.
I think that will always be true -- yank-handler can make a lot of
problems if done carelessly.