Re: yank-handler

[storm@cua.dk (Kim F. Storm)]

Luc Teirlinck <teirllm@dms.auburn.edu> 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!

> Without
> 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.

Please do!

> 
> _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.