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)