yank-handler

yank-handler

[Stefan Monnier]

I'd like to get diff-mode to behave as follows:

If I kill a piece of a hunk and then yank it in some other buffer,
the "[+-! ]" prefix added to each and every line should be removed
(unless I'm yanking back into a diff-mode buffer or unless there's
something like a "@@ -463,4 +463,36 @@" marker, obviously).

I'm still not quite sure whether it's a good idea or not, but to
figure that out, I'd like to experiment with it, but I can't seem
to figure out how to do it.

More specifically, it seems that the yank-handler property can only be
set by passing the proper argument to `kill-new' (or one
of its front men).  Is that right ?  Why is that ?
I don't want to rebind C-k, C-w, M-w and whatnot just to do that.
I'd rather either put the property directly on the text, or set
some buffer-local `default-yank-handler-for-kill' variable.

Any comment ?


	Stefan

Re: yank-handler

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> I'd like to get diff-mode to behave as follows:
> 
> If I kill a piece of a hunk and then yank it in some other buffer,
> the "[+-! ]" prefix added to each and every line should be removed
> (unless I'm yanking back into a diff-mode buffer or unless there's
> something like a "@@ -463,4 +463,36 @@" marker, obviously).
> 
> I'm still not quite sure whether it's a good idea or not, but to
> figure that out, I'd like to experiment with it, but I can't seem
> to figure out how to do it.
> 
> More specifically, it seems that the yank-handler property can only be
> set by passing the proper argument to `kill-new' (or one
> of its front men).  Is that right ?  Why is that ?

Because that was the context in which the idea was conceived (e.g.
for a mode like table-mode where a keymap property on text in a table
cell (but not on the buffer as a whole) would remap kill-region
etc. to table-kill-region etc. which would set the proper yank-handler
for yanking killed table contents in some sensible manner.


> I don't want to rebind C-k, C-w, M-w and whatnot just to do that.
> I'd rather either put the property directly on the text, or set
> some buffer-local `default-yank-handler-for-kill' variable.

I like the simplicity of having a buffer-local
default-yank-handler-for-kill variable (default nil).

I guess it would also work by having the yank-handler property
directly on the text in the buffer; especially since that property is
supposed to be removed automatically when the text is yanked into the
buffer (see insert-for-yank).

> 
> Any comment ?

Feel free to go ahead and improve the yank-handler functionality.

I think those changes can be localized to kill-new and kill-append
like this:

- In `kill-new' and `kill-append' add this at the beginning:
        (unless yank-handler
          (setq yank-handler default-yank-handler-for-kill))

- In `kill-new', simply remove this "else part" in the second if:
	(remove-list-of-text-properties 0 1 '(yank-handler) string))

Your new functionality for diff-mode will be a good "proof of concept".
          
-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: yank-handler

[Richard Stallman]

    If I kill a piece of a hunk and then yank it in some other buffer,
    the "[+-! ]" prefix added to each and every line should be removed
    (unless I'm yanking back into a diff-mode buffer or unless there's
    something like a "@@ -463,4 +463,36 @@" marker, obviously).

I have a bad feeling about this--it is the sort of thing
that makes the editor overall less controllable.  I would
prefer some sort of feature to copy part of a diff buffer
into the kill ring without these prefixes.

Re: yank-handler

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     If I kill a piece of a hunk and then yank it in some other buffer,
|>     the "[+-! ]" prefix added to each and every line should be removed
|>     (unless I'm yanking back into a diff-mode buffer or unless there's
|>     something like a "@@ -463,4 +463,36 @@" marker, obviously).
|> 
|> I have a bad feeling about this--it is the sort of thing
|> that makes the editor overall less controllable.  I would
|> prefer some sort of feature to copy part of a diff buffer
|> into the kill ring without these prefixes.

I've been using this for years:

(defun delete-columns (start end cols)
  "Delete columns from the beginning of the lines in the region.
Prefix argument gives the number of columns to delete."
  (interactive "*r\np")
  (save-excursion
    (goto-char end)
    (if (bolp) (forward-line -1))
    (move-to-column cols)
    (if (eolp) (indent-to cols))
    (delete-rectangle
     (save-excursion (goto-char start) (beginning-of-line) (point))
     (point))))

(defun copy-diff (&optional reverse)
  "Copy the current hunk of a context diff into the buffer in the next window.
Point must be at the first line to be copied.
Optional arg REVERSE (prefix arguement if interactive) means to
 assume a reversed patch."
  (interactive "P")
  (let (start region)
    (beginning-of-line)
    (setq start (point))
    (if (not (and (looking-at (if reverse "[-!] " "[+!] "))
		  (re-search-forward (if reverse
					 "\\(^[^-!]\\|\\'\\)"
				       "\\(^[^+!]\\|\\'\\)") nil t)))
	(error "Not at a context diff marker")
      (beginning-of-line)
      (setq region (buffer-substring start (point)))
      (other-window 1)
      (set-buffer (window-buffer (selected-window)))
      (push-mark)
      (insert region)
      (delete-columns (mark t) (point) 2))))

(defun copy-unidiff (&optional reverse)
  "Copy the current hunk of an unified diff into the buffer in the next window.
Point must be at the first line to be copied.
Optional arg REVERSE (prefix arguement if interactive) means to
 assume a reversed patch."
  (interactive "P")
  (let (start region)
    (beginning-of-line)
    (setq start (point))
    (if (not (and (eq (following-char) (if reverse ?- ?+))
		  (re-search-forward (if reverse
					 "\\(^[^-]\\|\\'\\)"
				       "\\(^[^+]\\|\\'\\)") nil t)))
	(error "Not at unified diff marker")
      (beginning-of-line)
      (setq region (buffer-substring start (point)))
      (other-window 1)
      (set-buffer (window-buffer (selected-window)))
      (push-mark)
      (insert region)
      (delete-columns (mark t) (point) 1))))

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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"))))
============================================================

Re: yank-handler

[Luc Teirlinck]

>From my previous message:

   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.

The above quote applies to kill-append called without explicit
yank-handler (or a nil yank handler) on the new string with the old
string as car of the kill ring.  The above quote is inaccurate.  The
new string would _keep_ any _pre-existing_ yank-handler properties,
just like the old one. 

Sincerely,

Luc.

Re: yank-handler

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