Re: kill-new discards current X selection

[Sam Steingold]

On Wed, Aug 26, 2009 at 3:28 PM, Stefan Monnier<address@hidden> 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>