Odd unused yank-handler arguments

Odd unused yank-handler arguments

[Stefan Monnier]

Any objection to the patch below?


        Stefan


=== modified file 'lisp/simple.el'
--- lisp/simple.el	2010-05-02 06:12:39 +0000
+++ lisp/simple.el	2010-05-02 06:14:00 +0000
@@ -2929,7 +2929,7 @@
   :group 'killing
   :version "23.2")
 
-(defun kill-new (string &optional replace yank-handler)
+(defun kill-new (string &optional replace)
   "Make STRING the latest kill in the kill ring.
 Set `kill-ring-yank-pointer' to point to it.
 If `interprogram-cut-function' is non-nil, apply it to STRING.
@@ -2964,13 +2964,6 @@
         (kill-new paste))))
   ;; The actual kill-new functionality.
   (when (equal string (car kill-ring)) (setq replace t))
-  (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"))))
   (when (and kill-do-not-save-duplicates
              (equal string (car kill-ring)))
     (setq replace t))
@@ -2993,7 +2986,7 @@
   (if interprogram-cut-function
       (funcall interprogram-cut-function string (not replace))))
 
-(defun kill-append (string before-p &optional yank-handler)
+(defun kill-append (string before-p)
   "Append STRING to the end of the latest kill in the kill ring.
 If BEFORE-P is non-nil, prepend STRING to the kill.
 Optional third argument YANK-HANDLER, if non-nil, specifies the
@@ -3004,10 +2997,7 @@
 instead of replacing the last kill with it.
 If `interprogram-cut-function' is set, pass the resulting kill to it."
   (let* ((cur (car kill-ring)))
-    (kill-new (if before-p (concat string cur) (concat cur string))
-	      (or (= (length cur) 0)
-		  (equal yank-handler (get-text-property 0 'yank-handler cur)))
-	      yank-handler)))
+    (kill-new (if before-p (concat string cur) (concat cur string)) t)))
 
 (defcustom yank-pop-change-selection nil
   "If non-nil, rotating the kill ring changes the window system selection."
@@ -3068,7 +3058,7 @@
      '(text-read-only buffer-read-only error))
 (put 'text-read-only 'error-message (purecopy "Text is read-only"))
 
-(defun kill-region (beg end &optional yank-handler)
+(defun kill-region (beg end)
   "Kill (\"cut\") text between point and mark.
 This deletes the text from the buffer and saves it in the kill ring.
 The command \\[yank] can retrieve it from there.
@@ -3102,8 +3092,8 @@
 	(when string			;STRING is nil if BEG = END
 	  ;; Add that string to the kill ring, one way or another.
 	  (if (eq last-command 'kill-region)
-	      (kill-append string (< end beg) yank-handler)
-	    (kill-new string nil yank-handler)))
+	      (kill-append string (< end beg))
+	    (kill-new string)))
 	(when (or string (eq last-command 'kill-region))
 	  (setq this-command 'kill-region))
 	nil)

RE: Odd unused yank-handler arguments

[Drew Adams]

> Any objection to the patch below?
>
> -(defun kill-new (string &optional replace yank-handler)
> +(defun kill-new (string &optional replace)
>  
> -(defun kill-append (string before-p &optional yank-handler)
> +(defun kill-append (string before-p)
>  
> -(defun kill-region (beg end &optional yank-handler)
> +(defun kill-region (beg end)

1. I don't use the `yank-handler' arg myself, so I don't have any objection a
priori.

2. However, why not give the reason for the change?

To understand this, I'm looking through the code (since Emacs 22, when this arg
was introduced) to try to understand. It seems to all turn around
`insert-for-yank-1', which still seems to respect a `yank-handler' property.

At least in the 1-96 pretest and in your patch, I see no change to the
`insert-for-yank-1' behavior, so this is apparently only to remove the arg for
those three `kill-*' functions. Can you give an idea what is behind the proposed
change?

Perhaps the reason is that those functions should never have had such an arg. Or
perhaps it is that they no longer need it. Or that no existing code using them
uses the arg. Or...

IOW, why not be clear, saying (a) whether there is also some associated general
change to the yank-handler handling and (b) what the particular motivation for
this change is?

Removing an arg is like adding an arg. What's the reason?

Re: Odd unused yank-handler arguments

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Any objection to the patch below?

I think I wrote that code, but my memory about it is a bit vague.

IIRC, the rationale for the yank-handler argument was that I wanted a
simple way for code to put the yank-handler onto strings that are pushed
onto the kill ring.

If you change this, remember to fix comint-kill-region too, and the docs.

-- 
Kim F. Storm  http://www.cua.dk

Re: Odd unused yank-handler arguments

[Stefan Monnier]

> 2. However, why not give the reason for the change?

Reduce complexity.

> Perhaps the reason is that those functions should never have had such
> an arg.  Or perhaps it is that they no longer need it.  Or that no
> existing code using them uses the arg.  Or...

IIUC the yank-handler code evolved a bit before finding its meaning, and
those args are left overs from this process: they seemed like a good
idea at the time, but in the end all we really care about and need is
the `yank-handler' property.

> Removing an arg is like adding an arg. What's the reason?

Maintenance.


        Stefan

RE: Odd unused yank-handler arguments

[Drew Adams]

> > 2. However, why not give the reason for the change?
> >    Perhaps the reason is that those functions should never 
> >    have had such an arg.  Or perhaps it is that they no longer
> >    need it.  Or that no existing code using them uses the arg.
> >    Or...
> 
> IIUC the yank-handler code evolved a bit before finding its 
> meaning, and those args are left overs from this process: they
> seemed like a good idea at the time, but in the end all we
> really care about and need is the `yank-handler' property.

See? That wasn't so hard to explain.