emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improving X selection?


From: David De La Harpe Golden
Subject: Re: Improving X selection?
Date: Wed, 17 Oct 2007 00:29:02 +0100

Hi,

Attached please find a stab at adjusting emacs selection interactions
to be comfy for naive users.  Not saying it's the best way for
experienced text-processing emacs X11 users, who might well  _like_
the fact killing interacts with PRIMARY, but this is how I made emacs
"feel" more like other apps, and interact particularly nicely (maybe)
with freedesktop.org compliant ones.

N.B. I can certainly see the attractions of having more
complex/powerful/traditional mouse-highlight and
PRIMARY/SECONDARY/CLIPBOARD and kill-ring interactions for more
advanced users, this was just a stab at making things act like a naive
user might expect, I just present it as one data point - an expanded
and cleaned up X11 selections handling system might want to permit
something like this as one possible configuration in its configuration
space.


Explanation:

0.  Transient mark mode => t . Of course.

1. mouse-drag-copy-region => nil.   You can set this to nil to prevent
the mouse highlight operation insta-copying the region to the kill
ring. To get to the kill ring with the mouse, you have to highlight
with the mouse (setting mark and point and making region active), then
press C-w/M-w to kill.  This obviously makes kill ring interaction
"feel" more like a usual clipboard within emacs, and does away with an
(imo confusing) difference between keyboard highlighting and mouse
highlighting.

2. However, killing still interacts with PRIMARY unless you nullify
interprogram-cut-function and interprogram-paste-function like
mouse-sel mode does, or better, adjust the functions to go to
CLIPBOARD rather than PRIMARY.  So let's do the latter.
By analogy with x-select-enable-clipboard, introduce
x-select-enable-primary to x-select-text and
x-cut-buffer-or-selection-value.   When x-select-enable-primary is nil
and x-select-enable-clipboard is t, then C-w/M-w go to CLIPBOARD, C-y
only pulls from CLIPBOARD (yeah, I'm ignoring cut buffers here).
Richard has just said he _likes_ C-y pulling in primary, but anyway, I
think it should pull in CLIPBOARD and only clipboard, so adjust  too -
the option is there, by enabling x-select-enable-primary, to allow
pulling from PRIMARY.

(Next thought: should the customs be split into incoming and outgoing? :-) )

(BTW, x-select-text has the comment  "address@hidden says
it's not desirable to put kills in the clipboard."  Well. Um.)

3. But now, the mouse highlighted region is not propagated to PRIMARY,
as propagation to selection is currently done by
copy-region-to-kill-ring which calls interprogram-cut-function, and if
mouse-drag-copy-region is nil, that isn't called.

So, to get other-X11-app-like freedesktop.org-like behaviour, you
really need to hook, so that when the mark is active, region becomes
PRIMARY (whether form the keyboard or from the mouse - Observe what
e.g. oowriter or firefox does with keyboard-highlighted (usual
shortuct: shift+arrow-keys) regions - they set PRIMARY, just like when
you highlight with the mouse in them.

Easy enough with a hook calling x-set-selection with
activate-mark-hook (which is also called when the region changes
shape).

4. But then, what about middle-button yanking?  What should that do?
Just insert PRIMARY if it exists, IMHO.   Not that since PRIMARY is
being set by the hook in 3, this also works merrily for emacs-to-emacs
mouseing.

Attachment: dgxselect.el
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]