Selection changes

Selection changes

[Chong Yidong]

I've changed the way Emacs interacts with the X clipboard and selection,
to bring it in line with how other X applications behave.  For most
users, the main visible change is that `kill' and `yank' now interact
with the clipboard.  One advantage of this change is that the
Cut/Copy/Paste menu bar items are just the usual C-w/M-w/C-y commands.

I believe that this change should be pretty much seamless, but let me
know if there is any problems.

Re: Selection changes

[Jeff Clough]

On Wed, 2010-07-14 at 14:08 -0400, Chong Yidong wrote:
> I've changed the way Emacs interacts with the X clipboard and selection,
> to bring it in line with how other X applications behave.  For most
> users, the main visible change is that `kill' and `yank' now interact
> with the clipboard.  One advantage of this change is that the
> Cut/Copy/Paste menu bar items are just the usual C-w/M-w/C-y commands.

Crap.  What's the variable I frob again to turn this off so Emacs stays
away from my clipboard?

> I believe that this change should be pretty much seamless, but let me
> know if there is any problems.

For what it's worth, I like the Emacs kill-ring to be completely
divorced from the X clipboard selection.  This creates two different
"worlds", to be sure, but I kill/yank text in Emacs all day and make
heavy use of jumping around the kill-ring.  The clipboard selection is
much more ephemeral and without such history.  I just tend to use
kill/yank in a different way than copy/paste.

When it's necessary to move text between these worlds, the primary
selection and middle-click are more than enough.

Again, just my personal preference.

Jeff

Re: Selection changes

[Chong Yidong]

Jeff Clough <jeff@chaosphere.com> writes:

> On Wed, 2010-07-14 at 14:08 -0400, Chong Yidong wrote:
>> I've changed the way Emacs interacts with the X clipboard and selection,
>> to bring it in line with how other X applications behave.  For most
>> users, the main visible change is that `kill' and `yank' now interact
>> with the clipboard.  One advantage of this change is that the
>> Cut/Copy/Paste menu bar items are just the usual C-w/M-w/C-y commands.
>
> Crap.  What's the variable I frob again to turn this off so Emacs stays
> away from my clipboard?

x-select-enable-clipboard

> I kill/yank text in Emacs all day and make heavy use of jumping around
> the kill-ring.  The clipboard selection is much more ephemeral and
> without such history.  I just tend to use kill/yank in a different way
> than copy/paste.

Nothing stops you from continuing to do this, if you don't care about
the fact that Emacs is overwriting the clipboard selection (most users
won't care since, as you say, its contents are ephemeral).

Re: Selection changes

[Jeff Clough]

On Wed, 2010-07-14 at 14:53 -0400, Chong Yidong wrote:
> Jeff Clough <jeff@chaosphere.com> writes:
> 
> > On Wed, 2010-07-14 at 14:08 -0400, Chong Yidong wrote:
> >> I've changed the way Emacs interacts with the X clipboard and selection,
> >> to bring it in line with how other X applications behave.  For most
> >> users, the main visible change is that `kill' and `yank' now interact
> >> with the clipboard.  One advantage of this change is that the
> >> Cut/Copy/Paste menu bar items are just the usual C-w/M-w/C-y commands.
> >
> > Crap.  What's the variable I frob again to turn this off so Emacs stays
> > away from my clipboard?
> 
> x-select-enable-clipboard

Thanks.

> > I kill/yank text in Emacs all day and make heavy use of jumping around
> > the kill-ring.  The clipboard selection is much more ephemeral and
> > without such history.  I just tend to use kill/yank in a different way
> > than copy/paste.
> 
> Nothing stops you from continuing to do this, if you don't care about
> the fact that Emacs is overwriting the clipboard selection (most users
> won't care since, as you say, its contents are ephemeral).

Um, but I *do* care.  I don't want Emacs and the clipboard selection to
interact at all.  I certainly don't want a kill in Emacs (which happens
about a thousand times a day) to clobber what's on my clipboard (which I
can never get back).

Thanks again for the reminder on the variable name.

Jeff

Re: Selection changes

[Yann Hodique]

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

> I've changed the way Emacs interacts with the X clipboard and selection,
> to bring it in line with how other X applications behave.  For most
> users, the main visible change is that `kill' and `yank' now interact
> with the clipboard.  One advantage of this change is that the
> Cut/Copy/Paste menu bar items are just the usual C-w/M-w/C-y commands.

> I believe that this change should be pretty much seamless, but let me
> know if there is any problems.

Hi,

I'm a bit confused by those changes. I used to have

--8<---------------cut here---------------start------------->8---
(setq mouse-drag-copy-region nil)
(mouse-sel-mode 1)
--8<---------------cut here---------------end--------------->8---

and was pretty happy with the behavior. Now it seems I cannot retrieve
the same behavior as `mouse-sel-mode' is apparently broken
("mouse-sel-selection-overlay: No overlay corresponding to PRIMARY
selection" whenever I try to select something). Which forces me to (setq
mouse-drag-copy-region t) to be able to select with the mouse, but this
in turn pollutes my kill-ring...

What I'd like to have is:
- mouse selection/middle click working as in any application
  (interacting with X primary selection), but *without* interacting with
  neither kill-ring, nor clipboard
- kill-ring being totally independent of clipboard
- (optionally) dedicated functions to yank/kill from/to
  clipboard/primary/secondary

I don't mind changing my configuration to accommodate the new defaults,
but can't find the relevant information. Any useful pointers to
magic variables?

Thanks a lot,

Yann.

-- 
It is your fate, forgetfulness.  All of the old lessons of life, you lose and 
gain and lose and gain again.

  -- Leto II, the Voice of Dar-es-Balat

Re: Selection changes

[Chong Yidong]

Yann Hodique <yann.hodique@gmail.com> writes:

> I'm a bit confused by those changes. I used to have
>
> (setq mouse-drag-copy-region nil)
> (mouse-sel-mode 1)
>
> and was pretty happy with the behavior. Now it seems I cannot retrieve
> the same behavior as `mouse-sel-mode' is apparently broken
> ("mouse-sel-selection-overlay: No overlay corresponding to PRIMARY
> selection" whenever I try to select something). Which forces me to (setq
> mouse-drag-copy-region t) to be able to select with the mouse, but this
> in turn pollutes my kill-ring...

I think mouse-sel-mode was somewhat bitrotted even prior to this change.
I will take a look over the next few days.

Re: Selection changes

[David De La Harpe Golden]

On 14/07/10 19:08, Chong Yidong wrote:

> I believe that this change should be pretty much seamless, but let me
> know if there is any problems.
>

'fraid the no-zero-length-region change to deactivate-mark, while 
well-intentioned, is wrong - by that stage emacs may have already taken 
ownership of the selection, and pointed it at the buffer.

e.g. try C-SPC C-SPC, move point a few chars, middle click, middle 
click, middle click, Yeuch! Or try making the region nonzero sized then 
zero sized again.

So please remove from deactivate-mark the
(not (eq (region-beginning) (region-end)))
for now - not having it is IMO the lesser of two evils, it's _way_ too 
easy to apparently randomize (well, it's not actually random, but users 
aren't going to appreciate rhat) primary with it there.  At least IMO.

Really, emacs needs to take ownership of the primary selection and set 
it to the buffer /the first time in each region activation that the 
active region becomes nonzero sized/.

Remember when the emacs-level selection val is set to a buffer object, 
the buffer is _lazily_ queried for its point-mark span if/when other X 
clients ask for the selection, so if it manages to stay set to the 
buffer past deactivation of the region you'll have a selection depending 
on where the mark and point are at that time.  Hence freezing off the 
string as the selection in deactivate-mark.

I'm out of "emacs time" for today for actual implementation of a 
proposal for a fix - I'll have time at the weekend if you haven't got to 
it by then...

Re: Selection changes

[Angelo Graziosi]

Chong Yidong wrote:
> I believe that this change should be pretty much seamless, but let me
> know if there is any problems.
>

After these changes something is not working rightly with Copy/Paste. 
Nor on GNU/Linux Kubuntu nor on Cygwin (both GTK build of trunk).

On Kubuntu often it paste the wrong test (both using C-y and mouse-2). 
Only after playing with it some time, it seems to work.

On Cygwin, *usually*, using C-y is slower. If I select some test with 
the mouse then, when I type C-y to paste it, I get 'Mark set' in the 
minibuffer, and the text is pasted only after 5-10 second (the 'clock' 
shows up). Using mouse-2, instead, seems to work fine.

Not always, one can reproduce the above exactly :(.

In both systems I have started Emacs with 'emacs -Q'.

Ciao,
Angelo.

Re: Selection changes

[Richard Stallman]

    I've changed the way Emacs interacts with the X clipboard and selection,
    to bring it in line with how other X applications behave.  For most
    users, the main visible change is that `kill' and `yank' now interact
    with the clipboard.  One advantage of this change is that the
    Cut/Copy/Paste menu bar items are just the usual C-w/M-w/C-y commands.

I have a vague recollection that it worked this way long ago and it
caused problems for users.  That was in the 90s and I don't remember
details.

Re: Selection changes

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I have a vague recollection that it worked this way long ago and it
> caused problems for users.  That was in the 90s and I don't remember
> details.

It's certainly worth trying again though -- 

   (1) I think the emacs infrastructure for handling this stuff has been
   changed quite a bit

   (2) IIRC, one of the main complaints was just speed, and machines/etc
   are _much_ faster now (even your slow laptop ... :)

   (3) I've personally had it enabled for years, with zero problems

IMHO, it really does make using emacs in conjunction with other X apps
much nicer (things "just work"), and is clearly what noobs expect.

-Miles

-- 
Road, n. A strip of land along which one may pass from where it is too
tiresome to be to where it is futile to go.

Re: Selection changes

[David De La Harpe Golden]

On 16/07/10 02:00, Angelo Graziosi wrote:

> Nor on GNU/Linux Kubuntu nor on Cygwin (both GTK build of trunk).
>
> On Kubuntu often it paste the wrong test (both using C-y and mouse-2).

At the moment there is a known issue which will cause the wrong text to 
be pasted in sometimes as per my other recent mail.

Just in case: also note C-y and mouse-2 should now be behaving more like 
C-v and mouse-2 in non-emacs, it will require a more precise 
reproduction recipe to determine if "wrong" is really-wrong or 
correct-but-different-to-prior-defaults behaviour (or right now, the 
known issue).

> On Cygwin, *usually*, using C-y is slower. If I select some test with
> the mouse then, when I type C-y to paste it, I get 'Mark set' in the
> minibuffer, and the text is pasted only after 5-10 second (the 'clock'
> shows up).

You mean you were - starting from "emacs -Q" - selecting some text with 
the mouse, _without_ hitting C-w/M-w to cut/copy it, then successfully 
inserting it with C-y?

If so, that shouldn't have worked at all (!).

...I see the reporter of #6637 appears to have been using cygwin's x11.
In this instance, the problem _might_ not be on emacs' side, especially 
given the long pause you describe: cygwin's x11 server may be doing 
something peculiar in its handling of x11 clipboard and/or primary, 
especially since it probably tries to integrate somehow with the w32 
native clipboard facilities.

Re: Selection changes

[Angelo Graziosi]

On Cygwin, I can confirm all is desribed here [*]. Another recipe, for 
Cygwin, is:

emacs -Q &

double click (mouse-1) on a word, for example 'buffer'. With the down 
arrow go to the bottom of the buffer and then C-y: it takes about 4-5 
second, and the mouse cursor switches to its "please wait" (clock).


On *Kubuntu 10.04* the things are a little different but wrong in any 
case. Following the step described here[*], at point 4) it pastes casual 
text, usually what is found in the clipboard. For example, adding the 
step 0):

0) with your browser, copy a link address with mouse-3 | 'Copy link 
address' menu item.

At step 4), it pastes the link, not the scartch buffer comment!

As described here [*], all seems to work as expected, if one adds

(setq x-select-clipboard-enable nil)

to .emacs file.

Ciao,
Angelo.

---
[*] http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-07/msg00429.html


Il 16/07/2010 3.00, Angelo Graziosi ha scritto:
> Chong Yidong wrote:
>> I believe that this change should be pretty much seamless, but let me
>> know if there is any problems.
>>
>
> After these changes something is not working rightly with Copy/Paste.
> Nor on GNU/Linux Kubuntu nor on Cygwin (both GTK build of trunk).
>
> On Kubuntu often it paste the wrong test (both using C-y and mouse-2).
> Only after playing with it some time, it seems to work.
>
> On Cygwin, *usually*, using C-y is slower. If I select some test with
> the mouse then, when I type C-y to paste it, I get 'Mark set' in the
> minibuffer, and the text is pasted only after 5-10 second (the 'clock'
> shows up). Using mouse-2, instead, seems to work fine.
>
> Not always, one can reproduce the above exactly :(.
>
> In both systems I have started Emacs with 'emacs -Q'.

Re: Selection changes

[David De La Harpe Golden]

On 14/07/10 19:08, Chong Yidong wrote:
> I've changed the way Emacs interacts with the X clipboard and selection,
> to bring it in line with how other X applications behave.


Erk. So... x-select-enable-primary is apparently still on by default.

N.B. that definitely needs to be _off_ for bringing emacs in line with 
other apps.  If it's on, it means C-y inserts primary and pushes primary 
onto the kill ring.

Re: Selection changes

[Miles Bader]

David De La Harpe Golden <david@harpegolden.net> writes:
> N.B. that definitely needs to be _off_ for bringing emacs in line with
> other apps.  If it's on, it means C-y inserts primary and pushes primary
> onto the kill ring.

Why is that bad?

After all absolute consistency in the sense of "do _exactly_ what other
apps do" is not the goal.  The goal is for Emacs to work smoothly and
intuitively with other apps -- and those other apps include those which
use selections rather than the clipboard.

I'm not arguing based on principle, but rather because I've been using
it that way (with x-select-enable-primary set to t) for many years with
many other standard apps of both sorts, and it seems to work almost
perfectly this way.  So I'm very wary of changing it for polemic reasons.

In particular:

  * selecting some text in a cut/past style app, and invoking "copy" in
    that app, should allow the copied text to be pasted in emacs with
    C-y.

  * selecting some text in a selection-using app (e.g. xterm) should
    allow the selected text to be pasted in emacs with C-y.

Thanks,

-Miles

-- 
Bore, n. A person who talks when you wish him to listen.

Re: Selection changes

[David De La Harpe Golden]

On 17/07/10 02:02, Miles Bader wrote:
> David De La Harpe Golden<david@harpegolden.net>  writes:
>> N.B. that definitely needs to be _off_ for bringing emacs in line with
>> other apps.  If it's on, it means C-y inserts primary and pushes primary
>> onto the kill ring.
>
> Why is that bad?
>

Shrug. It's  not what other apps do, and what's more, emacs behaviour 
when both the x-select-enables are turned on at once is particularly 
strange (thanks mostly to x-cut-buffer-or-selection-value's desperate 
attempts to please)

> I'm not arguing based on principle, but rather because I've been using
> it that way (with x-select-enable-primary set to t)
 > for many years with many other standard apps of both sorts,
 > and it seems to work almost perfectly this way.

Perhaps for you - but you, like myself, know what's going on under the 
hood.  To someone who has only used Mac/Windows/fd.o-x11, it's plain 
bizarre.

[Anyway, this is only about what the default should be, you can still 
turn on the option if you like it.]

> In particular:
>
>    * selecting some text in a cut/past style app, and invoking "copy" in
>      that app, should allow the copied text to be pasted in emacs with
>      C-y.
>

Remember that primary is /still set/ by "cut/paste" style apps that set 
clipboard on cut/paste, they still set primary on selecting text.

with both x-select-enables on:

C-y in emacs gives you clipboard for a while, until you select something 
else in emacs, which causes emacs to set and prefer primary, then it 
gives you primary for a bit when you C-y (or the kill ring head), then 
you go "wtf?" and select then C-c again in $app, and you get clipboard 
for a bit when you C-y in emacs, until you select more text, then C-y 
gives you primary, but then you C-v in $app and you still get clipboard, 
but C-y in emacs still gives you primary...

i.e. emacs C-y has magically morphed (as far as the end user is 
concerned) from acting like $app C-v to acting like $app mouse-2.

And then some helpful emacser turns around and tells a newbie "oh just 
turn on cua mode"!  but what cua mode does is make emacs C-v act like
emacs C-y. Since emacs C-y doesn't act like non-emacs C-v, turning on 
cua mode still doesn't make emacs C-v act like non-emacs C-v.


*** So please, turn on one or the other of x-select-enable-primary or
x-select-enable-clipboard by default, not both at once.


>    * selecting some text in a selection-using app (e.g. xterm) should
>      allow the selected text to be pasted in emacs with C-y.

With x-select-enable-primary off but with the mouse-2 rebound, it can 
still be inserted with mouse-2 as in other apps.

xterm itself, while IIRC still maintained, is not typically the terminal
emulator that gets launched when a user clicks "terminal" anymore:
e.g. in the terminal emulator I use (xfce4-terminal),  out of box, 
Shift-Ctrl-C will copy to clipboard and Shift-Ctrl-V will paste from 
clipboard. (Same shortcuts work out-of-box in the KDE terminal, konsole).

Re: Selection changes

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

> with both x-select-enables on:
>
> C-y in emacs gives you clipboard for a while, until you select
> something else in emacs, which causes emacs to set and prefer primary,
> then it gives you primary for a bit when you C-y (or the kill ring
> head), then you go "wtf?" and select then C-c again in $app, and you
> get clipboard for a bit when you C-y in emacs, until you select more
> text, then C-y gives you primary, but then you C-v in $app and you
> still get clipboard, but C-y in emacs still gives you primary...

Yes, with select-active-regions enabled, it is a serious problem if
C-SPC and making an active region messes with the primary.  So, for the
moment, I went ahead and changed x-select-enable-primary to nil, as you
requested.

But I think select-active-regions needs further improvement.  Perhaps
its default behavior should be as follows: for an active region created
using shift-selection or mouse dragging, Emacs supplies the region text
to primary.  When such a region is deactivated, Emacs disowns primary
(as some other apps do, tho not Firefox).  For an active region created
simply with C-SPC, no special x-selection handling should be performed.

We could give select-active-regions a new default value, `shift-select',
which would have the above meaning.

Re: Selection changes

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> But I think select-active-regions needs further improvement.  Perhaps
> its default behavior should be as follows: for an active region created
> using shift-selection or mouse dragging, Emacs supplies the region text
> to primary.  When such a region is deactivated, Emacs disowns primary
> (as some other apps do, tho not Firefox).  For an active region created
> simply with C-SPC, no special x-selection handling should be performed.

I don't like things that make selections magic depending on how they
were selected; it just makes the interface more confusing and
discourages people from learning new commands.

A selection should be a selection, to the greatest extent possible
(there are some exceptions, like shift-selections auto-deselecting, but
that's much less confusing because it's an immediate and visually
obvious effect, and fits people's shift-select muscle-memory).

-miles

-- 
Politeness, n. The most acceptable hypocrisy.

Re: Selection changes

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> I don't like things that make selections magic depending on how they
> were selected; it just makes the interface more confusing and
> discourages people from learning new commands.
>
> A selection should be a selection, to the greatest extent possible
> (there are some exceptions, like shift-selections auto-deselecting, but
> that's much less confusing because it's an immediate and visually
> obvious effect, and fits people's shift-select muscle-memory).

A valid point.  We can give the current system a shot; if ordinary
active regions grabbing the primary selection turns out not to be a
nuisance in practice, that is fine.

Re: Selection changes

[David De La Harpe Golden]

On 17/07/10 03:56, Chong Yidong wrote:
>  So, for the
> moment, I went ahead and changed x-select-enable-primary to nil, as you
> requested.
>

Thanks, sorry for the rant. It's 4:50am, time for bed...

The bad "(not (eq (region-beginning) (region-end)))" check is still 
present in deactivate-mark (~simple.el line 3690) and should just be 
removed, I did [try to] explain the problem with it in a previous mail, 
that's a further source of some  poor behaviour (perhaps 
counterintuitively, but that's lazy stuff for you) that might be related 
to some of your points below.

> But I think select-active-regions needs further improvement.

No doubt...

 > Perhaps
> its default behavior should be as follows: for an active region created
> using shift-selection or mouse dragging, Emacs supplies the region text
> to primary.  When such a region is deactivated, Emacs disowns primary
> (as some other apps do, tho not Firefox).

Hmm. I do rather prefer the freezing off of the region into a string 
selection (line just after the bad check above) when deactivating rather 
than completely disowning - I mean, once you disown, the text won't be 
made available for middle-click insertion anymore and you'll be seeing 
"No primary selection" warnings a lot more.

Don't forget, the bad check mentioned above is negatively impacting 
behaviour in this specific area right now, if you remove the bad check 
line, the freezing off will work properly again.

> For an active region created
> simply with C-SPC, no special x-selection handling should be performed.
>

Well, not immediately owning primary on C-SPC /would/ stop most (all?) 
of the possible zero-length-region annoyances (unlike the "bad check") 
in their tracks, but it might be overkill to not own it at all if 
there's an (efficient) way to make emacs just defer taking ownership 
until the newly active region first becomes nonzero length.

That way, visibly highlighted regions would still act the same 
regardless of wether they were mouse/keyboardA/keyboardB created.

Re: Selection changes

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

> The bad "(not (eq (region-beginning) (region-end)))" check is still
> present in deactivate-mark (~simple.el line 3690) and should just be
> removed, I did [try to] explain the problem with it in a previous
> mail, that's a further source of some  poor behaviour (perhaps
> counterintuitively, but that's lazy stuff for you) that might be
> related to some of your points below.

Let's come up with a proper fix, first.

Re: Selection changes

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> David De La Harpe Golden <david@harpegolden.net> writes:
>
>> The bad "(not (eq (region-beginning) (region-end)))" check is still
>> present in deactivate-mark (~simple.el line 3690) and should just be
>> removed, I did [try to] explain the problem with it in a previous
>> mail, that's a further source of some  poor behaviour (perhaps
>> counterintuitively, but that's lazy stuff for you) that might be
>> related to some of your points below.
>
> Let's come up with a proper fix, first.

To be precise, the check is necessary because otherwise mouse-1 (which
deactivates the mark) destroys the primary selection.

Re: Selection changes

[Wojciech Meyer]

Chong Yidong <cyd@stupidchicken.com> writes:

> David De La Harpe Golden <david@harpegolden.net> writes:
>
>> with both x-select-enables on:
>>
>> C-y in emacs gives you clipboard for a while, until you select
>> something else in emacs, which causes emacs to set and prefer primary,
>> then it gives you primary for a bit when you C-y (or the kill ring
>> head), then you go "wtf?" and select then C-c again in $app, and you
>> get clipboard for a bit when you C-y in emacs, until you select more
>> text, then C-y gives you primary, but then you C-v in $app and you
>> still get clipboard, but C-y in emacs still gives you primary...
>
> Yes, with select-active-regions enabled, it is a serious problem if
> C-SPC and making an active region messes with the primary.  So, for the
> moment, I went ahead and changed x-select-enable-primary to nil, as you
> requested.
>
> But I think select-active-regions needs further improvement.  Perhaps
> its default behavior should be as follows: for an active region created
> using shift-selection or mouse dragging, Emacs supplies the region text
> to primary.  When such a region is deactivated, Emacs disowns primary
> (as some other apps do, tho not Firefox).  For an active region created
> simply with C-SPC, no special x-selection handling should be performed.
>
> We could give select-active-regions a new default value, `shift-select',
> which would have the above meaning.

General idea: how about having a prefix key (like C-M w)?

Next command which is kill or yank will perform operation on a native
clipboard.

Just 2 cents.

Wojciech

Re: Selection changes

[Miles Bader]

Wojciech Meyer <wojciech.meyer@googlemail.com> writes:
> General idea: how about having a prefix key (like C-M w)?
>
> Next command which is kill or yank will perform operation on a native
> clipboard.

No, it should be as integrated as possible.  There's no reason not to do so.

-Miles

-- 
Happiness, n. An agreeable sensation arising from contemplating the misery of
another.

Re: Selection changes

[David De La Harpe Golden]

On 17/07/10 05:13, Chong Yidong wrote:
> Chong Yidong<cyd@stupidchicken.com>  writes:
>
>> David De La Harpe Golden<david@harpegolden.net>  writes:
>>
>>> The bad "(not (eq (region-beginning) (region-end)))" check is still
>>> present in deactivate-mark (~simple.el line 3690) and should just be
>>> removed, I did [try to] explain the problem with it in a previous
>>> mail, that's a further source of some  poor behaviour (perhaps
>>> counterintuitively, but that's lazy stuff for you) that might be
>>> related to some of your points below.
>>
>> Let's come up with a proper fix, first.

Indeed, that would be best. I do still intend to try something there 
over the next day.  In the meantime, here's another stab at showing one 
of the problems with the check, in the form of another example.

> To be precise, the check is necessary because otherwise mouse-1 (which
> deactivates the mark) destroys the primary selection.
>

Note that the check is only run if emacs has already owned the selection
(x-selection-owner-p ...) above it!  So the damage is already done, mostly.

Even if we were to fallback to just disowning the selection instead of 
freezing off the string as the selection /we'd still be wanting to 
remove the check/. I'm vaguely hopeful the below will help make clear why.

Try this:

^ => point location
@ => mouse pointer location, when relevant/known
A B etc => other location refs for instructions.

emacs -Q

| type hello world.

hello world
   A   B  C ^

| Now simulate a "clumsy click"
| (this might take a few attempts to trigger the issue):
| mouse-1-down at A.
| move mouse a little bit, but not enough to
|   create a non-zero-length visible region.
| mouse-1-up

+++ message shown "Mark set"

[Aside: recently every click, clumsy or not, is setting the mark and 
putting it on the mark ring. That sure is cluttering the mark ring]


hello world
   A   B  C
   ^
   @

| move point with cursor key to B.

hello world
   A   B  C
   @   ^

| move mouse to C.

hello world
   A   B  C
       ^  @


| mouse-2-click at C.

hello worllo world
   A      @      ^

| mouse-2-click again

hello worllo worllo world
   A      @      ^     X

| move mouse to X

hello worllo worllo world
   A             ^     X
                       @

| mouse-2-click

hello worllo worllo wollo worllo worllo world
Y A                   @                   ^


| move mouse to Y

hello worllo worllo wollo worllo worllo world
Y A                                       ^
@


| mouse-2-click

hehello worllo worllo wollo worllo worllo world
@ ^

| Blargh.


And note how similar the early parts of that sequence are to someone 
with a slight age-related tremor or similar using the mouse-1 to grossly 
reposition the point, then the keyboard for some fine adjustment.  (and 
the later parts to someone clicking randomly in confusion :-) )



N.B. There's a similar sequence with C-SPC C-SPC if you think just 
catching more "clumsy clicks" is addressing the underlying issue - it 
isn't (though might be independently good).

Re: Selection changes

[Angelo Graziosi]

On the way of changes...

In the menu 'Edit', I read:

[...]
Cut    C-w
Copy  <C-insertchar>
[...]

If I have understood what means 'insertchar', I would suggest:

'Copy   C-INS'

it looks better, I think, or the more symmetric

'Copy   M-w'

Ciao,
Angelo.

PS. '<...-insertchar>' is very ugly and... unattractive!

Re: Selection changes

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

On 17/07/10 05:13, Chong Yidong wrote:
> Chong Yidong<cyd@stupidchicken.com>  writes:
>
>> David De La Harpe Golden<david@harpegolden.net>  writes:
>>
>>> The bad "(not (eq (region-beginning) (region-end)))" check is still
>>> present in deactivate-mark (~simple.el line 3690) and should just be
>>> removed, I did [try to] explain the problem with it in a previous
>>> mail, that's a further source of some  poor behaviour (perhaps
>>> counterintuitively, but that's lazy stuff for you) that might be
>>> related to some of your points below.
>>
>> Let's come up with a proper fix, first.
>
> To be precise, the check is necessary because otherwise mouse-1 (which
> deactivates the mark) destroys the primary selection.
>


Okay, just saw rev. 100841:

Do you still think the remaining zero-length problems (still present in 
certain situations) are worth addressing?

Personally I'm not all that bothered by them, but I've been using an 
emacs with select-active-regions on for some time before any attempt to 
address them, so may have adjusted to avoid gotchas.

Anyway, I did say I'd propose something:

My initial stab wound up fugly, negating the efficiency of the lazy 
buffer query approach, doing buffer-substring ops before every command
to freeze off a copy of the region out of paranoia.

*** Then I hit upon an extra pair of markers to freeze the 
pre-command-execution extent of the region before each command, since 
x-set-selection can also take a cons of markers to lazily query.

It seems to work quite well, and doesn't buffer-substring gratuitously. 
I've yet to convince myself my actual implementation is 100% correct and 
it may be still kind of ugly, but shouldn't be grossly inefficient.

On the plus side, with the patch, C-SPC C-SPC sequences and clumsy 
clicks no longer nuke primary.

Anyway, see attached.  Perhaps not quite suitable for inclusion in its 
current form, but maybe the approach/idea is basically viable?

I have included debugging messages in the patch in its current state: It 
may be useful to split your window to show *Messages* and (setq 
select-active-region-debugging t) with it applied and try some 
selections. Or just confusing.

Other dumb issue: turns out I don't know how to make C code use 
defcustom variables - really, the calls introduced in the command loop 
need to be avoided if at all possible, given where they are, and so 
should also be guarded by !NILP select-active-regions, but apparently 
declaring the variable on the C side is the wrong thing to do.








[-- Attachment #2: select-active-regions_nozerosized_r1.diff --]
[-- Type: text/x-patch, Size: 9655 bytes --]

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2010-07-17 20:21:51 +0000
+++ lisp/simple.el	2010-07-18 16:14:28 +0000
@@ -3667,35 +3667,67 @@
     (signal 'mark-inactive nil)))
 
 (defcustom select-active-regions t
   "If non-nil, an active region automatically becomes the window selection."
   :type 'boolean
   :group 'killing
   :version "24.1")
 
 (declare-function x-selection-owner-p "xselect.c" (&optional selection))
 
+;; internal state tracking vars for select-active-regions
+(defvar select-active-region-deferred nil)
+(defvar select-active-region-frozen nil)
+(defvar select-active-region-frozen-start (make-marker))
+(defvar select-active-region-frozen-end (make-marker))
+
+(defvar select-active-region-debugging nil)
+
+(defun select-active-region-debug (at)
+  (when select-active-region-debugging
+    (message "sar %s: m: %s d: %s f: %s R: %s..%s F: %s..%s"
+             at
+             mark-active
+             select-active-region-deferred
+             select-active-region-frozen
+             (if (and (mark t) mark-active) (region-beginning) "nil")
+             (if (and (mark t) mark-active) (region-end) "nil")
+             (marker-position select-active-region-frozen-start)
+             (marker-position select-active-region-frozen-end))))
+
 ;; Many places set mark-active directly, and several of them failed to also
 ;; run deactivate-mark-hook.  This shorthand should simplify.
 (defsubst deactivate-mark (&optional force)
   "Deactivate the mark by setting `mark-active' to nil.
 Unless FORCE is non-nil, this function does nothing if Transient
 Mark mode is disabled.
 This function also runs `deactivate-mark-hook'."
+  (select-active-region-debug "dea-m 1")
   (when (or transient-mark-mode force)
     ;; Copy the latest region into the primary selection, if desired.
-    (and select-active-regions
-	 mark-active
-	 (display-selections-p)
-	 (x-selection-owner-p 'PRIMARY)
-	 (x-set-selection 'PRIMARY (buffer-substring-no-properties
-				    (region-beginning) (region-end))))
+    (when (and select-active-regions
+	       mark-active
+	       (display-selections-p)
+	       (x-selection-owner-p 'PRIMARY))
+      (if select-active-region-frozen
+          (and (marker-position select-active-region-frozen-start)
+               (marker-position select-active-region-frozen-end)
+               (eq (marker-buffer select-active-region-frozen-start)
+                   (current-buffer))
+               (x-set-selection 'PRIMARY (buffer-substring-no-properties
+                                          select-active-region-frozen-start
+                                          select-active-region-frozen-end)))
+      (x-set-selection 'PRIMARY (buffer-substring-no-properties
+				 (region-beginning) (region-end)))))
+    (select-active-region-debug "dea-m 2")
+    (setq select-active-region-frozen nil) ; well, it is still potentially "frozen", but string-frozen not marker-frozen.
+    (setq select-active-region-deferred nil)
     (if (and (null force)
 	     (or (eq transient-mark-mode 'lambda)
 		 (and (eq (car-safe transient-mark-mode) 'only)
 		      (null (cdr transient-mark-mode)))))
 	;; When deactivating a temporary region, don't change
 	;; `mark-active' or run `deactivate-mark-hook'.
 	(setq transient-mark-mode nil)
       (if (eq (car-safe transient-mark-mode) 'only)
 	  (setq transient-mark-mode (cdr transient-mark-mode)))
       (setq mark-active nil)
@@ -3704,23 +3736,58 @@
 (defun activate-mark ()
   "Activate the mark."
   (when (mark t)
     (setq mark-active t)
     (unless transient-mark-mode
       (setq transient-mark-mode 'lambda))
     (select-active-region)))
 
 (defsubst select-active-region ()
   "Set the PRIMARY X selection if `select-active-regions' is non-nil."
+  (select-active-region-debug "sar 1")
   (and select-active-regions
        (display-selections-p)
-       (x-set-selection 'PRIMARY (current-buffer))))
+       (if (eq (region-beginning) (region-end))
+           (setq select-active-region-deferred t)
+         (progn
+           (setq select-active-region-deferred nil)
+           (setq select-active-region-frozen nil)
+           (x-set-selection 'PRIMARY (current-buffer)))))
+  (select-active-region-debug "sar 2"))
+
+
+(defun select-active-region-precommand ()
+  (select-active-region-debug "pre 1")
+  (when select-active-region-deferred
+    (select-active-region))
+  (when (and select-active-regions
+             mark-active
+             (display-selections-p)
+             (x-selection-owner-p 'PRIMARY))
+    (when (not (eq (region-beginning) (region-end)))
+      (set-marker select-active-region-frozen-start (region-beginning))
+      (set-marker select-active-region-frozen-end (region-end)))
+    (when (not (eq (marker-position select-active-region-frozen-start)
+                   (marker-position select-active-region-frozen-end)))
+      (x-set-selection 'PRIMARY (cons select-active-region-frozen-start
+				      select-active-region-frozen-end))
+      (setq select-active-region-frozen t)))
+  (select-active-region-debug "pre 2"))
+
+
+(defun select-active-region-postcommand ()
+  (select-active-region-debug "post 1")
+  ;; maybe thaw after each command.
+  (when (or select-active-region-deferred select-active-region-frozen)
+    (select-active-region))
+  (select-active-region-debug "post 2"))
+
 
 (defun set-mark (pos)
   "Set this buffer's mark to POS.  Don't use this function!
 That is to say, don't use this function unless you want
 the user to see that the mark has moved, and you want the previous
 mark position to be lost.
 
 Normally, when a new mark is set, the old one should go on the stack.
 This is why most applications should use `push-mark', not `set-mark'.
 

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2010-07-13 10:57:00 +0000
+++ src/keyboard.c	2010-07-18 16:14:28 +0000
@@ -385,20 +385,26 @@
 Lisp_Object Qinput_method_function;
 
 /* When we call Vinput_method_function,
    this holds the echo area message that was just erased.  */
 Lisp_Object Vinput_method_previous_message;
 
 /* Non-nil means deactivate the mark at end of this command.  */
 Lisp_Object Vdeactivate_mark;
 Lisp_Object Qdeactivate_mark;
 
+/* Commands are bracketed with these.
+ */
+Lisp_Object Qselect_active_region_precommand;
+Lisp_Object Qselect_active_region_postcommand;
+
+
 /* Menu bar specified in Lucid Emacs fashion.  */
 
 Lisp_Object Vlucid_menu_bar_dirty_flag;
 Lisp_Object Qrecompute_lucid_menubar, Qactivate_menubar_hook;
 
 Lisp_Object Qecho_area_clear_hook;
 
 /* Hooks to run before and after each command.  */
 Lisp_Object Qpre_command_hook, Vpre_command_hook;
 Lisp_Object Qpost_command_hook, Vpost_command_hook;
@@ -1692,25 +1698,30 @@
 	{
 	  Lisp_Object cmd1;
 	  if (cmd1 = Fcommand_remapping (cmd, Qnil, Qnil), !NILP (cmd1))
 	    cmd = cmd1;
 	}
 
       /* Execute the command.  */
 
       Vthis_command = cmd;
       real_this_command = cmd;
+
+      if (!NILP (current_buffer->mark_active) && !NILP (Vrun_hooks))
+        call0 (Qselect_active_region_precommand);
+
       /* Note that the value cell will never directly contain nil
 	 if the symbol is a local variable.  */
       if (!NILP (Vpre_command_hook) && !NILP (Vrun_hooks))
 	safe_run_hooks (Qpre_command_hook);
 
+
       already_adjusted = 0;
 
       if (NILP (Vthis_command))
 	{
 	  /* nil means key is undefined.  */
 	  Lisp_Object keys = Fvector (i, keybuf);
 	  keys = Fkey_description (keys, Qnil);
 	  bitch_at_user ();
 	  message_with_string ("%s is undefined", keys, 0);
 	  current_kboard->defining_kbd_macro = Qnil;
@@ -1781,20 +1792,22 @@
 	  if (!CONSP (last_command_event))
 	    current_kboard->Vlast_repeatable_command = real_this_command;
 	  cancel_echoing ();
 	  this_command_key_count = 0;
 	  this_command_key_count_reset = 0;
 	  this_single_command_key_start = 0;
 	}
 
       if (!NILP (current_buffer->mark_active) && !NILP (Vrun_hooks))
 	{
+          call0 (Qselect_active_region_postcommand);
+
 	  /* In Emacs 22, setting transient-mark-mode to `only' was a
 	     way of turning it on for just one command.  This usage is
 	     obsolete, but support it anyway.  */
 	  if (EQ (Vtransient_mark_mode, Qidentity))
 	    Vtransient_mark_mode = Qnil;
 	  else if (EQ (Vtransient_mark_mode, Qonly))
 	    Vtransient_mark_mode = Qidentity;
 
 	  if (!NILP (Vdeactivate_mark))
 	    call0 (Qdeactivate_mark);
@@ -12059,20 +12072,26 @@
 
   DEFVAR_LISP ("deactivate-mark", &Vdeactivate_mark,
 	       doc: /* If an editing command sets this to t, deactivate the mark afterward.
 The command loop sets this to nil before each command,
 and tests the value when the command returns.
 Buffer modification stores t in this variable.  */);
   Vdeactivate_mark = Qnil;
   Qdeactivate_mark = intern_c_string ("deactivate-mark");
   staticpro (&Qdeactivate_mark);
 
+  Qselect_active_region_precommand = intern_c_string ("select-active-region-precommand");
+  staticpro (&Qselect_active_region_precommand);
+
+  Qselect_active_region_postcommand = intern_c_string ("select-active-region-postcommand");
+  staticpro (&Qselect_active_region_postcommand);
+
   DEFVAR_LISP ("command-hook-internal", &Vcommand_hook_internal,
 	       doc: /* Temporary storage of `pre-command-hook' or `post-command-hook'.  */);
   Vcommand_hook_internal = Qnil;
 
   DEFVAR_LISP ("pre-command-hook", &Vpre_command_hook,
 	       doc: /* Normal hook run before each command is executed.
 If an unhandled error happens in running this hook,
 the hook value is set to nil, since otherwise the error
 might happen repeatedly and make Emacs nonfunctional.  */);
   Vpre_command_hook = Qnil;

Re: Selection changes

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On 18/07/10 00:49, Angelo Graziosi wrote:
> On the way of changes...
>
> In the menu 'Edit', I read:
>
> [...]
> Cut C-w
> Copy <C-insertchar>
> [...]
>

Sorry, you mean out of box on "emacs -Q" ?
On what platform and emacs version?

C-insertchar seems unlikely, though maybe you mean
with cua-mode enabled (even then I don't get it, though
nor does it show C-x/C-c, though it does change paste to C-v.
Hmm.)


Cut   C-w
Copy  M-w
Paste C-y

is in fact what I see out of box, as attached.

[Of course maybe it was fixed after your report]





[-- Attachment #2: emacs_edit_menu1.png --]
[-- Type: image/png, Size: 24614 bytes --]

Re: Selection changes

[Angelo Graziosi]

Il 18/07/2010 21.28, David De La Harpe Golden ha scritto:
> On 18/07/10 00:49, Angelo Graziosi wrote:
>> On the way of changes...
>>
>> In the menu 'Edit', I read:
>>
>> [...]
>> Cut C-w
>> Copy <C-insertchar>
>> [...]
>>
>
> Sorry, you mean out of box on "emacs -Q" ?
> On what platform and emacs version?

It occurs on Kubuntu 10.04 and Cygwin, *WITH*

(pc-selection-mode t)

in ~/.emacs file :(.

Anyway, I do not see the reasons for which it uses 'Copy <C-insertchar>' 
and not, the better, 'Copy  C-INS' :-O

Usually, on keyboard, I have find: Home, End, PagUp, PagDown and _INS_ 
keys, not 'insertchar'.

As I said, I find '<>', 'insertchar' etc. very ugly!

Omitting (pc-selection-mode t) from ~/.emacs works as you

> Cut C-w
> Copy M-w
> Paste C-y

Ciao,
Angelo.

RE: Selection changes

[Drew Adams]

> Chong Yidong <cyd@stupidchicken.com> writes:
> > But I think select-active-regions needs further 
> > improvement.  Perhaps its default behavior should be as
> > follows: for an active region created using
> > shift-selection or mouse dragging, Emacs supplies the 
> > region text to primary.  When such a region is
> > deactivated, Emacs disowns primary (as some other apps
> > do, tho not Firefox).  For an active region created
> > simply with C-SPC, no special x-selection handling should 
> > be performed.
> 
> I don't like things that make selections magic depending on how they
> were selected; it just makes the interface more confusing and
> discourages people from learning new commands.
> 
> A selection should be a selection, to the greatest extent possible
> (there are some exceptions, like shift-selections auto-deselecting,
> but that's much less confusing because it's an immediate and visually
> obvious effect, and fits people's shift-select muscle-memory).

I agree with Miles about that.

I'll go further, on a different angle.  I disagree with a change to the default
behavior of selection/kill/copy/yank (with the mouse or keyboard).  Period.  

The latest build I have of Emacs is completely broken wrt yanking with mouse-2 -
see bugs 6689, 6694, 6701,....  I have not paid attention to this thread, but I
cannot ignore a blown-away mouse.

I don't know what problem you all think you're trying to fix, but AFAICT nothing
needs fixing wrt select/kill/copy/yank, whether via keys or mouse.  It ain't
broke, so please stop trying to fix it.  I use the kill ring, primary selection,
and secondary selection all the time, and they all work just fine, thank you
very much - both within Emacs and between it and other apps.  Or they did until
recently.

There are so many real bugs that need fixing - many with solutions already
provided.  Why not start there, if you have the time and energy to fiddle?

If you want to provide an optional (opt-in), _alternative_ behavior for
select/kill/copy/yank (mouse or keyboard or both), then fine - go for it.  Bring
that up here as a _proposal_, to be discussed.  No problem.  Normal.

But no such a change should be made to the _default_ behavior.  I cannot
understand how such changes are made willy nilly, without any real discussion.
That's not the way Emacs development should proceed.

When someone does propose a change here, it can be nigh unto impossible to get
any agreement and the final OK for it.  I understand that very well, believe me.
But that does not mean that having commit access is a license to make whatever
changes you like.  And that applies to everyone, or it should.

It's not kosher to avoid full proposal & discussion and just implement whatever
you think is right.  That doesn't respect the community, and it's not good
development practice that leads to a good product.

Just one opinion, of course.

Re: Selection changes

[Chong Yidong]

> The latest build I have of Emacs is completely broken wrt yanking with
> mouse-2 - see bugs 6689, 6694, 6701,....  I have not paid attention to
> this thread, but I cannot ignore a blown-away mouse.

The specific problem you encountered apparently comes from the way the
Windows port emulates a primary selection.  This will need some updating
for the current changes.  This kind of snag is to be expected; the
development sources are not stable releases.  Thanks for the bug report.

Re: Selection changes

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Thu, 22 Jul 2010 18:05:43 -0400
> Cc: 'David De La Harpe Golden' <david@harpegolden.net>, emacs-devel@gnu.org,
> 	'Miles Bader' <miles@gnu.org>
> 
> > The latest build I have of Emacs is completely broken wrt yanking with
> > mouse-2 - see bugs 6689, 6694, 6701,....  I have not paid attention to
> > this thread, but I cannot ignore a blown-away mouse.
> 
> The specific problem you encountered apparently comes from the way the
> Windows port emulates a primary selection.  This will need some updating
> for the current changes.

Could you please describe the changes that were made in this respect?

The NEWS entry says:

    ** Selection changes.

    The way Emacs interacts with the clipboard and primary selection, by
    default, is now similar to other X applications.  In particular, kill
    and yank use the clipboard, in addition to the primary selection.

    *** `select-active-regions' now defaults to t.

    *** `x-select-enable-clipboard' now defaults to t.

    *** `x-select-enable-primary' now defaults to nil.

    *** `mouse-drag-copy-region' now defaults to nil.

    *** `mouse-2' is now bound to `mouse-yank-primary'.

Is the list of default values in this entry all that was modified?
That is, if the user reverts all of these values to their previous
defaults, would she have the previous behavior?  Or were other changes
made as well?  If the latter, could someone please tell where these
changes were made, and in what revno's?

In general, the behavior on MS-Windows does not need to change,
because there's no primary selection on Windows.  Emacs on Windows
emulates the primary selection, but that emulation was never meant to
be a replacement for the "real thing", it was just there to minimize
OS-dependent conditions elsewhere in Emacs sources.

Re: Selection changes

[David De La Harpe Golden]

On 23/07/10 11:32, Eli Zaretskii wrote:

> Is the list of default values in this entry all that was modified?

It's those settings that cause the behaviour changes.   Menu-bar 
bindings were changed too, though not in a manner that would affect w32 
AFAICS.

There were/are various bugfixes arising from problems highlighted by the 
changes, of course.

> That is, if the user reverts all of these values to their previous
> defaults, would she have the previous behavior?

Though remembering the fact the previous defaults were different on 
different platforms - so on w32:
select-active-regions nil
x-select-enable-clipboard t
; x-select-enable-primary nil
mouse-drag-copy-region t
(global-set-key [mouse-2] 'mouse-yank-at-click)

Binding the menu bar items back to their old defaults would be required 
for a technically complete reversion, that would matter mostly on x11 
(the old menu bar used to force use of the clipboard, since the old 
defaults on x11 had x-select-enable-primary t / 
x-select-enable-clipboard nil).

AFAIK the use of rebinding (mouse-2, menu-bar) rather than rewriting the 
existing functions to which they were bound to honour some additional 
customization booleans (as in some earlier iterations of this...) does 
make it impossible to use pure customization theme functionality to 
encapsulate the changes.

 > In general, the behavior on MS-Windows does not need to change,
> because there's no primary selection on Windows.

There is no real primary selection, but that doesn't actually mean the 
default behaviour didn't merit changing on w32 too.  Windows apps do 
_not_ typically overwrite the clipboard upon mere selection of text (nor 
do x11 apps for that matter). "windows has no primary selection" does 
_not_ mean "the windows clipboard can be considered some sort of a 
substitute primary selection that is okay to overwrite willy-nilly".

Yes, some may view the w32 clipboard-eating as a "feature" (and even 
want it expanded to catch all the cases consistently, which would at 
least be consistent - i.e. the proposed "clipboard-active-regions") 
and/or consider making w32 emacs work more like other apps (whether 
other w32 apps, x11 emacs or other x11 apps) a non-goal.  In any case, 
the feature is still available, whether it's on by default or not is a 
different matter.

Re: Selection changes

[Eli Zaretskii]

> Date: Sat, 24 Jul 2010 19:44:13 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: Chong Yidong <cyd@stupidchicken.com>, drew.adams@oracle.com, 
>  emacs-devel@gnu.org, miles@gnu.org
> 
> > Is the list of default values in this entry all that was modified?
> 
> It's those settings that cause the behaviour changes.   Menu-bar 
> bindings were changed too, though not in a manner that would affect w32 
> AFAICS.
> 
> There were/are various bugfixes arising from problems highlighted by the 
> changes, of course.

Thanks.

> Windows apps do _not_ typically overwrite the clipboard upon mere
> selection of text

Did Emacs on Windows really do that before these changes?  I thought
it didn't.

Re: Selection changes

[David De La Harpe Golden]

On 24/07/10 21:28, Eli Zaretskii wrote:

>
>> Windows apps do _not_ typically overwrite the clipboard upon mere
>> selection of text
>
> Did Emacs on Windows really do that before these changes?  I thought
> it didn't.

Yes - though dependent on whether you used mouse or keyboard to select...

With mixed-mouse-keyboard established regions possible (shift-extending 
an initially mouse-selected region has worked for some time, 
mouse-extending an initally keyboard-selected region could be made 
work*), there isn't a clean division either.

So, hence the (still hypothetical) "clipboard-active-regions": it would 
be for people who want the active region consistently put to the 
clipboard whether the selection was established by mouse or keyboard or 
both. People who want mouse to go to the clipboard but not keyboard 
could turn on mouse-drag-copy-region and leave clipboard-active-regions 
turned off.

* You may _think_ it works already (emacs' mouse-3), but currently that 
also side-effects, you can't _just_ mouse-extend the region like other 
apps' shift-mouse-1. (as per some discussion under #6701, though it 
properly belongs in a separate ticket).

Re: Selection changes

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

On 24/07/10 19:44, David De La Harpe Golden wrote:

> AFAIK the use of rebinding (mouse-2, menu-bar) rather than rewriting the
> existing functions to which they were bound to honour some additional
> customization booleans (as in some earlier iterations of this...) does
> make it impossible to use pure customization theme functionality to
> encapsulate the changes.
>

Perhaps reverting the rebinding of mouse-2, but then expanding 
mouse-yank-at-click to honour a boolean customization
mouse-yank-selection-only would be best?

This would certainly simplify instructing users on how to switch between 
the old and new behaviours (and I guess we can expect more tickets in 
the tracker in that area): it becomes possible to switch the behaviours 
solely by changing a small set of all-boolean customizations.

Thhis also means other bindings to mouse-yank-at-click (such as in the 
fringes, or done by 3rd party apps or end users) get the behaviour.

(*apart from the menu, though maybe users most likely to want the 
"classic" behaviour are least likely to be heavy menu users)

[-- Attachment #2: mouseyank_selonly.diff --]
[-- Type: text/x-patch, Size: 2763 bytes --]

=== modified file 'lisp/mouse.el'
--- lisp/mouse.el	2010-07-17 20:21:51 +0000
+++ lisp/mouse.el	2010-07-25 16:27:46 +0000
@@ -47,6 +47,16 @@
   :version "24.1"
   :group 'mouse)
 
+(defcustom mouse-yank-selection-only t
+  "If non-nil, mouse yank inserts the current selection only.
+
+If nil, then the text that is inserted is the same as that which
+a keyboard `yank' would insert, which itself varies according to
+`x-select-enable-primary' and `x-select-enable-clipboard'"
+  :type 'boolean
+  :version "24.1"
+  :group 'mouse)
+
 (defcustom mouse-1-click-follows-link 450
   "Non-nil means that clicking Mouse-1 on a link follows the link.
 
@@ -1247,25 +1257,30 @@
 		     (max (point) click-posn)))))
 
 (defun mouse-yank-at-click (click arg)
-  "Insert the last stretch of killed text at the position clicked on.
+  "Insert the last stretch of killed  text at the position clicked on.
 Also move point to one end of the text thus inserted (normally the end),
 and set mark at the beginning.
 Prefix arguments are interpreted as with \\[yank].
+If `mouse-yank-selection-only' is non-nil, delegate click to
+`mouse-yank-primary' (arg ignored in that case).
 If `mouse-yank-at-point' is non-nil, insert at point
 regardless of where you click.
 If `select-active-regions' is non-nil, the mark is deactivated
 before inserting the text."
   (interactive "e\nP")
   ;; Give temporary modes such as isearch a chance to turn off.
-  (run-hooks 'mouse-leave-buffer-hook)
-  (when select-active-regions
-    ;; Without this, confusing things happen upon e.g. inserting into
-    ;; the middle of an active region.
-    (deactivate-mark))
-  (or mouse-yank-at-point (mouse-set-point click))
-  (setq this-command 'yank)
-  (setq mouse-selection-click-count 0)
-  (yank arg))
+  (if mouse-yank-selection-only
+      (mouse-yank-primary click)
+    (progn
+      (run-hooks 'mouse-leave-buffer-hook)
+      (when select-active-regions
+        ;; Without this, confusing things happen upon e.g. inserting into
+        ;; the middle of an active region.
+        (deactivate-mark))
+      (or mouse-yank-at-point (mouse-set-point click))
+      (setq this-command 'yank)
+      (setq mouse-selection-click-count 0)
+      (yank arg))))
 
 (defun mouse-yank-primary (click)
   "Insert the primary selection at the position clicked on.
@@ -2441,7 +2456,7 @@
 (global-set-key [left-fringe mouse-1]	'mouse-set-point)
 (global-set-key [right-fringe mouse-1]	'mouse-set-point)
 
-(global-set-key [mouse-2]	'mouse-yank-primary)
+(global-set-key [mouse-2]	'mouse-yank-at-click)
 ;; Allow yanking also when the corresponding cursor is "in the fringe".
 (global-set-key [right-fringe mouse-2] 'mouse-yank-at-click)
 (global-set-key [left-fringe mouse-2] 'mouse-yank-at-click)

Selection changes

[Chong Yidong]

I've updated the X selection code to provide support for clipboard
managers (plus some standards compliance bits like the MULTIPLE target).

It seems to work well with Gnome's minimalist clipboard manager; the
clipboard is no longer lost when deleting a frame or exiting Emacs.
Help with testing on other environments would be much appreciated, and
let me know if you experience any funky behavior.

Saving is done by the function x-clipboard-manager-save, run from
delete-frame-functions and kill-emacs-hook (though I'm considering
making this internal instead of using hooks).  The other ports should be
unaffected by these changes.

Re: Selection changes

[David De La Harpe Golden]

On 27/05/11 17:25, Chong Yidong wrote:
> I've updated the X selection code to provide support for clipboard
> managers (plus some standards compliance bits like the MULTIPLE target).

Cool.

> Help with testing on other environments would be much appreciated,
> and let me know if you experience any funky behavior.

No problems visible in the xfce4 case:

Note that an xfce4-settings package 4.8.2 with the revised gnome-like 
minimalist clipboard manager as discussed in earlier thread was released 
some days ago, and appears to have hit both Debian/unstable and Arch by 
now.  Taylor, you may want to upgrade to it if you haven't already, it 
should fix the emacs slowdown you were experiencing under xfce.

Re: Selection changes

[Andreas Röhler]

Am 27.05.2011 18:25, schrieb Chong Yidong:
> I've updated the X selection code to provide support for clipboard
> managers (plus some standards compliance bits like the MULTIPLE target).
>
> It seems to work well with Gnome's minimalist clipboard manager; the
> clipboard is no longer lost when deleting a frame or exiting Emacs.
> Help with testing on other environments would be much appreciated, and
> let me know if you experience any funky behavior.
>
> Saving is done by the function x-clipboard-manager-save, run from
> delete-frame-functions and kill-emacs-hook (though I'm considering
> making this internal instead of using hooks).  The other ports should be
> unaffected by these changes.
>
>

Hi,

at a first glance yank and yank-pop work fine also from clipboard on 
Suse11.4, KDE4

GNU Emacs 24.0.50.1 (i686-suse-linux-gnu, X toolkit, Xaw3d scroll bars) 
of 2011-05-28

Please tell if you want specific tests to be done.

Best regards,

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/components-python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/

Re: Selection changes

[Taylor Venable]

On Sat, May 28, 2011 at 00:13, David De La Harpe Golden
<david@harpegolden.net> wrote:
> On 27/05/11 17:25, Chong Yidong wrote:
>>
>> I've updated the X selection code to provide support for clipboard
>> managers (plus some standards compliance bits like the MULTIPLE target).
>
> Cool.
>
>> Help with testing on other environments would be much appreciated,
>> and let me know if you experience any funky behavior.
>
> No problems visible in the xfce4 case:
>
> Note that an xfce4-settings package 4.8.2 with the revised gnome-like
> minimalist clipboard manager as discussed in earlier thread was released
> some days ago, and appears to have hit both Debian/unstable and Arch by now.
>  Taylor, you may want to upgrade to it if you haven't already, it should fix
> the emacs slowdown you were experiencing under xfce.

Hi, just got back from a two-week holiday and tried out the 4.8.2 XFCE
settings manager with a new build of Emacs trunk (bzr revno 104439).
It works great, blazing fast compared to how it used to be. And using
the little clipboard panel widget I can see that the stuff I kill from
Emacs is making it into XFCE's clipboard manager, and is still present
after Emacs is closed. Great thanks, everyone!

-- 
Taylor C. Venable
http://metasyntax.net/