2

I use emacs 24 (OSX) and have a problem with shift-selection. If I select a region with my mouse, the text is highlighted and automaticaly saved on to the kill ring (I can yank it immediately). With shift-selection, the text is highlighted but I have to manualy save the text (M-w) to be able to yank it. Is there any way that shift-selection hightlights the text AND saves it onto the kill ring ?

Thomas
  • 17,016
  • 4
  • 46
  • 70
fxbois
  • 806
  • 9
  • 21

2 Answers2

2

Selecting text with the mouse does not place anything onto the kill ring by default (it copies it to the X clipboard).

There are various ways in which you can customise how Emacs interacts with the clipboard. See:

C-hig (emacs) Cut and Paste RET

Is there any way that shift-selection hightlights the text AND saves it onto the kill ring ?

I'm not sure that there's any way to detect that you've stopped selecting things, but you could perhaps advise handle-shift-selection to set a temporary post-command-hook to run a custom function to place the region in the clipboard (and remove the post-command-hook).

Edit: Hang on, what you describe is exactly what happens for me in Emacs 24.1 on Ubuntu.

If I shift-select some text in Emacs and then middle-click the mouse in any application, I paste the selected text.

Try testing when running emacs -Q

Edit 2: Ah, but you didn't mean the mouse, did you?

How about this?

(defvar my-shift-selection-in-progress nil)
(make-variable-buffer-local 'my-shift-selection-in-progress)

(defadvice handle-shift-selection
  (before my-shift-selection-to-kill-ring-advice)
  "Automatically copy shift-selected text to the kill ring.

If `interprogram-cut-function' is non-nil, also save the text for a window
system cut and paste.

See `my-shift-selection-to-kill-ring'."
  (when (and shift-select-mode
             this-command-keys-shift-translated
             (not my-shift-selection-in-progress))
    (add-hook 'post-command-hook 'my-shift-selection-to-kill-ring nil t)))

(ad-activate 'handle-shift-selection)

(defun my-shift-selection-to-kill-ring ()
  "Post-command callback for my-shift-selection-to-kill-ring-advice."
  (if this-command-keys-shift-translated
      (kill-new (filter-buffer-substring (region-beginning) (region-end))
                my-shift-selection-in-progress)
    (remove-hook 'post-command-hook 'my-shift-selection-to-kill-ring t))
  (setq my-shift-selection-in-progress this-command-keys-shift-translated))
phils
  • 71,335
  • 11
  • 153
  • 198
  • Wouldn't `kill-new` fill the kill-ring up with strings as you select more text? – event_jr Jun 11 '12 at 13:35
  • Not while `my-shift-selection-in-progress`. – phils Jun 11 '12 at 14:05
  • I see. Wouldn't taking the whole region concatenate copies of the region as it grows? Also what if I'm extending the selection towards point-min? – event_jr Jun 11 '12 at 14:08
  • No, it's a *replace* argument, not *append*; there's no concatenation. Try it out if you're not convinced. Bug reports are welcomed, but I've not spotted any issues with this version (save for vaguely wondering whether I should really be retesting `shift-select-mode` again in the post-command function). – phils Jun 11 '12 at 14:19
  • Admittedly, appending/prepending as the region grows would (presumably) be more efficient; but you'd still need to replace whenever the region shrinks, so the worst-case remains the same. The performance seems entirely decent as-is, though, and I rather suspect that shift-selection on genuinely large regions doesn't really happen much. – phils Jun 11 '12 at 14:56
  • I see. I thought the third argument to `kill-new` was to append. This should work then. I don't use shift-selection so never actually ran the code. – event_jr Jun 12 '12 at 02:46
  • Neither do I, actually, but it seemed like an interesting exercise :) – phils Jun 12 '12 at 03:14
0

The problem with "auto-kill from shift-selection" is to determine when the shift-selection ends (at which point you can finally do the kill).

Stefan
  • 27,908
  • 4
  • 53
  • 82