yank-handler

[Luc Teirlinck]

Revision 1372 of subr.el drastically changed the behavior of
`insert-for-yank', but made no supporting changes in `kill-new'.
Such supporting changes are necessary as the ielm run below shows:

===File ~/killielm==========================================
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (kill-new "01234" nil '(ignore))
nil
ELISP> kill-ring
(#("01234" 0 1
   (yank-handler
    (ignore))
   1 5 nil))

ELISP> ;; C-y gives: 1234
ELISP> (kill-append "56789" t '(ignore))
nil
ELISP> kill-ring
(#("5678901234" 0 1
   (yank-handler
    (ignore))
   1 5 nil 5 6
   (yank-handler
    (ignore))
   6 10 nil))

ELISP> ;; C-y gives: 
67891234============================================================

As before, `kill-new' only sets the yank-handler property of the
_first_ character of the string, because it considers that to be
representative of the entire string.  But `insert-for-yank' now only
considers it to be representative for that first character itself and
the resulting behavior makes no sense.

The following trivial change to `kill-new' would eliminate the
"miscommunication" between `kill-new' and `insert-for-yank'.

It remains to be decided what the behavior of `kill-append' ought to
be.  If we _only_ make the change below, then `kill-append' returns to
its pre-revision-1372 behavior if called with a non-nil yank-handler
argument: the yank-handler argument applies to both parts of the
string.  That seems good.  If no explicit yank-handler argument is
specified the old behavior was that the yank-handler was set to nil
for the entire result string if the new string was prepended and the
yank-handler of the old string applied to the entire string if the new
string was appended: the first character was what mattered.  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'.

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 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.  Maybe one just will have to be extremely
careful when specifying 4-part yank-handlers.

===File ~/simple-diff=======================================
*** simple.el.~1.629.~  Wed Feb 11 22:08:18 2004
--- simple.el   Thu Feb 12 20:36:09 2004
***************
*** 1842,1848 ****
  argument should still be a \"useful\" string for such uses."
    (if (> (length string) 0)
        (if yank-handler
!         (put-text-property 0 1 'yank-handler yank-handler string))
      (if yank-handler
        (signal 'args-out-of-range
                (list string "yank-handler specified for empty string"))))
--- 1842,1849 ----
  argument should still be a \"useful\" string for such uses."
    (if (> (length string) 0)
        (if yank-handler
!         (put-text-property 0 (length string)
!                            'yank-handler yank-handler string))
      (if yank-handler
        (signal 'args-out-of-range
                (list string "yank-handler specified for empty string"))))
============================================================