[Top][All Lists]

[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: Thu, 7 Feb 2008 03:57:17 +0000

I'm sorry about email length (again), but if you haven't yet waded
through my previous emails in this thread yet, please don't bother,
just start on this one.

Rev. 2 of improved X selections attempt attached (patch against recent
emacs CVS HEAD).  Supersedes previously sent patches and associated
writeups in my previous emails in this thread.

(To Tom Horsley:  a part of particular interest for you re multiple
selections is tagged "[TOM HORSLEY]" below.)

This time, patch will (or at least should - if it doesn't, it's a bug)
default to existing emacs behaviours.  Sample customization that makes
emacs with this patch mimic recent-X11-style interaction very closely
is given at the end.  Relevant customization groups: killing, mouse,

Note again some complexity stems from trying to allow for all possible
customizations of existing X11 emacs selection behaviour AND desired
new behaviours.  A ruthless reimplementation supporting only one
recent-X11-style behaviour and/or losing backward-compat would yield
rather simpler-looking code and customizations - but would hardly be
acceptable for people who like all or aspects of existing emacs
selection behaviour (myself included).

Five files are affected in rev. 2:

lisp/w32-vars.el (?!, see below)

Details of changes below - largely a more concise recap of previous
mails, but sorted by file may be easier to take in as a whole.

Meta: shouldn't the interprogram- functions be frame-specific somehow
given multi-tty? the X11 implementations for these functions currently
have an uggy check-if-frame-is-really-X.

Meta: tool-bar and menu-bar cut/paste might benefit from alterations
to go with these changes (but N.B. should still work as before without

*** 1. lisp/w32-vars.el

[Niggle, but would need to be sorted somehow before any merge...]

Not clear on (i) why this file is being loaded in the first place on
my gnu+linux+xorg system, and (ii) not clear on what another
x-select-enable-clipboard is doing in it either: presumably w32
has or should have something like w32-select-enable-clipboard for
customization of its interprogram-[cut|paste]-function implementations,
not screw up the x- ones.

*** 2. lisp/loadup.el

If I place the idle-timer based fix in simple.el, then timer needs to
be loaded before it.  I'm not sure this is safe, the old order
might well have been that way for some reason, but seems to work.

*** 3. lisp/simple.el

Introduced interprogram-highlight-function analogous to
interprogram-cut-function, but for outgoing highlight propagation on
platforms where it makes sense (i.e. X11, mostly, though other terms
could supply implementations if they wanted to provide some X11-like
The value of this function is called by the implementation of

Added idle-timer based implementation of select-active-regions: when
region is active, have an idle timer check the active region for
changes, and use interprogram-highlight-function to propagate out.

Introduced interprogram-lightins-function analogous to
interprogram-paste-function, but for incoming X11-style
highlight/middlebutton insertions on platforms where it makes sense
(i.e. X11, mostly, though other terms could supply implementations if
they wanted to provide some X11-like behaviour).    The value of this
function is called by mouse-yank-at-click when
mouse-yank-at-click-source is lightins (see mouse.el discussion below)

(Note that to actually produce recent-X11-style behaviour, customizations
of [the X11 implementations of] these functions and mouse behaviour,
are necessary - see below mouse.el and x-win.el discussion and the
example at end)

*** 4. lisp/mouse.el

(i) Move deactivate-mark in mouse-drag-track (mouse-1) so that it
happens before initial point move.  This is probably less important
with the idle-timer implementation of select-active-regions (will
emacs ever go idle in the middle of mouse-drag-track?), but still if
the initial point move
happens before the deactivate-mark, there IS a moment when the old
active region has been spuriously deformed.

(ii) Introduce mouse-yank-at-click-source, which allows to customize
whether mouse-yank-at-click (mouse-2) gets the text to be inserted by
using the kill ring yank proper (and thereby perhaps
interprogram-paste-function, and perhaps adding to the kill ring), or
the interprogram-lightins-function, without affecting the kill ring.

(iii) Introduce mouse-save-then-kill-copy-region (mouse-3), which,
analogously to mouse-drag-copy-region for mouse-drag, customizes the
interaction of mouse-save-then-kill with the kill ring.

original behaviour:  single-click save, double-click kill
new behaviour 1:  just adjust active region.
new behavour 2:  adjust active region on single click, double-click
save, triple-click kill.

(point here is that active region adjustment may, depending on
select-active-region, cause propagation to X11 selection(s) without
affecting kill-ring via interprogram-highlight-function, whereas
saving and killing will affect kill-ring and possibly also X11
selection(s) via interprogram-cut-function. So, the new behaviours are
necessary to avoid confusing behaviour of mouse-3 when trying to do

Should possibly also similarly augment mouse-secondary-save-then-kill.

*** 5. lisp/term/x-win.el

This is, perhaps despite appearances, really fairly straightforward:

Supplied X11 implementations of the four (was two) interprogram-*
functions in lisp/simple.el as follows:

interprogram-cut => x-select-text  (revised)
interprogram-paste => x-cut-buffer-or-selection-value  (revised)
interprogram-highlight => x-select-text-for-highlight  (new)
interprogram-lightins => x-cut-buffer-or-selection-value-for-lightins  (new)

As x-select-text and x-select-text-for-highlight are nearly identical,
they are both implemented as wrappers around x-select-text-for-op.

These revised/new functions have an expanded range of possible
Allowed specification of which of the X11 implementations of the
interprogram- functions the X11 PRIMARY and CLIPBOARD selections and
the legacy X Cut Buffer 0 will be involved in.

I didn't bother involving X11 SECONDARY in all this.  It could be done, though
(mouse.el has existing secondary-handling code that is (afaik) neither
hurt nor improved by this patch).

This is done by allowing x-select-enable-clipboard,
x-select-enable-primary and (new) x-select-enable-cutbuffer to take
values other than nil and t: sets of
one or more of cut, paste, highlight, lightins.

nil and t also had to be supported for backward compat, and it was
done "this way round" (rather than specifying for each interprogram-
what selection) also for backward compat.

[TOM HORSLEY] Multiple Selections:

Also added something like Tom Horsley's (cc'd in case not onlist -as
I'm not likely to use the feature, you might want to test if I've got
the behaviour you want right!) desired feature (though different
implementation to fit in with rest of changes...):   As the ability
for interprogram-paste-function implementations to return more than
one value was added last year, add the ability for
x-cut-buffer-or-selection-value to return multiple selections,
customized by boolean x-cut-buffer-or-selection-value-return-multiple,
and choice
If -multiple is nil, then return the "winner", priority determined by -order.
If -multiple is t, then return all available unique selections in
order determined by -order.
N.B. Existing emacs just used "winner" with a fixed order => default
is existing emacs behaviour.  I think the nondefault primary-first
order works better with -return-multiple, FWIW.

(Yes some names here are rather long.  If I could slightly break
transparency of the changes by e.g. removing "-cut-buffer-or" from them,
they'd look much better.)

*** Customization corresponding to recent-X11-style.

The following, starting from an emacs -Q,  makes X11 emacs + this
patch closely follow recent-X11-style: kill-ring should "be"
clipboard, but not primary. (though personally I prefer sort of a
compromise position between this and historic emacs behaviour, but I
doubt my prefs would make good default).

;; cua-mode (or pc-selection-mode) also works fine alongside
;; these settings to further "fit in".
 '(mouse-drag-copy-region nil)
 '(yank-pop-change-selection nil)
 '(mouse-save-then-kill-copy-region nil)
 '(mouse-yank-at-click-source :lightins)
 '(select-active-regions t)
 '(transient-mark-mode t)
 '(x-cut-buffer-or-selection-value-return-multiple nil)
 '(x-select-enable-clipboard (quote (:cut :paste)))
 '(x-select-enable-cutbuffer nil)
 '(x-select-enable-primary (quote (:highlight :lightins))))

Attachment: enhanced-x-selections_rev2.diff
Description: Text Data

reply via email to

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