[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: Sun, 17 Feb 2008 03:38:14 +0000

On 08/02/2008, Stefan Monnier <address@hidden> wrote:
> > Do you mean as a customization telling select-active-regions not to
> > use kill-ring-save but rather its own call to
> > interprogram-cut-function with the locally rebound
> > x-select-enable-clipboard*? Or telling kill-ring-save to not use the
> > kill ring (heh)?
> Not sure how I'd use it, I'd have to look more carefully at the code.
> But maybe it would be a simple var used for let-binding, and not
> a defcustom.

Anyhow, here's a stab at doing it Stefan's way...

Rev 3. patch has an enable-kill-ring, a boolean var that (um) acts at
the core, current-kill and kill-new.  It's not itself a customization,
but specific-situation overrides of it with
active-region-enable-kill-ring and mouse-yank-enable-kill-ring are.
(assumed people would always want to use the kill ring in keyboard and
menu/tool-bar killing/yanking...).

Patch introduces a number of boolean customizations:

;; for "default" (C-w/C-y) killing/yanking
;; override defaults for mouse yanking
;; override defaults for active region propagation to system
;; what was "select-active-regions"
;; override for yank-pop propagations to system.
;; what was "yank-pop-change-selection"
;; override for menu-bar (when menu-enable-clipboard has been called.)
;; for deciding what "system-clipboard" and "system-current-selection"
;; actually mean in X11 terms, for those who dislike recent-X11-style
;; and/or other compat  with other programs that dislike or predate it.

As per comments in this thread and for clarity, I've
de-platform-specialized and renamed
x-select-enable-clipboard/x-select-enable-primary, according to how a
user used to recent-X11-style would perceive them, and tried to use
"selection" to mean "what the user has selected", not "x selection".
Then,  to try to keep everyone happy, there is an extra layer of
indirection to allow you to specify what the de-platform-specialized
variables then actually mean on an X level - i.e. when, when the user
says  "enable-system-clipboard", do they mean primary, clipboard or
cutbuffer, and similarly for "enable-system-current-selection".

This patch doesn't try to do multiple-selection-return - doing it
would mean a bit more of an alteration to

The customization defaults in this patch should produce behaviour
matching or nearly matching (menus may be slightly different) current
default emacs behaviour.   Unlike rev.2, while the full spectrum of
possible historic emacs behaviours should be possible in addition to
the desired new behaviour, it now takes somewhat different
customizations to get them - but customization is clearer.   term/
impls other than x-win are not updated to use the model (but that
should be straightforward in itself, typical platforms only have a
system-clipboard in the first place).

To get the recent-X11-style behaviour from it:

 '(active-region-enable-kill-ring nil)
 '(active-region-enable-system-clipboard nil)
 '(active-region-enable-system-current-selection t)
 '(enable-system-clipboard t)
 '(enable-system-current-selection nil)
 '(menu-bar-enable-system-clipboard t)
 '(menu-bar-enable-system-current-selection nil)
 '(mouse-drag-copy-region nil)
 '(mouse-yank-enable-kill-ring nil)
 '(mouse-yank-enable-system-clipboard nil)
 '(mouse-yank-enable-system-current-selection t)
 '(transient-mark-mode t)
 '(x-system-clipboard-is-x-selection (quote (:clipboard)))
 '(x-system-current-selection-is-x-selection (quote (:primary))))

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

reply via email to

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