kill-new discards current X selection

kill-new discards current X selection

[Sam Steingold]

When I select a word in an xterm and then kill in emacs, then X selection is 
gone forever, replaced with the emacs kill.
The appended patch prepends the current X selection to kill-ring before 
replacing the X selection with the current Emacs kill.
Is it OK to install it unconditionally, or is it better to guard it with a user 
option, e.g., save-interprogram-paste-before-kill?


--- simple.el.~1.1005.~	2009-08-25 16:44:36.000000000 -0400
+++ simple.el	2009-08-26 12:15:19.000123000 -0400
@@ -2819,6 +2819,13 @@ argument should still be a \"useful\" st
  		(list string "yank-handler specified for empty string"))))
    (if (fboundp 'menu-bar-update-yank-menu)
        (menu-bar-update-yank-menu string (and replace (car kill-ring))))
+  (let ((interprogram-paste (and interprogram-paste-function
+				 (funcall interprogram-paste-function))))
+    (when interprogram-paste
+      (if (listp interprogram-paste)
+        (dolist (s (nreverse interprogram-paste))
+          (push s kill-ring))
+        (push interprogram-paste kill-ring))))
    (if (and replace kill-ring)
        (setcar kill-ring string)
      (push string kill-ring)

Re: kill-new discards current X selection

[Jan D.]

I for one would be very surprised if the X selection popped up in the  
kill-ring just because I made a kill in Emacs.

An option to tell Emacs to grab the primary X selection only when  
something is selected with the mouse would be nice. Maybe there  
already exists one. I assume you mean the primary selection?

        Jan D.

26 aug 2009 kl. 18.18 skrev Sam Steingold <sds@gnu.org>:

> When I select a word in an xterm and then kill in emacs, then X  
> selection is gone forever, replaced with the emacs kill.
> The appended patch prepends the current X selection to kill-ring  
> before replacing the X selection with the current Emacs kill.
> Is it OK to install it unconditionally, or is it better to guard it  
> with a user option, e.g., save-interprogram-paste-before-kill?
>
>
> --- simple.el.~1.1005.~    2009-08-25 16:44:36.000000000 -0400
> +++ simple.el    2009-08-26 12:15:19.000123000 -0400
> @@ -2819,6 +2819,13 @@ argument should still be a \"useful\" st
>        (list string "yank-handler specified for empty string"))))
>   (if (fboundp 'menu-bar-update-yank-menu)
>       (menu-bar-update-yank-menu string (and replace (car kill- 
> ring))))
> +  (let ((interprogram-paste (and interprogram-paste-function
> +                 (funcall interprogram-paste-function))))
> +    (when interprogram-paste
> +      (if (listp interprogram-paste)
> +        (dolist (s (nreverse interprogram-paste))
> +          (push s kill-ring))
> +        (push interprogram-paste kill-ring))))
>   (if (and replace kill-ring)
>       (setcar kill-ring string)
>     (push string kill-ring)
>
>

Re: kill-new discards current X selection

[Stefan Monnier]

> When I select a word in an xterm and then kill in emacs, then X selection is
> gone forever, replaced with the emacs kill.
> The appended patch prepends the current X selection to kill-ring before
> replacing the X selection with the current Emacs kill.
> Is it OK to install it unconditionally, or is it better to guard it
> with a user option, e.g., save-interprogram-paste-before-kill?

It needs to be guarded, because it can cause a delay in C-k (when the
previous selection owner is non-responsive) and some people find it
unacceptable.  At least that's my recollection of the consensus last
time I suggested it.

BTW, here's the version I use in my own local collection of hacks.


        Stefan


=== modified file 'lisp/simple.el'
--- lisp/simple.el	2009-08-19 08:31:59 +0000
+++ lisp/simple.el	2009-08-21 14:24:38 +0000
@@ -2799,6 +2851,21 @@
 argument is not used by `insert-for-yank'.  However, since Lisp code
 may access and use elements from the kill ring directly, the STRING
 argument should still be a \"useful\" string for such uses."
+  ;; To better pretend that X-selection = head-of-kill-ring, we copy other
+  ;; application's X-selection to the kill-ring.  This comes in handy when
+  ;; you do something like:
+  ;; - copy a piece of text in your web-browser.
+  ;; - have to do some editing (including killing) before you can yank
+  ;;   that text.
+  ;; Note: this piece of code inspired from current-kill.
+  (let ((paste (and interprogram-paste-function
+                    (funcall interprogram-paste-function))))
+    (when paste
+      (let ((interprogram-cut-function nil)
+            (interprogram-paste-function nil))
+        (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)

Re: kill-new discards current X selection

[Sam Steingold]

On Wed, Aug 26, 2009 at 3:28 PM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>> When I select a word in an xterm and then kill in emacs, then X selection is
>> gone forever, replaced with the emacs kill.
>> The appended patch prepends the current X selection to kill-ring before
>> replacing the X selection with the current Emacs kill.
>> Is it OK to install it unconditionally, or is it better to guard it
>> with a user option, e.g., save-interprogram-paste-before-kill?
>
> It needs to be guarded, because it can cause a delay in C-k (when the
> previous selection owner is non-responsive) and some people find it
> unacceptable.  At least that's my recollection of the consensus last
> time I suggested it.

OK, I will.

> BTW, here's the version I use in my own local collection of hacks.
>
> === modified file 'lisp/simple.el'
> --- lisp/simple.el      2009-08-19 08:31:59 +0000
> +++ lisp/simple.el      2009-08-21 14:24:38 +0000
> @@ -2799,6 +2851,21 @@
>  argument is not used by `insert-for-yank'.  However, since Lisp code
>  may access and use elements from the kill ring directly, the STRING
>  argument should still be a \"useful\" string for such uses."
> +  ;; To better pretend that X-selection = head-of-kill-ring, we copy other
> +  ;; application's X-selection to the kill-ring.  This comes in handy when
> +  ;; you do something like:
> +  ;; - copy a piece of text in your web-browser.
> +  ;; - have to do some editing (including killing) before you can yank
> +  ;;   that text.
> +  ;; Note: this piece of code inspired from current-kill.
> +  (let ((paste (and interprogram-paste-function
> +                    (funcall interprogram-paste-function))))
> +    (when paste
> +      (let ((interprogram-cut-function nil)
> +            (interprogram-paste-function nil))
> +        (kill-new paste))))

I think my version is just a little bit more transparent.

> +  ;; The actual kill-new functionality.
> +  (when (equal string (car kill-ring)) (setq replace t))

this seems to be a separate nice feature, similar to bash
HISTCONTROL=ignoredups.
I think it would be a good separate addition, controlled by
kill-ignore-duplicates




-- 
Sam Steingold <http://sds.podval.org>

Re: kill-new discards current X selection

[Stefan Monnier]

>> BTW, here's the version I use in my own local collection of hacks.
>> 
>> === modified file 'lisp/simple.el'
>> --- lisp/simple.el      2009-08-19 08:31:59 +0000
>> +++ lisp/simple.el      2009-08-21 14:24:38 +0000
>> @@ -2799,6 +2851,21 @@
>>  argument is not used by `insert-for-yank'.  However, since Lisp code
>>  may access and use elements from the kill ring directly, the STRING
>>  argument should still be a \"useful\" string for such uses."
>> +  ;; To better pretend that X-selection = head-of-kill-ring, we copy other
>> +  ;; application's X-selection to the kill-ring.  This comes in handy when
>> +  ;; you do something like:
>> +  ;; - copy a piece of text in your web-browser.
>> +  ;; - have to do some editing (including killing) before you can yank
>> +  ;;   that text.
>> +  ;; Note: this piece of code inspired from current-kill.
>> +  (let ((paste (and interprogram-paste-function
>> +                    (funcall interprogram-paste-function))))
>> +    (when paste
>> +      (let ((interprogram-cut-function nil)
>> +            (interprogram-paste-function nil))
>> +        (kill-new paste))))
> I think my version is just a little bit more transparent.

Actually, IIRC I specifically (re)used kill-new to avoid code duplication.

>> +  ;; The actual kill-new functionality.
>> +  (when (equal string (car kill-ring)) (setq replace t))

> this seems to be a separate nice feature, similar to bash
> HISTCONTROL=ignoredups.
> I think it would be a good separate addition, controlled by
> kill-ignore-duplicates

Yes, it's a separate "feature".  I can't remember which use-case this
was designed for, but I remember I added it for one particular situation
where it makes a big difference (not that it doesn't remove all
duplicates, just consecutive duplicates).


        Stefan

Re: kill-new discards current X selection

[David De La Harpe Golden]

Sam Steingold wrote:
> When I select a word in an xterm and then kill in emacs, then X 
> selection is gone forever, replaced with the emacs kill.
> The appended patch prepends the current X selection to kill-ring before 
> replacing the X selection with the current Emacs kill.
> Is it OK to install it unconditionally, or is it better to guard it with 
> a user option, e.g., save-interprogram-paste-before-kill?
> 

I'd certainly like that to be optional if it's going in at all. That's 
not to say it's necessarily a bad feature.  But it's not usual behaviour 
in the slightest.

"the" x selection is also an inaccurate way of looking at things -
if you had turned off x-select-enable-primary and turned on
x-select-enable-clipboard, then killing in emacs wouldn't
(necessarily) nuke the xterm's primary, as killing would
be going to the clipboard.   Of course, since you can't specify
incoming and outgoing behaviour separately (a feature that was however
part of my "giant matrix of every silly selection behaviour possible" 
patch a good while back), you also couldn't pull in primary upon yanking 
with those settings...

OTOH, if you'd set emacs select-active-regions, primary might be gone 
already if you used a region to define what to kill, as that would
cause emacs to send whatever's highlighted onscreen in emacs straight to 
primary (but not clipboard!).