Re: Improving X selection?

[David De La Harpe Golden]

On 03/02/2008, Richard Stallman <address@hidden> wrote:

> Adding interprogram-highlight-function seems good to me
>
> Your proposed changes in x-win.el are very big;

Well, the delta is bloated partly because of my verbose docstrings for
the extended customizations.  Those should be cut down, I tend
to write too much (I was eager to explain the ramifications of the
different customizations.

It also seemed to make sense to reuse the x-select-text code for
x-select-text-for-highlight, so I made both into wrappers around one
function, x-select-text-for-op parameterised by the "op" i.e. whether
the  function was being called for cutting or highlighting purposes by
cut (x-select-text) or highlight (x-select-text-for-highlight)
wrappers.  That moved some code about, but just to avoid unnecessary
redundancy.

(And there's one more patch touching x-win.el to come, introducing the
multiple-selections return thing that started the thread, and note
that
the already-forwarded
mouse-behaviours-nice-with-select-active-regions.diff  also affects
x-win.el due to introduction of an interprogram-lightins-function that
is to interprogram-highlight-function as interprogram-paste-function
is to interprogram-cut-function)

> what is the purpose?

Well, the abstract purpose remains to make kill ring and active region
interaction with the X11 clipboard and primary selections customizable
to historic emacs defaults - and historic emacs possible
customizations AND recent X11 conventions, without breaking backward
compat.

Regarding x-win.el in particular, the possible values of
x-select-enable-primary and x-select-enable-clipboard were extended to
allow more versatile specification of what selections are involved in
what
interprogram-cut/paste/highlight-function operations, rather than just
all-or-nothing (and thereby somewhat problematic) "nil" and "t".

> Do they change the default behavior?

Depends entirely on defaults chosen for customize variables
x-select-enable-primary and x-select-enable-clipboard (and
x-select-enable-cutbuffer, but, well, does anyone use cut buffers?)

The patch picked new defaults, but only out of last-minute
thoughtlessness on my part (my local tree defaults are the settings I
want to get working): The existing default behaviour (and existing
customisation possibilities to default behaviour) is still possible,
and backward-compat is peserved, some complexity stems from me being
paranoid about keeping it all possible if anything.

> Why do you think there is a problem with select-active-regions?
> Can you present a test case and explain what behavior you think
> ought to be different?
>

Okay, I'll try:

with transient mark mode on, select-active-regions on. a buffer with a
bunch of  text in. Set mark  (C-SPC) somewhere, Move point somewhere
else (with cursor keys).   The active region between the mark and
point is visible on screen as a highlight.

Problem: The primary X11 selection is not updated to reflect the
just-reshaped active region, despite select-active-regions being on.

Why is this a problem?  Because the highlight on the screen will stop
matching the primary X11 selection, so users will get something
unexpected or nothing  when they try to middle-click transfer the
emacs highlight into other applications.

Why does this problem happen?  Because the mark doesn't change if you
only move the point, and if the mark doesn't change, the
select-active-regions callout to set the X11 selection in set-mark
doesn't run.

How did I "fix" it (apart from "badly")? Check if the region is active
on every point move as well as every mark move, and set the X11
selection then too (when select-active-regions is set).

> The hook post-point-motion would be very costly,
> so only a very powerful reason could convince me to install it.

Well, for select-active-regions to work (work: keep active region and
X11 selection synchronised), I didn't see any good way around calling
something
whenever the active region changes shape. And when does the active
region change shape?  When the point or mark moves.  Without updating
when the point moves, it's only doing 1/2 the job.