[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: yank-handler

From: Kim F. Storm
Subject: Re: yank-handler
Date: 13 Feb 2004 17:15:12 +0100
User-agent: 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!

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]