Selection changes in revno 100822

Selection changes in revno 100822

[Eli Zaretskii]

I'm studying the changes in how selections behave that were made in
revno 100822, and I have a couple of questions:

  . Why was mouse-drag-copy-region changed to default to nil?  This
    variable doesn't seem to be related to selections, but rather to
    the kill ring.

  . The change in binding mouse-2 to mouse-yank-primary instead of
    mouse-yank-at-point, in addition to referencing only the primary
    selection, means one more change: mouse-2 no longer yanks the last
    kill, except through the primary selection.  Is this change in
    behavior intentional, and if so, what is the reason behind this
    change?

Re: Selection changes in revno 100822

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

Thanks for looking through the changes.

>   . Why was mouse-drag-copy-region changed to default to nil?  This
>     variable doesn't seem to be related to selections, but rather to
>     the kill ring.

IIRC, this was part of the attempt to cut down on the special casing
involved in mouse drags.  It is not consistent with shift-selection, for
instance.

If it's desired to add selections to the kill ring, I think it ought to
be done uniformly; shift-selection should do the same.

> . The change in binding mouse-2 to mouse-yank-primary instead of
>   mouse-yank-at-point, in addition to referencing only the primary
>   selection, means one more change: mouse-2 no longer yanks the last
>   kill, except through the primary selection.  Is this change in
>   behavior intentional, and if so, what is the reason behind this
>   change?

I assume you mean mouse-yank-at-click.  The change is intentional.  The
standard behavior of other X applications is for mouse-2 to insert
primary.  mouse-yank-at-click calls yank, but since
x-select-enable-primary is now nil, that does not insert primary.

We could change mouse-yank-primary so that it calls yank if no primary
selection exists.  But maybe that is too confusing.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 13 Aug 2010 21:08:51 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Thanks for looking through the changes.
> 
> >   . Why was mouse-drag-copy-region changed to default to nil?  This
> >     variable doesn't seem to be related to selections, but rather to
> >     the kill ring.
> 
> IIRC, this was part of the attempt to cut down on the special casing
> involved in mouse drags.  It is not consistent with shift-selection, for
> instance.

Perhaps we should solve this inconsistency the other way around: have
shift-selected text be copied (under control of the same variable).
But that is unrelated to the main issue of this thread; I personally
have no problems with the new default.

> > . The change in binding mouse-2 to mouse-yank-primary instead of
> >   mouse-yank-at-point, in addition to referencing only the primary
> >   selection, means one more change: mouse-2 no longer yanks the last
> >   kill, except through the primary selection.  Is this change in
> >   behavior intentional, and if so, what is the reason behind this
> >   change?
> 
> I assume you mean mouse-yank-at-click.

Yes, sorry.

> The change is intentional.  The
> standard behavior of other X applications is for mouse-2 to insert
> primary.  mouse-yank-at-click calls yank, but since
> x-select-enable-primary is now nil, that does not insert primary.

I'm utterly confused now.  The doc string of x-select-enable-primary
says:

  Non-nil means cutting and pasting uses the primary selection.

According to this, the value of nil, the current default, means
"cutting and pasting do NOT use the primary selection", right?

But OTOH, the NEWS entry says something contradictory:

  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.

The last sentence seems to say that kill and yank still do use the
primary selection, and _in_addition_ also use the clipboard.  If
that's the intent of this text, then it seems to be in contradiction
with the new default of x-select-enable-primary.

OTTH (On The Third Hand), mouse-2 is one way of pasting (yanking) text
that was cut (killed) elsewhere.  And the new binding of mouse-2 to
mouse-yank-primary _does_ insert text from the primary selection,
albeit by a different way.  IOW, mouse-2 works _against_ the value of
x-select-enable-primary.  It also seems to be in contradiction with
the NEWS entry, in that it doesn't access the clipboard (unless I'm
missing something).

How to reconcile these apparent contradictions?  What exactly is the
role of x-select-enable-primary, if Emacs does not behave according to
its value and its advertised doc string?

Do we still want to have kill/yank and cut/paste be largely synonyms?
If so, they are now a tad less synonyms, so it seems, as at least one
commonly used command does paste, but does not yank.

Please also note that x-select-enable-primary exists only on X, but
the changes we are discussing affect all builds, which just adds to
confusion on those builds that do not use X.  See below for one such
example.

> We could change mouse-yank-primary so that it calls yank if no primary
> selection exists.  But maybe that is too confusing.

This is directly relevant to the issue at (my) hand: how to restore
the expected behavior of selections on Windows.  If it is okay to call
`yank' when there's no primary selection, then that's one way of
fixing the bug on Windows.  But then note that `yank' does not only
insert text, it also does other non-trivial things to the kill ring
etc.; so if the primary selection _does_ exist, all those things won't
be done.  This is unlike the old code, which accessed the selection
from inside `yank', and then treated it in the same way as if it came
from the kill ring.

An alternative way of fixing the bug on Windows would be to modify the
Windows implementation of x-get-selection to get the text from the
clipboard if the (emulated) primary selection does not exist.

Which of these ways is the best one, depends on clearing up the above
confusions.  You say "maybe [calling yank] is too confusing" -- what
kind of confusion do you envision here?

One other issue we should consider IMO is what is the semantics of
mouse-2 in sessions that support the mouse, but cannot access
selections.  One such example is a TTY with a GPM mouse.  I don't have
access to such a build of Emacs, but I'm quite sure mouse-2 there will
either do nothing or signal an error.  That's hardly a good thing,
because previously it would yank from the kill ring.

Thanks in advance for helping me become less confused.

Re: Selection changes in revno 100822

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Perhaps we should solve this inconsistency the other way around: have
> shift-selected text be copied (under control of the same variable).

But, then shift-selected text would be inconsistent with other methods of
selection, which would be an even worse inconsistency...

-Miles

-- 
Ocean, n. A body of water covering seven-tenths of a world designed for Man -
who has no gills.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 14 Aug 2010 17:24:05 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Perhaps we should solve this inconsistency the other way around: have
> > shift-selected text be copied (under control of the same variable).
> 
> But, then shift-selected text would be inconsistent with other methods of
> selection

Which "other methods" are those?

Re: Selection changes in revno 100822

[Miles Bader]

On Sat, Aug 14, 2010 at 6:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > Perhaps we should solve this inconsistency the other way around: have
>> > shift-selected text be copied (under control of the same variable).
>>
>> But, then shift-selected text would be inconsistent with other methods of
>> selection
>
> Which "other methods" are those?

The usual ones, e.g., "C-@ <movement>"

-miles

-- 
Do not taunt Happy Fun Ball.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 14 Aug 2010 21:16:33 +0900
> Cc: emacs-devel@gnu.org
> 
> On Sat, Aug 14, 2010 at 6:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> > Perhaps we should solve this inconsistency the other way around: have
> >> > shift-selected text be copied (under control of the same variable).
> >>
> >> But, then shift-selected text would be inconsistent with other methods of
> >> selection
> >
> > Which "other methods" are those?
> 
> The usual ones, e.g., "C-@ <movement>"

Given Jan's clarifications, doesn't Emacs on X put any selected text
in the primary selection, no matter how it was selected?

Re: Selection changes in revno 100822

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> >> But, then shift-selected text would be inconsistent with other methods of
>> >> selection
>> >
>> > Which "other methods" are those?
>> 
>> The usual ones, e.g., "C-@ <movement>"
>
> Given Jan's clarifications, doesn't Emacs on X put any selected text
> in the primary selection, no matter how it was selected?

No, if you select text with "C-@ <movement", it doesn't (you have to do
"C-w" to get it in the primary), though now that I test it,
"shift selected" text _does_ get put in the primary (lame!).

Sometimes I think this stuff is just completely random...

-Miles

-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 14 Aug 2010 21:35:15 +0900
> 
> > Given Jan's clarifications, doesn't Emacs on X put any selected text
> > in the primary selection, no matter how it was selected?
> 
> No, if you select text with "C-@ <movement", it doesn't (you have to do
> "C-w" to get it in the primary)

The last part, about C-w, is with x-select-enable-primary non-nil,
right?  With the default nil value, IIUC, C-w should _not_ put text
into primary, just into the clipboard.  That's what I understand from
Jan's explanations.

> though now that I test it, "shift selected" text _does_ get put in
> the primary (lame!).

Why ``lame''?  Selections with C-SPC+movement and with Shift+movement
are different, so why expect them to behave the same.  I think
shift-selected text is conceptually like mouse-selected text.  Do you
expect mouse-selected text also not set the primary selection?

> Sometimes I think this stuff is just completely random...

I know the feeling ;-)

Re: Selection changes in revno 100822

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> No, if you select text with "C-@ <movement", it doesn't (you have to do
>> "C-w" to get it in the primary)
>
> The last part, about C-w, is with x-select-enable-primary non-nil,
> right?  With the default nil value, IIUC, C-w should _not_ put text
> into primary, just into the clipboard.  That's what I understand from
> Jan's explanations.

It's with "emacs -Q"

>> though now that I test it, "shift selected" text _does_ get put in
>> the primary (lame!).
>
> Why ``lame''?  Selections with C-SPC+movement and with Shift+movement
> are different, so why expect them to behave the same.

They should not be different.  To a user, they're both "selection", and
every pointless difference is just grounds for confusion.  The user
should be able to use whichever he find convenient (or both ... I do)
without weird subtle differences. 

> I think shift-selected text is conceptually like mouse-selected text.
> Do you expect mouse-selected text also not set the primary selection?

I'd be fine with that, though I imagine the same drive for
"compatibility with other apps" that started the current round of
mucking-about would resist that solution.

Mouse-Selection has always been "kind of weird" in Emacs (compared to
keyboard selection); I don't think that's good, but I think it's more
acceptable than subtle inconsistencies between keyboard selection
methods.

Of course, perhaps the best solution of all, would be to have _all_
selections available as primary (including "C-@ <movement>"
selections).  That would give both consistency within emacs, and with
other apps.

>> Sometimes I think this stuff is just completely random...
>
> I know the feeling ;-)

-Miles

-- 
Discriminate, v.i. To note the particulars in which one person or thing is,
if possible, more objectionable than another.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 14 Aug 2010 22:23:38 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> No, if you select text with "C-@ <movement", it doesn't (you have to do
> >> "C-w" to get it in the primary)
> >
> > The last part, about C-w, is with x-select-enable-primary non-nil,
> > right?  With the default nil value, IIUC, C-w should _not_ put text
> > into primary, just into the clipboard.  That's what I understand from
> > Jan's explanations.
> 
> It's with "emacs -Q"

Then it sounds like I misunderstood Jan, or maybe some other factor
(transient-mark-mode?) is at work here.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 14/08/10 14:27, Eli Zaretskii wrote:
>> From: Miles Bader<miles@gnu.org>
>> Date: Sat, 14 Aug 2010 22:23:38 +0900
>>
>> Eli Zaretskii<eliz@gnu.org>  writes:
>>>> No, if you select text with "C-@<movement", it doesn't (you have to do
>>>> "C-w" to get it in the primary)
>>>
>>> The last part, about C-w, is with x-select-enable-primary non-nil,
>>> right?  With the default nil value, IIUC, C-w should _not_ put text
>>> into primary, just into the clipboard.  That's what I understand from
>>> Jan's explanations.
>>
>> It's with "emacs -Q"
>
> Then it sounds like I misunderstood Jan, or maybe some other factor
> (transient-mark-mode?) is at work here.
>

That would be Chong Yidong's third way "select-active-regions => lazy" 
kicking in I think.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 14:32:18 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: Miles Bader <miles@gnu.org>, emacs-devel@gnu.org
> 
> On 14/08/10 14:27, Eli Zaretskii wrote:
> >> From: Miles Bader<miles@gnu.org>
> >> Date: Sat, 14 Aug 2010 22:23:38 +0900
> >>
> >> Eli Zaretskii<eliz@gnu.org>  writes:
> >>>> No, if you select text with "C-@<movement", it doesn't (you have to do
> >>>> "C-w" to get it in the primary)
> >>>
> >>> The last part, about C-w, is with x-select-enable-primary non-nil,
> >>> right?  With the default nil value, IIUC, C-w should _not_ put text
> >>> into primary, just into the clipboard.  That's what I understand from
> >>> Jan's explanations.
> >>
> >> It's with "emacs -Q"
> >
> > Then it sounds like I misunderstood Jan, or maybe some other factor
> > (transient-mark-mode?) is at work here.
> >
> 
> That would be Chong Yidong's third way "select-active-regions => lazy" 
> kicking in I think.

Does that mean that x-select-enable-primary being nil is only
effective (in preventing setting the primary selection) when
select-active-regions is nil?

Re: Selection changes in revno 100822

[Kenichi Handa]

In article <871va12uqt.fsf@catnip.gol.com>, Miles Bader <miles@gnu.org> writes:
> Of course, perhaps the best solution of all, would be to have _all_
> selections available as primary (including "C-@ <movement>"
> selections).  That would give both consistency within emacs, and with
> other apps.

I agree with that.

---
Kenichi Handa
handa@m17n.org

Re: Selection changes in revno 100822

[Jan Djärv]

Eli Zaretskii skrev 2010-08-14 10.00:

> I'm utterly confused now.  The doc string of x-select-enable-primary
> says:
>
>    Non-nil means cutting and pasting uses the primary selection.
>
> According to this, the value of nil, the current default, means
> "cutting and pasting do NOT use the primary selection", right?
>
> But OTOH, the NEWS entry says something contradictory:
>
>    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.
>
> The last sentence seems to say that kill and yank still do use the
> primary selection, and _in_addition_ also use the clipboard.  If
> that's the intent of this text, then it seems to be in contradiction
> with the new default of x-select-enable-primary.

The name is bad.  The way other X apps doit is that selected text (i.e. just 
selected, not cut/copied) goes to PRIMARY.
Then when you cut/copy, it goes to CLIPBOARD also.

So the name x-select-enable-primary is really x-cut/copy-into-primary AFAIK.

>
> One other issue we should consider IMO is what is the semantics of
> mouse-2 in sessions that support the mouse, but cannot access
> selections.  One such example is a TTY with a GPM mouse.  I don't have
> access to such a build of Emacs, but I'm quite sure mouse-2 there will
> either do nothing or signal an error.  That's hardly a good thing,
> because previously it would yank from the kill ring.
>

Maybe Emacs should use some internal notion of PRIMARY on those platforms
where it don't exist.  That way select and mouse-2 selects and insterts text
as on X.  But without touching the kill ring.

> Thanks in advance for helping me become less confused.

It is very confusing.  There are special cases depending on how the selection 
was made, and then badly named variables increase the confusion.  Not to 
mention trying to handle multiple platforms with differing capabilities.

	Jan D.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 11:46:53 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
> > I'm utterly confused now.  The doc string of x-select-enable-primary
> > says:
> >
> >    Non-nil means cutting and pasting uses the primary selection.
> >
> > According to this, the value of nil, the current default, means
> > "cutting and pasting do NOT use the primary selection", right?
> >
> > But OTOH, the NEWS entry says something contradictory:
> >
> >    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.
> >
> > The last sentence seems to say that kill and yank still do use the
> > primary selection, and _in_addition_ also use the clipboard.  If
> > that's the intent of this text, then it seems to be in contradiction
> > with the new default of x-select-enable-primary.
> 
> The name is bad.  The way other X apps doit is that selected text (i.e. just 
> selected, not cut/copied) goes to PRIMARY.
> Then when you cut/copy, it goes to CLIPBOARD also.
> 
> So the name x-select-enable-primary is really x-cut/copy-into-primary AFAIK.

Thanks, this clears up quite a bit of the confusion.  So would it be
correct to modify the doc string of x-select-enable-primary to say
this:

   Non-nil means cutting text sets the primary selection.
   When the value is nil, the primary selection is still set by
   selecting the text.

and change the NEWS entry to say this:

    In particular, kill and yank use the clipboard, while the primary
    selection is by default set as soon as text is selected, but not
    when text is killed.

?

> > One other issue we should consider IMO is what is the semantics of
> > mouse-2 in sessions that support the mouse, but cannot access
> > selections.  One such example is a TTY with a GPM mouse.  I don't have
> > access to such a build of Emacs, but I'm quite sure mouse-2 there will
> > either do nothing or signal an error.  That's hardly a good thing,
> > because previously it would yank from the kill ring.
> >
> 
> Maybe Emacs should use some internal notion of PRIMARY on those platforms
> where it don't exist.  That way select and mouse-2 selects and insterts text
> as on X.  But without touching the kill ring.

Why is it important not to touch the kill ring?

> > Thanks in advance for helping me become less confused.
> 
> It is very confusing.  There are special cases depending on how the selection 
> was made, and then badly named variables increase the confusion.  Not to 
> mention trying to handle multiple platforms with differing capabilities.

It seems to me that on platforms that have only one selection (the
clipboard), selecting text should do nothing by default, while cutting
should set the clipboard.  And there should be a variable to
optionally set the clipboard when the text is selected.  (Do we
already have such a variable?)  Do you agree?

Re: Selection changes in revno 100822

[Jan Djärv]

Eli Zaretskii skrev 2010-08-14 13.20:
>> So the name x-select-enable-primary is really x-cut/copy-into-primary AFAIK.
>
> Thanks, this clears up quite a bit of the confusion.  So would it be
> correct to modify the doc string of x-select-enable-primary to say
> this:
>
>     Non-nil means cutting text sets the primary selection.
>     When the value is nil, the primary selection is still set by
>     selecting the text.
>
> and change the NEWS entry to say this:
>
>      In particular, kill and yank use the clipboard, while the primary
>      selection is by default set as soon as text is selected, but not
>      when text is killed.
>
> ?

I think shift selection and setting point and mark is different, i.e. the 
latter does not put text in PRIMARY.  IMHO it should.

>> Maybe Emacs should use some internal notion of PRIMARY on those platforms
>> where it don't exist.  That way select and mouse-2 selects and insterts text
>> as on X.  But without touching the kill ring.
>
> Why is it important not to touch the kill ring?

Not important at all, it is just (I think) how mouse-2 works now.

> It seems to me that on platforms that have only one selection (the
> clipboard), selecting text should do nothing by default, while cutting
> should set the clipboard.  And there should be a variable to
> optionally set the clipboard when the text is selected.  (Do we
> already have such a variable?)  Do you agree?

Fine by me, as long as I can do select, mouse-2 to copy text on 
non-primary-enabled platforms.  It still doesn't clear up what Gpm/Xterm mode 
should do on mouse-2.

	Jan D.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

> Thanks, this clears up quite a bit of the confusion.  So would it be
> correct to modify the doc string of x-select-enable-primary to say
> this:
>
>     Non-nil means cutting text sets the primary selection.

[and pasting (yanking) gets from the primary selection.]

>     When the value is nil, the primary selection is still set by
>     selecting the text.
>

...if select-active-regions is t

As just mentioned elsepost, a third option other than nil and t, 'lazy, 
for select-active-regions was introduced recently, which means that 
mouse/shift selections do, but c-spc selections don't immediately, c-spc 
selections will defer setting primary to C-w/M-w time.

I don't like 'lazy.

> Why is it important not to touch the kill ring?
>

Well, if you do that, you break a conceptually straightforward 
kill-ring<=>clipboard mapping (that makes "turn on cua mode" somewhat 
useful advice to newbies who want to use C-x/c/v on x11) and pretty much 
depart from other-x11-app behaviour again.

>>> Thanks in advance for helping me become less confused.
>>
>> It is very confusing.  There are special cases depending on how the selection
>> was made, and then badly named variables increase the confusion.  Not to
>> mention trying to handle multiple platforms with differing capabilities.
>
> It seems to me that on platforms that have only one selection (the
> clipboard), selecting text should do nothing by default, while cutting
> should set the clipboard.

That sounds sensible to me, for the most part (there may be certain 
platforms that have an "only one selection (the primary)" - think gpm, 
where the user expectation would in fact be that mere selection of text 
changes the gpm "selection buffer" (as it is referred to in the gpm 
manpage) i.e. gpm happens to be more analogous to an x11 primary than an 
x11 clipboard, unlike the w32 clipboard where users generally do not 
expect mere selection of text to erase the previous clipboard contents).

w32 is the "odd one out" here of the x11/ns/w32 trinity.  I was rambling 
about ways to create an inter-application primary on w32 a while back, 
which caused you some puzzlement at the time.

Both x11 and ns platforms have functional inter-application 
clipboard/primary/secondary.  While other macosx apps may not typically 
use the latter two, they still work sensibly inter-session on macosx 
between emacs instances because of the way *step pasteboards work, and 
on gnustep/x11 they actually work in integrated fashion with x11 apps on 
the same desktop so long as you use the right pasteboard names,
which is neat.

>  And there should be a variable to
> optionally set the clipboard when the text is selected.  (Do we
> already have such a variable?

No, that would be the clipboard-active-regions I've mentioned before.

Some might have thought that's what x-select-enable-clipboard does, but, 
um, it doesn't, for similar reasons to x-select-enable-primary as just 
outlined by Jan D.

However, it used to "symptomatically" for mouse selections only on w32, 
because mouse selections used to implicitly copy 
(mouse-drag-copy-region=>t). That "copy" (kill-ring-save), as well as 
pushing to the kill-ring, called interprogram-cut-function, which set 
the clipboard when x-select-enable-clipboard is on.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 15:31:33 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: Jan Djärv <jan.h.d@swipnet.se>, 
>  cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> 
> > Thanks, this clears up quite a bit of the confusion.  So would it be
> > correct to modify the doc string of x-select-enable-primary to say
> > this:
> >
> >     Non-nil means cutting text sets the primary selection.
> 
> [and pasting (yanking) gets from the primary selection.]

But pasting gets from the primary selection unconditionally, so it
seems.  E.g., under the default nil value of x-select-enable-primary,
mouse-2 still pastes from the primary selection.  That's why I didn't
mention pasting in the suggested modification of the doc string.  Am I
missing something?

> >     When the value is nil, the primary selection is still set by
> >     selecting the text.
> >
> 
> ...if select-active-regions is t

You mean, non-nil, right?  At least in deactivate-mark, we have this:

  (when (or transient-mark-mode force)
    (when (and select-active-regions   <<<<<<<<<<<<<<
	       (region-active-p)
	       (display-selections-p))
      ;; The var `saved-region-selection', if non-nil, is the text in
      ;; the region prior to the last command modifying the buffer.
      ;; Set the selection to that, or to the current region.
      (cond (saved-region-selection
	     (x-set-selection 'PRIMARY saved-region-selection)
	     (setq saved-region-selection nil))
	    ((/= (region-beginning) (region-end))
	     (x-set-selection 'PRIMARY
			      (buffer-substring-no-properties
			       (region-beginning)
			       (region-end))))))

Is this a bug or intended behavior?

> As just mentioned elsepost, a third option other than nil and t, 'lazy, 
> for select-active-regions was introduced recently, which means that 
> mouse/shift selections do, but c-spc selections don't immediately, c-spc 
> selections will defer setting primary to C-w/M-w time.
> 
> I don't like 'lazy.

And I don't like in general the situation where it seems impossible to
say if and when will selected text be put into the primary selection.

May I suggest to step back and post a clear set of requirements for
when Emacs should and shouldn't put selected text into the primary
selection and into the clipboard?  Forget the w32 case for now; let's
just spell out the requirements for X.

> > Why is it important not to touch the kill ring?
> >
> 
> Well, if you do that, you break a conceptually straightforward 
> kill-ring<=>clipboard mapping

What mapping is that?  Do you mean that only killed text goes to the
clipboard?  If so, that's fine, but I wasn't talking about the
clipboard.  I was talking about the primary selection on X and about
platforms that don't have any selections at all.  I was wondering why
is it important to stay away of the kill-ring like mouse-yank-primary
does, instead of doing it like mouse-yank-at-click, which was
previously bound to mouse-2?

> and pretty much depart from other-x11-app behaviour again.

What behavior is that?  What other apps have something similar to the
kill ring?

> there may be certain 
> platforms that have an "only one selection (the primary)" - think gpm, 
> where the user expectation would in fact be that mere selection of text 
> changes the gpm "selection buffer" (as it is referred to in the gpm 
> manpage) i.e. gpm happens to be more analogous to an x11 primary than an 
> x11 clipboard, unlike the w32 clipboard where users generally do not 
> expect mere selection of text to erase the previous clipboard contents).

IMO, whenever there's only one selection, its name, whether primary or
clipboard, is not important.  Thus, GPM can be thought of as being
like w32, not like X, because the distinction between the primary and
all the other selections is null and void.

IOW, the clipboard-related behavior of Emacs on Windows should be the
same as what Emacs does on X wrt the primary selection.

> >  And there should be a variable to
> > optionally set the clipboard when the text is selected.  (Do we
> > already have such a variable?
> 
> No, that would be the clipboard-active-regions I've mentioned before.

Why do we need a separate variable for the clipboard on w32? why not
reuse select-active-regions?  The amount of subtly dependent variables
that control the behavior regarding selected text wrt selections is
already too large, why introduce yet another one?

> However, it used to "symptomatically" for mouse selections only on
> w32, because mouse selections used to implicitly copy
> (mouse-drag-copy-region=>t).

So maybe we should continue setting the clipboard data on selecting
text, since w32 users always had that (mis-)feature.  They are used to
it.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 14/08/10 16:18, Eli Zaretskii wrote:

 > You mean, non-nil, right?  At least in deactivate-mark, we have this:

No, I didn't.  whether t or 'lazy the current code still does it in 
deactivate-mark (possibly unnecessarily or even counterproductively in 
the the t case, I'm not currently sure), the t/lazy difference is 
elsewhere (keyboard.c line 1798 or so).

('lazy was not my idea, that's just my understanding)

> But pasting gets from the primary selection unconditionally, so it
> seems.

No, mouse-2 clicking does. pasting (C-y/ CUA C-v) doesn't.

mouse-2 click insertion and clipboard pasting are not equivalent on x11. 
If you think they are, then that surely would lead you to be confused.

> IMO, whenever there's only one selection, its name, whether primary or
> clipboard, is not important.

Users have different expectations of clipboards and primaries. Following 
de-facto standard in the area:

clipboards aren't overwritten when you merely select text.
clipboards are overwritten when you cut/copy (C-x/C-c)
clipboards are not inserted when you click mouse-2.
clipboards are inserted when you paste (C-v)
(w32 clipboard, ns general pasteboard, x11 clipboard*).

primary selections are overwritten when you merely select text.
primary selections are not overwritten when you cut/copy (C-x/C-c) (but 
they've probably already just been overwritten because you selected text 
just before you cut/copied).
primary selections are inserted when you click mouse-2.
primary selections are not inserted when you paste (C-v)

(like x11 primary selection, ns "Selection" pasteboard, gpm selection 
buffer)

So if emacs does anything other than clipboard<=>kill-ring, then
"cua mode" is not an answer, since if emacs C-w/M-w/C-y doesn't act like 
other-app C-x/C-c/C-v, making emacs C-x/C-c/C-v act like emacs 
C-w/M-w/C-y still doesn't make emacs C-x/C-c/C-v act like other-app 
C-x/C-c/C-v.

> Why do we need a separate variable for the clipboard on w32? why not
> reuse select-active-regions?

Why have the same setting do such grossly different things on different 
platforms?

> So maybe we should continue setting the clipboard data on selecting
> text, since w32 users always had that (mis-)feature.  They are used to
> it.

By all means have a clipboard-active-regions that defaults to t on w32 
if you want, but please do not reinterpret select-active-regions to 
affect the clipboard on w32.  You'd be making it gratuitously impossible 
to have the 3 gui platforms behave similarly given similar settings.

I'm not an emacs committer, just a contributor.  I can just go back to 
maintaining my own emacs branch with beer and hookers.  But once again 
I'd ask you not to use the name select-active-regions but rather 
clipboard-active-regions or similar for a feature that ...makes the 
active region got to the system clipboard, not the system selection..

Note such a feature also makes sense to provide on x11, there's an old 
guard who dislike the way x11 apps currently use primary/clipboard and 
x11 emacs users are more likely to be in that old guard than most.


* which happens to be /implemented with/ an "x11 selection thingy" 
(let's say a "rhubarb").  But so is, say, the protocol for deciding what 
x11 client is the active window compositing manager...(done with rhubarb 
'_NET_WM_CM_Sn rather than 'CLIPBOARD or 'PRIMARY or 'SECONDARY.)

rhubarbs are thingies x11 programs can "own" (beware this is not 
entirely equivalent to the w32 notion of clipboard ownership)

rhubarb 'PRIMARY implements the system notion of a known 
current/most-recent selection. The current owner of this rhubarb is who 
to ask for
the current/most-recent selection.

rhubarb 'SECONDARY implements, uh, another selection that people seldom 
use (alt-mouse-drag/alt-mouse-2 in emacs).  The current owner of this 
rhubarb is who to ask for the current/most-recent secondary selection.

rhubarb 'CLIBPOARD implements the system clipboard.  The current owner 
of this rhubarb is who to ask for the clipboard contents.

rhubarb '_NET_WM_CM_S0 implements the system notion of who is the 
current compositing manager for screen 0. The current owner of this 
rhubarb is who gets to be the current compositing manager.

RE: Selection changes in revno 100822

[Drew Adams]

> I can just go back to maintaining my own emacs branch
> with beer and hookers.

Oh - please _do_ commit that branch.  ;-)

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 18:21:05 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: cyd@stupidchicken.com, jan.h.d@swipnet.se, emacs-devel@gnu.org
> 
> > But pasting gets from the primary selection unconditionally, so it
> > seems.
> 
> No, mouse-2 clicking does. pasting (C-y/ CUA C-v) doesn't.

This just adds more confusion.  Mouse-2 _was_ pasting until very
recently.

> mouse-2 click insertion and clipboard pasting are not equivalent on x11. 

I wasn't talking about clipboard pasting, I was talking about pasting
from the primary selection.

> If you think they are, then that surely would lead you to be confused.

Please give me some minimal credit that I know what I'm talking about.

> > IMO, whenever there's only one selection, its name, whether primary or
> > clipboard, is not important.
> 
> Users have different expectations of clipboards and primaries. Following 
> de-facto standard in the area:
> 
> clipboards aren't overwritten when you merely select text.
> clipboards are overwritten when you cut/copy (C-x/C-c)
> clipboards are not inserted when you click mouse-2.
> clipboards are inserted when you paste (C-v)
> (w32 clipboard, ns general pasteboard, x11 clipboard*).

We've been there before.  As far as Windows use patterns are
concerned, we disagree.  I expect most Windows users disagree with
you, because there's only the clipboard, so no way of having 2
different selection types and 2 different ways of pasting.  Now let's
stop arguing about this, because we will never agree.  The above was
just my opinion, not an invitation to another dispute.

> primary selections are inserted when you click mouse-2.
> primary selections are not inserted when you paste (C-v)

Does this mean I have no way of pasting from the primary selection
without using a mouse?  That's hardly a Good Thing.

> > Why do we need a separate variable for the clipboard on w32? why not
> > reuse select-active-regions?
> 
> Why have the same setting do such grossly different things on different 
> platforms?

Because that makes users' life easier (less customizations when
switching platforms; can use the same .emacs without lots of
system-type conditionals, etc.).  Because we already do -- those are
all those x-SOMETHING variables.

> > So maybe we should continue setting the clipboard data on selecting
> > text, since w32 users always had that (mis-)feature.  They are used to
> > it.
> 
> By all means have a clipboard-active-regions that defaults to t on w32 
> if you want, but please do not reinterpret select-active-regions to 
> affect the clipboard on w32.  You'd be making it gratuitously impossible 
> to have the 3 gui platforms behave similarly given similar settings.

X and Windows cannot behave similarly because they have different
abilities.  Where X has 3 selection types, Windows has only one.  We
need to map those 3 into that one in some fashion, but no matter which
mapping we eventually use, there _will_ be differences.  Instead of
dumping these differences on users, by presenting the Windows users
with an array of options that don't make sense, Emacs should adapt as
seamlessly as possible, and let similar behavior be customizable by
the same options.

What you suggest is an antithesis of usability.  Not to mention that
it makes documentation much-much harder and the result will certainly
be confusing.  And the only reason you give is some purist arguments.
I think that's simply wrong.

So I will continue pushing for re-using primary-related options on
Windows to be applicable to the Windows clipboard, where it makes
sense.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 14/08/10 23:16, Eli Zaretskii wrote:

> Does this mean I have no way of pasting from the primary selection
> without using a mouse?

Yes, no way*, but x11 users don't generally expect to be able to.

* apart from the awkward keyboard mouse emulation, and actually some x11 
apps provide separate "paste" and "paste selection" menu options, which 
may be accessible via keyboard menu access.

>>> Why do we need a separate variable for the clipboard on w32? why not
>>> reuse select-active-regions?
>>
>> Why have the same setting do such grossly different things on different
>> platforms?
>
> Because that makes users' life easier (less customizations when
> switching platforms; can use the same .emacs without lots of
> system-type conditionals, etc.).

Nonsense, it means MORE customisations with MORE system-type 
conditionals. I'd have to have different settings on w32 to prevent my 
clipboard being eaten suddenly when I select text. Not that I use w32
by choice.

Also, the emulated primary mechanism in emacs already worked 
intra-session on w32, it's only in an inter-session context it doesn't 
work.

I don't really care so much so long as x11 isn't broken, but the idea 
your way makes .emacs more portable rather than less is absurd.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 23:33:31 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> 
> On 14/08/10 23:16, Eli Zaretskii wrote:
> 
> > Does this mean I have no way of pasting from the primary selection
> > without using a mouse?
> 
> Yes, no way*, but x11 users don't generally expect to be able to.

Sounds strange, but fine with me.

> >>> Why do we need a separate variable for the clipboard on w32? why not
> >>> reuse select-active-regions?
> >>
> >> Why have the same setting do such grossly different things on different
> >> platforms?
> >
> > Because that makes users' life easier (less customizations when
> > switching platforms; can use the same .emacs without lots of
> > system-type conditionals, etc.).
> 
> Nonsense, it means MORE customisations with MORE system-type 
> conditionals. I'd have to have different settings on w32 to prevent my 
> clipboard being eaten suddenly when I select text.

Your personal preferences are just that--yours and yours alone.
Imposing them on others is not a good idea, and building theories on
them is even worse.

> Also, the emulated primary mechanism in emacs already worked 
> intra-session on w32, it's only in an inter-session context it doesn't 
> work.

There's no such thing as "half-works".  Either it works or it doesn't.
Patches to make primary selection work 100% on Windows are very
welcome.  Until we have that, we will have to use the clipboard as a
replacement for the missing primary selection.

> I don't really care so much so long as x11 isn't broken, but the idea 
> your way makes .emacs more portable rather than less is absurd.

It is absurd only if you don't want compatible behavior.  Like, if you
don't want the clipboard to serve as replacement for the missing
primary selection--that is, you want no interprogram selections at all
on Windows.  It's your prerogative to want that, but I very much doubt
other Windows users will agree with you.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 14/08/10 23:58, Eli Zaretskii wrote:
>> Date: Sat, 14 Aug 2010 23:33:31 +0100
>> From: David De La Harpe Golden<david@harpegolden.net>
>>
>> On 14/08/10 23:16, Eli Zaretskii wrote:
>>
>>> Does this mean I have no way of pasting from the primary selection
>>> without using a mouse?
>>
>> Yes, no way*, but x11 users don't generally expect to be able to.
>
> Sounds strange,


It is, sorta, if you used x11 in the very distant past when things 
worked differently.  Basically primary is now very de-emphasised. The 
relevant spec says:

"""
PRIMARY is an "easter egg" for expert users, regular users
can just ignore it; it's normally pastable only via
middle-mouse-click.
"""

> Patches to make primary selection work 100% on Windows are very
> welcome.

Hmm.

Honestly, I'm sorry I chimed in at all, a few hours ago you seemed to 
agree on some more sensible behaviour, so whatever I said I managed to 
change your mind, which is most unfortunate.

"""
It seems to me that on platforms that have only one selection (the
clipboard), selecting text should do nothing by default, while cutting
should set the clipboard.  And there should be a variable to
optionally set the clipboard when the text is selected.  (Do we
already have such a variable?)  Do you agree?
"""

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sun, 15 Aug 2010 00:42:20 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: emacs-devel@gnu.org
> 
> Honestly, I'm sorry I chimed in at all, a few hours ago you seemed to 
> agree on some more sensible behaviour, so whatever I said I managed to 
> change your mind, which is most unfortunate.

You are wrong, I never changed my mind.

Re: Selection changes in revno 100822

[James Cloos]

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

DDLHG> On 14/08/10 23:16, Eli Zaretskii wrote:

>> Does this mean I have no way of pasting from the primary selection
>> without using a mouse?

DDLHG> Yes, no way*, but x11 users don't generally expect to be able to.

Yes we do.  A few kids might not have learned it yet, but anyone who has
used X11 for any length of time will come to use primary as the primary ☺
method of copy-n-paste.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Selection changes in revno 100822

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I wasn't talking about clipboard pasting, I was talking about
 > pasting from the primary selection.

AFAIK you can't copy/paste from the Windows primary selection (unless
it's a situation where moving doesn't make sense, such as between
disks in Explorer), although you can drag it somewhere else.  (More
explanation below.)

 > > > But pasting gets from the primary selection unconditionally, so
 > > > it seems.

 > > No, mouse-2 clicking does. pasting (C-y/ CUA C-v) doesn't.

 > This just adds more confusion.  Mouse-2 _was_ pasting until very
 > recently.

That's because of the (bogus) historical association of the selection
with the kill-ring in Emacs.  Good riddance, IMO.

 > > mouse-2 click insertion and clipboard pasting are not equivalent
 > > on x11.  If you think they are, then that surely would lead you
 > > to be confused.

 > Please give me some minimal credit that I know what I'm talking
 > about.

That's kind of difficult when you also wrote this:

 > We've been there before.  As far as Windows use patterns are
 > concerned, we disagree.  I expect most Windows users disagree with
 > you, because there's only the clipboard, so no way of having 2
 > different selection types and 2 different ways of pasting.

On X11 there are three different selection types, in fact, and two
different ways of pasting.  That is a fact, and saying the Windows
users don't believe it doesn't make it any less true.

And in fact, there *is* an analog to the X11 primary selection on
Windows, and it can only be manipulated with the mouse.  That's what
is used for drag'n'drop.  AFAIK there is no way to paste that
selection from the keyboard (C-v) without using cut (C-x) or copy
(C-c) first (in fact C-v will overwrite it with the contents of the
clipboard), but in some applications (eg, the Explorer) it can be
dragged, which causes either movement or copying depending on context,
and does not affect the clipboard.  Am I wrong?

I don't know enough about Windows to guess whether Emacs could access
this feature, but I bet if it were available some Windows users would
take to dragging text around in a buffer like ducks take to water.

 > Now let's stop arguing about this, because we will never agree.
 > The above was just my opinion, not an invitation to another
 > dispute.

Your opinion is wrong, and that matters a lot.  Some experienced X
users use the "drag to select, middle button to paste" and "drag to
select, drag again to move" gestures a lot (when available, drag to
move isn't standard part of toolkits AFAIK, although some apps
implement it).  If available, Windows users might like to use it too.

 > > primary selections are inserted when you click mouse-2.
 > > primary selections are not inserted when you paste (C-v)
 > 
 > Does this mean I have no way of pasting from the primary selection
 > without using a mouse?  That's hardly a Good Thing.

Indeed, it's a Damn Good Thing.  Pasting from the *primary* selection
is supposed to be lightweight.  It's only interesting if you only want
to do something very simple (copy/paste) quickly, and not disturb the
state of the application or system (specifically, the contents of the
clipboard).  Since your hand is already on the mouse in most cases,
why would you use a different interface to manipulate the selection?

Otherwise, you need to manipulate a clipboard (with the menus or keys,
and here by "a clipboard" I mean either the system clipboard, or an
app-specific clipboard such as the Emacs kill ring).  And if you
originally selected via the keyboard, then you can easily use C-c or
C-x to copy/move it to a clipboard.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: David De La Harpe Golden <david@harpegolden.net>,
>     cyd@stupidchicken.com,
>     jan.h.d@swipnet.se,
>     emacs-devel@gnu.org
> Date: Sun, 15 Aug 2010 22:52:39 +0900
> 
> Eli Zaretskii writes:
> 
>  > I wasn't talking about clipboard pasting, I was talking about
>  > pasting from the primary selection.
> 
> AFAIK you can't copy/paste from the Windows primary selection (unless
> it's a situation where moving doesn't make sense, such as between
> disks in Explorer), although you can drag it somewhere else.

You are confused (not that it's hard to become one in this thread).  I
was talking about X here, not about Windows.

>  > Please give me some minimal credit that I know what I'm talking
>  > about.
> 
> That's kind of difficult when you also wrote this:
> 
>  > We've been there before.  As far as Windows use patterns are
>  > concerned, we disagree.  I expect most Windows users disagree with
>  > you, because there's only the clipboard, so no way of having 2
>  > different selection types and 2 different ways of pasting.
> 
> On X11 there are three different selection types, in fact, and two
> different ways of pasting.  That is a fact, and saying the Windows
> users don't believe it doesn't make it any less true.

You are confused.  The "as far as Windows use patterns" part is about
my past disagreements with David regarding how to map 3 selection
types on X to a single clipboard on Windows.  The "give me some
credit" part is about the distinction between these 3 selection types
on X: somehow, David thought I didn't understand that, and that I
needed a lecture about it.

> And in fact, there *is* an analog to the X11 primary selection on
> Windows, and it can only be manipulated with the mouse.  That's what
> is used for drag'n'drop.  AFAIK there is no way to paste that
> selection from the keyboard (C-v) without using cut (C-x) or copy
> (C-c) first (in fact C-v will overwrite it with the contents of the
> clipboard), but in some applications (eg, the Explorer) it can be
> dragged, which causes either movement or copying depending on context,
> and does not affect the clipboard.  Am I wrong?

You are talking about drag'n'drop, which does have a direct analog on
X.  I don't think drag'n'drop, in its current shape, could or should
be regarded as a kind of ``primary selection'' on Windows, that would
just make this discussion more confusing.  Drag'n'drop APIs _might_ be
a basis for implementing PRIMARY on Windows (assuming it can support
that -- I didn't research this issue, so I don't know), but unless and
until someone comes up with a patch to do that, MS-Windows users will
have to do without PRIMARY.

> Some experienced X
> users use the "drag to select, middle button to paste" and "drag to
> select, drag again to move" gestures a lot (when available, drag to
> move isn't standard part of toolkits AFAIK, although some apps
> implement it).  If available, Windows users might like to use it too.

But it isn't available on Windows, not without overwriting the
clipboard with selected text.  Unless you are willing to give up
having the primary selection available to other apps, which is what
the emulation of PRIMARY on Windows already does in Emacs.

Anyway, the issue of why the primary selection and the clipboard
should be set separately in Emacs and by different gestures is quite
clear (although it would be nice if it were explained in NEWS in more
detail), so let's not beat this dead horse anymore.  The only issue
that still needs to be discussed (IMO) is which gestures should cause
PRIMARY to be set with the selected text and which shouldn't.  This
should be decided for X first; the mapping to Windows' limitations
should come later.

Re: Selection changes in revno 100822

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > >  > I wasn't talking about clipboard pasting, I was talking about
 > >  > pasting from the primary selection.

 > > AFAIK you can't copy/paste from the Windows primary selection
 > > (unless it's a situation where moving doesn't make sense, such as
 > > between disks in Explorer), although you can drag it somewhere
 > > else.

 > You are confused (not that it's hard to become one in this thread).
 > I was talking about X here, not about Windows.

Perhaps I was not being sufficiently explicit.  There *is* an analogue
to the primary selection on Windows, but it is (at least) as limited
as the primary selection on X, although in a different way.  (Although
it would seem from discussion in this thread that Windows programmers
don't think of it that way.)

Because of this, it makes sense to look for a common interface that is
natural to Windows users, and is not unnatural (because not commonly
used for something else) to X11 users.  That something is drag and
drop, which happens to work on Mac as it does on Windows AFAIK.

It doesn't hurt if mouse-2 is enabled as paste-the-primary on X11.  In
fact, I would really like that combination.  Drag to move and mouse-2
to copy, without polluting the kill ring, would be a killer feature
IMHO.  Sometimes I want to move once, sometimes I want to copy one or
more times.  This gives me both.

 > You are confused.  The "as far as Windows use patterns" part is
 > about my past disagreements with David regarding how to map 3
 > selection types on X to a single clipboard on Windows.

Sure, but the reason you give is wrong.  There is a clipboard, and
there is the selection, which *can* but does not *always* interact
with the clipboard.  These can be distinguished by the user on Windows
as well as in X11.  If you drag a file in Explorer, it does not end up
on the clipboard.

 > The "give me some credit" part is about the distinction between
 > these 3 selection types on X: somehow, David thought I didn't
 > understand that, and that I needed a lecture about it.

Well, you may understand it, but you do not write in a way that would
allow someone familiar with X conventions and terminology to guess
that you do.  If you're going to consistently use terms that have a
specific definition in X ("selection", "primary") in a different way,
then you have a choice: be misunderstood, or repeatedly provide your
definitions.

Asking people who know X well to forget all the definitions they know
*when talking about X* is not an option.  The human mind is flexible
enough to use X definitions in the X world and Emacs definitions in
the Emacs world, but it is not going to successfully adapt to loss of
the familiar vocabulary that is *needed* for this kind of discussion,
just because you don't feel like learning to speak intelligibly to an
audience of Xperts.

 > You are talking about drag'n'drop, which does have a direct analog
 > on X.  I don't think drag'n'drop, in its current shape, could or
 > should be regarded as a kind of ``primary selection'' on Windows,
 > that would just make this discussion more confusing.

Drag and drop is not a primary selection, it is a way of manipulating
the primary selection (or its Windows analog).  The primary selection
is a set of objects contained in an area on the screen, normally
indicated by highlighting, which in practice can manipulated
ephemerally with the mouse, or which can be more durably handled by
placing them (as a group) on the clipboard.

 > > Some experienced X users use the "drag to select, middle button
 > > to paste" and "drag to select, drag again to move" gestures a lot
 > > (when available, drag to move isn't standard part of toolkits
 > > AFAIK, although some apps implement it).  If available, Windows
 > > users might like to use it too.

 > But it isn't available on Windows, not without overwriting the
 > clipboard with selected text.

Drag and drop *is* available, and I explained elsewhere a reasonable
compromise semantics (copy between apps, move within a document,
context-dependent for separate buffers within Emacs) which gives
Windows most of what I would want.  X11 can have full mouse-based
functionality by also binding mouse-2 to paste-primary-selection.

Of course the drop targets need to accept what Emacs has to offer, but
that's not Emacs's problem, I suspect most drop targets that should
accept dropped text do accept dropped text, and the user can always
fall back on C-c/C-v to work via the clipboard.

 > The only issue that still needs to be discussed (IMO) is which
 > gestures should cause PRIMARY to be set with the selected text and
 > which shouldn't.

Hey, Eli, you're the one who said, "let's talk about X first".  Well,
in X, that needs zero discussion.  In X, PRIMARY *is* the set of
objects in the selected (highlighted) area of the screen (which might
be text or a widget or an icon, or sets of the above).  I don't know
of any programs where this is not true.  And the program should not do
something different unless explicitly asked by the user.  It would be
insane on X if PRIMARY was not set (by default) when something is
selected.

If by "selected" you mean the Emacs region, that does need discussion,
but you've got the wrong idea.  It's not "which gestures," it's "which
face."  I would say that if you highlight the region with the same
face used to highlight an area selected by the mouse, then Emacs
should own PRIMARY and associate the region with it.  If the region is
not highlighted, or highlighted with a distinctive face different from
the one used to indicate the X selection, then Emacs should not own
primary for that region.

Of course you can then say, "which gestures should be associated with
which face".  On that, IMO the region should be either highlighted or
not, and when it is highlighted, it should be highlighted with the "X
selection face", and it should be associated with the PRIMARY
selection.  Regardless of the gesture(s) used to select the region.
IIUC, that is Miles's position, too.

N.B. 15 years of experience with that policy in XEmacs say it works
well, including the last ten years when selection by mouse, selection
by C-SPC, and selection by shifted motion have all been available (by
default).

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: cyd@stupidchicken.com,
>     jan.h.d@swipnet.se,
>     emacs-devel@gnu.org,
>     david@harpegolden.net
> Date: Mon, 16 Aug 2010 02:36:42 +0900
> 
> If by "selected" you mean the Emacs region

Yes!

> that does need discussion,

At last!

> but you've got the wrong idea.  It's not "which gestures," it's "which
> face."

That's your interpretation (and I happen to agree with it), but Emacs
doesn't currently behave consistently in this regard, and a few hours
ago, I wasn't even sure others will agree with me.  I would still wait
for a day or two to hear possible objections.

RE: Selection changes in revno 100822

[Drew Adams]

>  > Mouse-2 _was_ pasting until very recently.
> 
> That's because of the (bogus) historical association of the selection
> with the kill-ring in Emacs.  Good riddance, IMO.

Reason?  Emacs has always had that feature (as long as I can remember, at
least).  And IMO it is a positive, handy feature.  I take advantage of it all
the time.

Why is it "bogus"?  What is gained by losing the ability to yank from the kill
ring using the mouse?

>  > We've been there before.  As far as Windows use patterns are
>  > concerned, we disagree.  I expect most Windows users disagree with
>  > you, because there's only the clipboard, so no way of having 2
>  > different selection types and 2 different ways of pasting.
> 
> On X11 there are three different selection types, in fact, and two
> different ways of pasting.  That is a fact, and saying the Windows
> users don't believe it doesn't make it any less true.

Why care so much about X11 (or Windows or...)?  Why not define the best
interaction for _Emacs_ itself?  From the descriptions here of the X behavior, I
see no advantage over the traditional Emacs behavior regarding selection,
copying, killing, and yanking.

I don't think anyone has explained the advantage for Emacs users _in Emacs_.
We've heard that this can help X users by making Emacs correspond more closely
with X, but that's the only user-oriented argument voiced so far, AFAICS.
Compatibility with other apps or window mgrs is a consideration, of course, but
only one consideration.

Why should it be all-important for Emacs to limit its user interaction to what
X11 defines?  Or to what Windows defines.  Or to what any other OS or window mgr
defines.

Emacs needs to _cohabit_ with window managers - sure.  But it need not respect
every whim that a particular window mgr implements.  (This is circling 'round to
the discussion about CUA.)  Emacs is not X.  Emacs is not Windows.

It is far more important that Emacs user interaction be useful and _internally_
consistent than that it be the same as what some app or window mgr might define.

Catering to what some or even many users might be accustomed to outside of Emacs
is only one consideration for Emacs design.  And even that is not the same thing
as catering to some window-mgr "standard": Many users of X or of Windows seldom
use some of the behavior it might define as part of its "standard".

X-standardization of Emacs is not my goal.  If it is the proposed goal here,
then please provide some user-oriented arguments.  Tell us what _users_ gain and
what they lose by such a change.

>  > > primary selections are inserted when you click mouse-2.
>  > > primary selections are not inserted when you paste (C-v)
>  > 
>  > Does this mean I have no way of pasting from the primary selection
>  > without using a mouse?  That's hardly a Good Thing.
> 
> Indeed, it's a Damn Good Thing.  Pasting from the *primary* selection
> is supposed to be lightweight.

"Supposed" by whom?  That question seems to be the elephant in the room.  Why
should we be limiting Emacs behavior to what X (or any other window mgr) might
define?  The X11 std defines what is "supposed to happen" for X11, but not for
anything else.  This is the emacs-devel list, not the x11-devel list.

Reminds me of the kind of changes that take place after one software company
buys another: the software of the gobbled is reworked to fit the gobbler.  X11
has not bought Emacs, AFAIK, so why act as if Emacs is being swallowed?

> It's only interesting if you only want to do something very
> simple (copy/paste) quickly, and not disturb the state of the
> application or system (specifically, the contents of the
> clipboard).

Who says so?  Not Emacs.  Not until now.  Emacs has traditionally associated
mouse-2 pasting with yanking the head of the kill ring.

That might not be what is interesting to X11, but it is interesting to Emacs and
Emacs users.  And it has been, for decades.  Is there some reason now why this
feature should no longer interest Emacs users?  Calling it "bogus" is not an
argument; it's just name-calling.

> Since your hand is already on the mouse in most cases,
> why would you use a different interface to manipulate the selection?

For one thing, your hand might no longer be on the mouse when you want to do
that.  You seem to have a simplistic idea of mouse use.

Do you (Stephen) actually use both the mouse and the keyboard for selecting and
yanking/pasting?  Maybe not.  I do.  I often use C-y to yank text that I have
previously selected using the mouse.  And I often use mouse-2 to yank text that
I have previously selected using the keyboard.

Both keyboard and mouse are convenient at different times for both selection and
yanking/pasting.

In fact, yanking with C-y is so handy, even when the selection might have been
made previously using the mouse, that I personally do the same thing for the
_secondary_ selection.

I bind C-M-y to yank the secondary - and I use it often.  I even have and use a
secondary-selection kill ring, analogous to the kill ring used by C-y.  (And in
Emacs, at least, the secondary selection definitely _is_ less ephemeral than the
region, primary, and clipboard.)

There seems to be an assumption here that mouse and keyboard do not mix.  That
they live on different planets or different sides of the railroad tracks.  That
you use either one or the other.  That we might as well consecrate their
de-facto segregation, erecting a clean, high wall so they cannot interact.

I use both.  Depending on the context, I might double-click the mouse to select
a Lisp symbol or a text line or a Lisp sexp, or I might use the keyboard to do
that.  Each can be useful.  One is not inherently more ephemeral or lightweight
than the other.  They should not be relegated to separate ghettos.

Maybe X or Windows feels differently about that, but I'm interested in Emacs,
not X or Windows.

I do not want to see mouse selection and pasting become cantoned apart from
keyboard selection and yanking.  And I do not feel this way just about my own
personal use but also about what Emacs should be offering users in general.  At
the very least, the traditional (superior) Emacs way should still be available.

And it would be better to keep it as the default.  At least that is what I feel
now, until I hear some actual arguments (reasons) wrt the _benefit to users_ of
such a change.

So far, all I've heard (I have not studied each mail in detail, so I might have
missed something) is the argument that X defines things this way: XYZ0123, so
Emacs must do that also, to be X-compatible.

That, to me, is a _VERY_ weak argument for Emacs design.  Tell us how Emacs
_users_ benefit, please.  I do not believe in sacrifice to the goddess of
external compatibility with no benefit in sight.

X11 is not a goddess to whom Emacs need bow down.  Likewise, Windows.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>, <jan.h.d@swipnet.se>, <emacs-devel@gnu.org>,
>         "'David De La Harpe Golden'" <david@harpegolden.net>
> Date: Sun, 15 Aug 2010 10:48:16 -0700
> 
> Emacs has traditionally associated mouse-2 pasting with yanking the
> head of the kill ring.

Drew, you make a convincing argument that you would like selecting
text to set the clipboard with that text.  It turns out others don't
want that.  Assuming that we have or will have an option to get you
what you want, this becomes an argument about the default behavior.
Is it still worth our time to have that argument?  Does it really
matter if you are part of the majority or not?

Instead of arguing about the defaults, I'd suggest to discuss the
various preferences of users regarding this, and see that we have one
or two clearly defined options to get everyone what they want,
including on X/ns, on Windows, and on text-only terminals that support
the mouse.

RE: Selection changes in revno 100822

[Drew Adams]

> > Emacs has traditionally associated mouse-2 pasting with yanking the
> > head of the kill ring.
> 
> Drew, you make a convincing argument that you would like selecting
> text to set the clipboard with that text.

I did not say that in what you quoted - read it again.  Does it say anything
about mouse _selection_?  No.  It speaks about mouse-2 _pasting_ as yanking the
kill-ring head.

I asked, "What is gained by losing the ability to yank from the kill ring using
the mouse?"

You yourself said "Does this mean I have no way of pasting from the primary
selection without using a mouse?  That's hardly a Good Thing."  That speaks
about the other direction.  You expressed concern about being able to use the
keyboard to paste something that might have been selected using the mouse.

I'm concerned about both directions.

Yes, I did say that "I often use C-y to yank text that I have previously
selected using the mouse.  And I often use mouse-2 to yank text that I have
previously selected using the keyboard."  Both directions, for the mouse and for
the keyboard.  Just what Emacs has always offered.

I don't care so much what you call the kind of saved selection that can be
pasted/yanked by the mouse or the keyboard.  Calling it primary or clipboard,
and saying that one or the other is "supposed" to be lightweight etc. according
to the X std does not weigh heavily as an argument.  For me.  X-standardization
is not the goal, for me.

Express what will change for _users_, operationally, and why it is a good thing.
Don't just say that the change is good and the traditional behavior is "bogus".
State clearly what is to be gained by changing.  And say clearly and completely
what the change is.  Whether the change will be a change in default or just an
option - same need to explain it clearly.

> It turns out others don't want that.

Some others who are promoting this change, sure.  _I_ might not want it either,
once you explain the advantages of something different.  My guess is that most
people here are not even clear on what is being proposed - what the change is.

That's my point: Make clear what the stakes are for users: What will be changed
_from a user point of view_.  And why it is a good thing: advantages,
disadvantages.  Do not just argue about what X conformity demands - argue about
what you want for Emacs users.

How do you expect any of us to decide what we think is best if it's not clear
what behavior changes are proposed?

I said clearly that my preference for the traditional default behavior is only
tentative, based on familiarity with it and a fuzzy idea (ignorance) of what
changes are being proposed.  I like what Emacs has always let me do, and so far
it doesn't sound like I would prefer what has been hinted at vaguely.

But tell me the advantage of not being able to use C-y to yank what you have
selected with the mouse and not being able to use mouse-2 to paste what you have
selected with the keyboard.  I'm ready to be persuaded, just let me know what
the advantages are.

This is no different from any other change to Emacs in this regard - we deserve
to have an idea where we're headed.

> Assuming that we have or will have an option to get you
> what you want, this becomes an argument about the default behavior.
> Is it still worth our time to have that argument?  Does it really
> matter if you are part of the majority or not?
> 
> Instead of arguing about the defaults, I'd suggest to discuss the
> various preferences of users regarding this, and see that we have one
> or two clearly defined options to get everyone what they want,
> including on X/ns, on Windows, and on text-only terminals that support
> the mouse.

We agree that users should at a minimum have the ability to get back the
traditional Emacs behavior, and that that possibility is more important than
whatever the default behavior might end up being.  That's always the case, for
any proposed change.

Is there a clear proposal to change the default behavior?  It seems that such a
change is being made, but I've seen no real proposal for that.  If there is such
a proposal, then let's hear arguments in favor of it - and primarily in terms of
benefits (and costs) to Emacs users.

I'm open to arguments about the default behavior, and I'm sure others are too.
I was quite clear that my feeling about the default is only tentative, "until I
hear some actual arguments (reasons) wrt the _benefit to users_ of such a
change".  Let's hear the arguments for changing the default.

Let's not just say that the traditional behavior is "bogus" or act as if we must
make Emacs fit the X standard.  Let's have a real discussion in terms of
behavior for users: what are the benefits and costs of the proposed behavior
changes?

So far, we've gotten actual changes (implementation) with no arguments
supporting them.  When people complained, they were sometimes told that the
changes (but which ones?) are only temporary bugs that will soon be fixed (and a
few have been).  But sometimes it seems that some of the implemented changes are
intended (which ones?), and no real reasons have been given for them beyond
X-standardization.

And it really doesn't matter at this point whether the issue is the default
behavior or optional behavior.  Even if the new behavior will be optional, we
still deserve a clear explanation of it and arguments letting us know its
advantages and disadvantages.

It's amazing to me that we've gotten this far along with no proposal,
discussion, and argument about pros & cons for users.

That's not the way to proceed.  If great, positive changes are in store, then
please discuss them openly.  State clearly what will change from a user
perspective, and what benefits and costs you see for users.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <stephen@xemacs.org>, <cyd@stupidchicken.com>, <jan.h.d@swipnet.se>,
>         <emacs-devel@gnu.org>, <david@harpegolden.net>
> Date: Sun, 15 Aug 2010 12:29:29 -0700
> 
> > > Emacs has traditionally associated mouse-2 pasting with yanking the
> > > head of the kill ring.
> > 
> > Drew, you make a convincing argument that you would like selecting
> > text to set the clipboard with that text.
> 
> I did not say that in what you quoted - read it again.

I was unable to quote a small part of your mail that said it all.
Nevertheless, please trust me that I read it all and understood what I
read.

> Does it say anything about mouse _selection_?  No.  It speaks about
> mouse-2 _pasting_ as yanking the kill-ring head.

If selecting text sets the clipboard, then mouse-2 will yank it.  You
also provided other use-cases which led me to the same conclusion:
that you want selected text to go to the clipboard.  For example:

> Yes, I did say that "I often use C-y to yank text that I have previously
> selected using the mouse.  And I often use mouse-2 to yank text that I have
> previously selected using the keyboard."  Both directions, for the mouse and for
> the keyboard.  Just what Emacs has always offered.

These both will work like you want them to if selecting text puts it
into the clipboard.

> Express what will change for _users_, operationally, and why it is a good thing.
> Don't just say that the change is good and the traditional behavior is "bogus".

You seem to confuse me with Stephen.  I didn't say the old behavior
was bogus.

> State clearly what is to be gained by changing.

Consistency with other X apps, so it seems.  And I happen to agree
that consistency with widely accepted GUI standards is a Good Thing,
in general.

> And say clearly and completely what the change is.

That was said already.  Let me repeat it (quoting David with slight
changes):

  clipboards aren't overwritten when you merely select text.
  clipboards are overwritten when you cut/copy (C-w/M-w)
  clipboard text is not inserted (pasted) when you click mouse-2.
  clipboard text is inserted when you paste (C-y)

  primary selections are overwritten when you merely select text.
  primary selections are not overwritten when you cut/copy (C-w/M-w) (but 
    they've probably already just been overwritten because you selected
    text just before you cut/copied).
  primary selections are inserted when you click mouse-2.
  primary selections are not inserted when you paste (C-y)

> That's my point: Make clear what the stakes are for users: What will
> be changed _from a user point of view_.  And why it is a good thing:
> advantages, disadvantages.

See this URL:

   http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt

It makes good sense wrt apps other than Emacs.  When applied to Emacs,
IMO most of the reasons it gives for the above behavior are quite
lame, because Emacs has features this document doesn't consider.  But
there's one reason that made perfect sense to me even wrt Emacs,
namely, that the "traditional" Emacs behavior with setting PRIMARY on
C-w/M-w has this problem:

 - you should be able to select text, then paste the clipboard over
   it, but that doesn't work if the selection and clipboard are the
   same

IOW, if selecting text overwrites the clipboard, you cannot select and
then paste from the clipboard over the selection, because selecting
destroys the clipboard data.

(It is ironical that all the heated discussion regarding the reasons
why the new behavior is "right" never brought up this reason, which
IMO is the only one that hits the nail on the head.)

> It's amazing to me that we've gotten this far along with no proposal,
> discussion, and argument about pros & cons for users.

FWIW, the above URL was posted here long ago.  All the info you are
looking for is there.

RE: Selection changes in revno 100822

[Drew Adams]

> > Express what will change for _users_, operationally, and 
> > why it is a good thing.  Don't just say that the change is
> > good and the traditional behavior is "bogus".
> 
> You seem to confuse me with Stephen.  I didn't say the old behavior
> was bogus.

No, I'm not confusing you with Stephen.  I was not replying only to you
personally.

The point is that this discussion has not expressed what will change for users,
in user terms.  Some general opinions have been expressed wrt
good/bad/ugly/bogus, without any clear expression of just what behavior changes
are proposed.  

> > State clearly what is to be gained by changing.
> 
> Consistency with other X apps, so it seems.

Yes, we've gathered that much.  But what will change, in operational terms, for
Emacs users?  Please tell us concretely and completely just what will change.
(Again, the request is not necessarily for you personally.)

> And I happen to agree that consistency with widely accepted
> GUI standards is a Good Thing, in general.

Probably everyone agrees that consistency is good, in general.  Mom & apple pie
- hoorah.

The question is what is the +/-/good/bad _for Emacs_, with emphasis on
specifics.  What behavior changes, and what are their advantages and
disadvantages.

Emacs has always been _more or less_ consistent with some outside standards.  It
has also always differed to some extent from some outside standards.

For the most part, any divergence from standards has not been accidental but
intentional - that is my impression, at least.  And over time, accidental
divergences that have little negative impact have been corrected.  IOW, other
things being equal, sure, let's go for consistency with the outside world.

What is most important wrt consistency is the _internal_ consistency within
Emacs.  And the devil is as always in the details: what changes and (for each
change) what advantages.

Complete consistency wrt an outside standard is not a necessary or sufficient
aim.  (Richard has expressed that elegantly on a number of occasions.)  It
should be only one consideration for us.

What any potential changes do to users inside Emacs is much more important.  So
far, we know little about what changes are in store here.  Lots of smoke and
noise, little fire and signal.

> > And say clearly and completely what the change is.
> 
> That was said already.  Let me repeat it (quoting David with slight
> changes):
> 
>   clipboards aren't overwritten when you merely select text.
>   clipboards are overwritten when you cut/copy (C-w/M-w)
>   clipboard text is not inserted (pasted) when you click mouse-2.
>   clipboard text is inserted when you paste (C-y)
> 
>   primary selections are overwritten when you merely select text.
>   primary selections are not overwritten when you cut/copy 
> (C-w/M-w) (but 
>     they've probably already just been overwritten because 
> you selected
>     text just before you cut/copied).
>   primary selections are inserted when you click mouse-2.
>   primary selections are not inserted when you paste (C-y)

Sorry, that means little to me.  Try saying something without referring to
"primary" or "clipboard".  Try describing the changes simply and
_operationally_, in terms of user actions.  See David's last mail replying to
you for how.

And please express them clearly as _changes_: Previously, when you did A and
then B, the result was C.  Now, the result will instead be D.  That will be
clear to all Emacs users, regardless of their knowledge of the X standard,
primary selection, and clipboard.

I repeat:

"AFAICS we haven't yet gotten a simple description of the proposed changes, in
terms of how they will affect users: use cases, pros & cons, what will change
and why."

> > That's my point: Make clear what the stakes are for users: What will
> > be changed _from a user point of view_.  And why it is a good thing:
> > advantages, disadvantages.
> 
> See this URL:
> http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt

I already saw it.

See above: Please describe the proposed changes in terms of Emacs user actions.

> It makes good sense wrt apps other than Emacs.  When applied to Emacs,
> IMO most of the reasons it gives for the above behavior are quite
> lame, because Emacs has features this document doesn't consider.  But
> there's one reason that made perfect sense to me even wrt Emacs,
> namely, that the "traditional" Emacs behavior with setting PRIMARY on
> C-w/M-w has this problem:
> 
>  - you should be able to select text, then paste the clipboard over
>    it, but that doesn't work if the selection and clipboard are the
>    same
> 
> IOW, if selecting text overwrites the clipboard, you cannot select and
> then paste from the clipboard over the selection, because selecting
> destroys the clipboard data.

Please express it in Emacs terms.  Give a recipe involving Emacs actions and not
mentioning "clipboard" or "selection".  For example:

1. Select some text with the mouse.

(If important, break that down, but I'm guessing it is insignificant here just
how selection is made using the mouse: drag, double-click, mouse-1 +
mouse-3,...)

2. Hit C-y on the keyboard.
... (whatever)

Show in that way what the problem is that you (pl) are trying to solve.
Apparently, today there is a problem that people are running into (which
involves trying to "paste the clipboard over selected text").  I'm not aware of
the problem.

Please describe it in simple terms.  Start with emacs -Q, so we'll know just
which modes are involved (e.g. delete-selection-mode? transient-mark-mode?...).

> (It is ironical that all the heated discussion regarding the reasons
> why the new behavior is "right" never brought up this reason, which
> IMO is the only one that hits the nail on the head.)

OK, so you have found a reason for the changes that convinces you.  If you
express it in Emacs terms (operationally), then perhaps some of the rest of us
will also be convinced.

Do I understand it?  Maybe I do, but I think you (someone) should express it wrt
Emacs actions.  Might as well be very clear to everyone.

What is the problem in practice?  Is it that you want to select some text A,
save that selection, select some other text B, and paste the saved text A to
replace text B?

Is that it?  Is that the only reason for all of these changes - the reason, at
least, that convinced you?  If so, then I really don't see it as a significant
problem.

I already do that everyday, using the secondary selection - which has always
been less ephemeral than and independent from the region/selection in Emacs.  I
often use that as a quick way to perform ad hoc replacements in Emacs.

Doing that using the secondary selection does not prevent interaction between
the mouse and the kill ring.  And selection of the region with the mouse is done
differently from selection of the secondary with the mouse (modifier keys), so
the mouse can be used for each independently.  And either can be used for
yanking, independently (I mentioned that I have a second kill ring for the
secondary).

You might argue that the secondary cannot be used outside Emacs very easily,
whereas the clipboard can.  That's true, but I don't miss it in practice.  I can
easily paste from the kill ring to other apps, and I can easily transfer the
secondary to the region in Emacs if I want to paste that outside Emacs.

[For me:
 `C-M-y' yanks the secondary.
 `C-0 C-M-y' selects the secondary as the region.
 `C-1 C-M-y' turns the region into the secondary.
   (IOW, it defines the secondary using the keyboard.)
 `C-- C-M-y' swaps the secondary with the region.
   (IOW it puts the secondary where the region is now.)
 http://www.emacswiki.org/emacs/SecondarySelection#secondary-sel.el]


In the few weeks that Emacs has been broken by the recent changes, I've already
tried unsuccessfully many times to paste/yank text that I had selected
previously, because mouse selection and pasting is now separate from keyboard
selection and yanking.  I cannot count the number of times that I've ended up
pasting/yanking nothing or text other than what was expected.  Including when
trying to paste Emacs text outside of Emacs.

> > It's amazing to me that we've gotten this far along with no 
> > proposal, discussion, and argument about pros & cons for users.
> 
> FWIW, the above URL was posted here long ago.  All the info you are
> looking for is there.

When it was posted long ago I read it.  I'm still waiting for a simple Emacs
recipe - a description in operational, user terms.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <stephen@xemacs.org>, <cyd@stupidchicken.com>, <jan.h.d@swipnet.se>,
>         <emacs-devel@gnu.org>, <david@harpegolden.net>
> Date: Sun, 15 Aug 2010 16:01:33 -0700
> 
> > FWIW, the above URL was posted here long ago.  All the info you are
> > looking for is there.
> 
> When it was posted long ago I read it.  I'm still waiting for a simple Emacs
> recipe - a description in operational, user terms.

The info there is very clear for Emacs as well.  If you don't
understand it, someone else will have to make the extra effort to make
it clear for you, sorry.  I simply have no time to explain things that
are very clear to me.

RE: Selection changes in revno 100822

[Stephen J. Turnbull]

Drew Adams writes:
 > >  > Mouse-2 _was_ pasting until very recently.
 > > That's because of the (bogus) historical association of the
 > > selection with the kill-ring in Emacs.  Good riddance, IMO.

 > Reason?  Emacs has always had that feature (as long as I can
 > remember, at least).  And IMO it is a positive, handy feature.  I
 > take advantage of it all the time.
 > 
 > Why is it "bogus"?  What is gained by losing the ability to yank
 > from the kill ring using the mouse?

Who's suggesting you lose that ability?  If you want that ability,
that's fine with me.

;; This works in XEmacs, I dunno about Emacs
(define-key global-map 'mouse-2 #'mouse-yank)

The "bogus association" I'm referring to is where Emacsen copy the X
primary selection to the kill ring under certain circumstances.  This
tends to pollute the kill ring (or other clipboard feature) with
ephemeral text.

 > Why care so much about X11 (or Windows or...)?  Why not define the
 > best interaction for _Emacs_ itself?  From the descriptions here of
 > the X behavior, I see no advantage over the traditional Emacs
 > behavior regarding selection, copying, killing, and yanking.

I understand that.  But then, you're Helen Keller, a genius, but blind
nevertheless.  If you had the X behavior available, I suspect you
would use it increasingly frequently and come to appreciate it.

 > I don't think anyone has explained the advantage for Emacs users
 > _in Emacs_.

There are two kinds of copying, cutting, and pasting.  The first is
ephemeral, for example twiddling text.  In my global-map, this is
a single operation, bound to C-t, M-t, C-M-t, etc.  The obvious (to
me, anyway) mouse gesture to implement transpositions is drag and
drop.  This should not affect the kill ring.  Similarly, I'd like a
non-kill-ring-polluting copy/paste, which is what binding mouse-2 to
x-insert-selection should do IMO.

 > Why should it be all-important for Emacs to limit its user
 > interaction to what X11 defines?

Please reread the thread.  Eli asked us to focus on X Windows behavior
because (1) it's the most flexible, and (2) it's the window system
implemented as free software.

I believe that (1) is a *fact*; X11 is capable of implementing, using
standardized protocols, all of the selection-oriented capabilities of
both Windows and Mac OS X that I know of.  If you know otherwise,
please inform me.

 > It is far more important that Emacs user interaction be useful and
 > _internally_ consistent than that it be the same as what some app
 > or window mgr might define.

That's disingenuous, Drew, and you should know better.  In fact in
modern environments certain conventions are *extremely* widespread and
accurately implemented by almost all applications.  In the case of the
PRIMARY selection on X, *all* applications (except Emacsen, to my
knowledge) *implement* the lightweight model of the PRIMARY selection.
Those that want to emphasize the clipboard can (and do) do so, via the
standardized CLIPBOARD selection.

 > X-standardization of Emacs is not my goal.  If it is the proposed
 > goal here, then please provide some user-oriented arguments.  Tell
 > us what _users_ gain and what they lose by such a change.

Conformance to X behavioral standards is not an Emacs goal, as stated
by anyone in this thread AFAICR.  What Eli requested is that we
discuss what behavior should be implemented in terms of targeting the
X platform, and worry about translating that to the other platforms.
Of course it is a *very* good idea to conform to various X standards
for *implementation* of the chosen behavior, because that maximizes
the ability to communicate what Emacs needs and offers to other apps.

 > "Supposed" by whom?  That question seems to be the elephant in the
 > room.

You obviously haven't read and comprehended my posts.  The _primary
selection_ on X is *defined* by the X protocol to be a _region_ on a
_screen_ of a _display_.  The underlined terms are all terms of art in
X with precise definitions, and I'm using them that way.  I made that
pretty clear, but I guess not clear enough.  Read my lips: in this
post, and in preceding posts, when talking about terms with precise
definitions in the X Window System, I use those definitions.

All of the window systems I use (X, MS Windows, Mac OS X) have a
protocol analogous to the X primary selection.  In the X standards,
the protocol deliberately makes no provision for automatic persistence
of the primary selection in the face of changes.  It's WYSIWYG, and
therefore ephemeral: if the highlighted part of the screen changes or
moves, so does the selection.  A separate selection, the CLIPBOARD
selection, is provided for users who want some degree of automatic
persistence.  (Unlike Windows and Mac, the X protocol for CLIPBOARD is
very abstract; the various X desktop environments have more or less
sensibly settled on imitating Windows and Mac clipboard protocols for
concrete implementations.)

In the case of drag and drop, *all* of the window systems do treat
the (analogue to the) primary selection as emphemeral; they do not
copy to a clipboard or other persistence mechanism (except in the case
of the drop target being a clipboard, of course).  This is an
observable fact, not an opinion or suggested policy.

 > X11 has not bought Emacs, AFAIK, so why act as if Emacs is being
 > swallowed?

Drew, you're hallucinating.  Calm down, and throw that blotter in the
shredder.  Focusing on X has two purposes: figuring out what *can* be
implemented, and working out the implementation on the free platform.
That's what Eli said, and AFAIK nobody has said differently, although
several people advocate the position that "it would be nice if" Emacs
could conform to traditional X practice in this regard, especially
where it doesn't conflict with desired Emacs practice.

Granted, I'm willing to go somewhat farther and say that the
traditional Emacs practice is relatively undesirable, and should be
made a non-default option.  Nothing wrong with me having an opinion
and expressing it, is there?

 > Who says so?  Not Emacs.  Not until now.  Emacs has traditionally
 > associated mouse-2 pasting with yanking the head of the kill ring.

And it still can.  What I object to is the automatic association of
the content of the primary selection with the kill ring.  It's a
bloody annoyance to some users, hard to specify sanely, and really
difficult to implement correctly and efficiently even if you have a
precise specification, even on X where "primary selection" is a
defined concept, and not a mere analogue to a concept from an alien
window system.

It is true that Emacs users on X learn to stop using the selection as
it was designed to be used.  Their heads stop hurting, the blood on
the hammer dries, and they even convince themselves they like the
change.

 > That might not be what is interesting to X11, but it is interesting
 > to Emacs and Emacs users.

To some of them.  To others, it's a bloody annoyance, and has been,
for decades.  I won't repeat what Jamie Zawinski had to say about it,
but leave it up to your imagination.  It was, uh, colorful but
uninformative.

 > > Since your hand is already on the mouse in most cases, why would
 > > you use a different interface to manipulate the selection?

 > For one thing, your hand might no longer be on the mouse when you
 > want to do that.  You seem to have a simplistic idea of mouse use.
 > 
 > Do you (Stephen) actually use both the mouse and the keyboard for
 > selecting and yanking/pasting?  Maybe not.  I do.

Yes, I do.  Until I disabled the automatic insertion of the primary
selection into the kill ring, however, the ratio was 60-40, at best
50-50, in favor of the keyboard.  Once I did that, however, I'd say I
use the mouse about 3:2 over the keyboard, and almost all of that is
due to an increase in use of the mouse to manipulate the primary
selection, not to a shift from keyboard to mouse.  If I had good DND
support within XEmacs, it would surely increase even more.

 > In fact, yanking with C-y is so handy,

Agreed.  And believe me, I've noticed how much you love repetition.  I
think we all have.  But you're unusual in that respect.

Sometimes, frequently, I want the selection on the kill ring for
various reasons, which is why in my XEmacs the popup menu has
#'copy-primary-selection as its default entry.  Click-drag-1 to select
text, mouse-3 to popup the menu, mouse-1 to copy, and Bob's your
uncle.  But I don't want everything I select and insert on the kill
ring; in fact, mostly I don't want the stuff I select and copy on the
kill ring.  Thus that's relegated to the popup menu.

FWIW, this is one of the few customizations I permit myself.  If I
allow myself to use customizationg not in the mainline, I find that I
get even more out of touch with the pain we inflict on our users.  But
this one is sufficiently important to me to break the rules.

 > even when the selection might have been made previously using the
 > mouse, that I personally do the same thing for the _secondary_
 > selection.

"Secondary selection" is a term of art in X, and in XEmacs there is no
way to access the X secondary selection in the default keymaps,
although the necessary commands are defined and I believe they work.
Is X secondary selection available by default in Emacs?  Did you
implement it?  Do you mean something else?

 > (And in Emacs, at least, the secondary selection definitely _is_
 > less ephemeral than the region, primary, and clipboard.)

If you mean the X secondary selection, that's *really* weird.  In X,
it's called "secondary" precisely because it mostly doesn't exist at
all, let alone persist.[1]  So I'd appreciate it if you'd define what you
mean by "secondary selection".

 > There seems to be an assumption here that mouse and keyboard do not
 > mix.

Not on my part.  The mouse and the keyboard are different, and
switching between them involves a small cost.  Switching often would
involve a big cost, so it's worthwhile duplicating the features
available from the keyboard on the mouse if the number of switches can
be dramatically reduced.  On the other hand, there are subtle
differences in how efficiently they can be used for different
purposes, and the default bindings should be tuned to take advantage
of those efficiencies.

 > At the very least, the traditional (superior) Emacs way should
 > still be available.

Superior to what?  Traditional X ca. 1995, with no common conventions
for clipboard use except Motif's execrably expensive protocol and the
very weak MIT xclipboard implementation?  Current Windows, with no way
to paste from the clipboard with a mouse click?  Agreed, it's superior
to those.  Superior to what could be?  Not in my experience; the
traditional Emacs way strongly discouraged me from using the mouse,
without substantially increasing the usability of the keyboard.

 > So far, all I've heard (I have not studied each mail in detail,

It would repay you in saved misunderstandings if you would do so.

Footnotes: 
[1]  AIUI, the design rationale in X was to allow you to exchange two
discontiguous selections, or copy the primary selection over the
secondary selection, obliterating the latter in the process.  AFAIK
it's rarely implemented by applications.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>,
>     <cyd@stupidchicken.com>,
>     <jan.h.d@swipnet.se>,
>     <emacs-devel@gnu.org>,
>     "'David De La Harpe Golden'" <david@harpegolden.net>
> Date: Mon, 16 Aug 2010 12:42:32 +0900
> 
> ;; This works in XEmacs, I dunno about Emacs
> (define-key global-map 'mouse-2 #'mouse-yank)

  (global-set-key [mouse-2] 'mouse-yank-at-click)

> The "bogus association" I'm referring to is where Emacsen copy the X
> primary selection to the kill ring under certain circumstances.  This
> tends to pollute the kill ring (or other clipboard feature) with
> ephemeral text.

AFAIU, in GNU Emacs (under the old behavior prior to revno 100822) the
relation between the primary selection and the kill ring was
asymmetrical: killed text would set PRIMARY, but changes in PRIMARY
would not modify the kill ring, _except_ if the user pasted it in some
manner into the current session.  The idea was that if the user pasted
the selection, it is not exactly "ephemeral" for her, and does not
constitute pollution.

> Is X secondary selection available by default in Emacs?

Yes, we have this in mouse.el:

  (global-set-key [M-mouse-1] 'mouse-start-secondary)
  (global-set-key [M-drag-mouse-1] 'mouse-set-secondary)
  (global-set-key [M-down-mouse-1] 'mouse-drag-secondary)
  (global-set-key [M-mouse-3] 'mouse-secondary-save-then-kill)
  (global-set-key [M-mouse-2] 'mouse-yank-secondary)

Re: Selection changes in revno 100822

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > The idea was that if the user pasted the selection, it is not
 > exactly "ephemeral" for her, and does not constitute pollution.

OK.  I disagree (strongly) with that assessment.  My own experience
suggests that pasting once is pretty much independent of the selection
being ephemeral, and that having an emphemeral selection encourages
use of the mouse.  Obviously the Emacs maintainers are in a better
position to make it for Emacs than I am.

 > > Is X secondary selection available by default in Emacs?
 > 
 > Yes, we have this in mouse.el:
 > 
 >   (global-set-key [M-mouse-1] 'mouse-start-secondary)
 >   (global-set-key [M-drag-mouse-1] 'mouse-set-secondary)
 >   (global-set-key [M-down-mouse-1] 'mouse-drag-secondary)
 >   (global-set-key [M-mouse-3] 'mouse-secondary-save-then-kill)
 >   (global-set-key [M-mouse-2] 'mouse-yank-secondary)

Ah, OK.  That would explain Drew's observation that the secondary is
more persistent than the primary, if it only gets set when somebody
intentionally sets it, and then it just stays that way.  I would
rarely want that behavior, personally.  I expect/would want it to be a
"fat cursor" for a drop target, either to exchange the two selections
or to overwrite the secondary with the primary.  Use of the secondary
is certainly a feature that could be independent of multiple kill
rings.

Again, a matter of personal preference.  Maybe I'll try enforcing it
on a couple of XEmacs betas and listen for howls of anguish.  Of
course, I expect none. :-)

Re: Selection changes in revno 100822

[Manoj Srivastava]

Hi,

        I compiled an emacs from CVS a few minutes ago, and ran with
 ./src/emacs -Q. I tried three methods of selecting text:

  1) Click  down-mouse-1 at start fo text, click down-mouse-3 at end of text 
  2) Drag mouse-1 from start to end of text
  3) move point to start of text, hit C-SPX, move cursor to end of text,
     and hit M-w

        I tried the following combinations:
1 Select with mouse, paste with mouse
   Works fine

2 Drag with mouse, paste with mouse
  Works fine

3 Select with M-w, yank with C-y
  Works as well

4 Select with M-w, Paste with mouse
  Works fine

5 Select with mouse, yank with C-y
  Works

6 Drag (or double click) with mouse, yank with C-y
  Does not work

        What do I set to  allow this mouse drag (which does highlight
 text)  to be yanked when I hit C-y? (I do want to be able to yank text
 I see high lighted, whether the highlighting happened by any of the
 three methods above).

        As an end user, I don't know whether the highlighted text I see
 goes into Primary, Secondary, or clipboard (I use X windows on a
 GNU/Linux machine). I see it highlighted, and am very confused as to why
 it sometimes does not yank with C-y. I find this inconsistency in Emacs
 confusing.

        manoj
-- 
If at first you don't succeed, destroy all evidence that you tried.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Re: Selection changes in revno 100822

[Miles Bader]

Manoj Srivastava <srivasta@ieee.org> writes:
>         As an end user, I don't know whether the highlighted text I
>  see goes into Primary, Secondary, or clipboard (I use X windows on a
>  GNU/Linux machine). I see it highlighted, and am very confused as to
>  why it sometimes does not yank with C-y. I find this inconsistency in
>  Emacs confusing.

Can you try:

   (setq x-select-enable-clipboard t)
   (setq x-select-enable-primary t)

They make things work better for me.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Selection changes in revno 100822

[Manoj Srivastava]

On Mon, Aug 16 2010, Miles Bader wrote:

> Manoj Srivastava <srivasta@ieee.org> writes:
>>         As an end user, I don't know whether the highlighted text I
>>  see goes into Primary, Secondary, or clipboard (I use X windows on a
>>  GNU/Linux machine). I see it highlighted, and am very confused as to
>>  why it sometimes does not yank with C-y. I find this inconsistency in
>>  Emacs confusing.
>
> Can you try:
>
>    (setq x-select-enable-clipboard t)
>    (setq x-select-enable-primary t)
>
> They make things work better for me.

        Thanks. That did work; and I think that ought to be the default
 if we detect that the window-system is X, but I am content now that I
 know how to get things working as I wanted.

        I still find the doc string of select-active-regions to be
 unclear, since I am not sure when "deactivate-mark" happens, and I
 suspect most users would also not know. Could the documentation be
 clarified as to what the user visible changes that setting it to 'lazy vs
 setting it to t are?

        thanks

        manoj
-- 
Wait for that wisest of all counselors, Time. Pericles
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Re: Selection changes in revno 100822

[Miles Bader]

Manoj Srivastava <srivasta@ieee.org> writes:
>>    (setq x-select-enable-clipboard t)
>>    (setq x-select-enable-primary t)
>>
>> They make things work better for me.
>
>         Thanks. That did work; and I think that ought to be the default
>  if we detect that the window-system is X

Me too, but others feel differently.

-Miles

-- 
Resign, v. A good thing to do when you are going to be kicked out.

Re: Selection changes in revno 100822

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Manoj Srivastava <srivasta@ieee.org> writes:
>>>    (setq x-select-enable-clipboard t)
>>>    (setq x-select-enable-primary t)
>>>
>>> They make things work better for me.
>>
>>         Thanks. That did work; and I think that ought to be the default
>>  if we detect that the window-system is X
>
> Me too, but others feel differently.

I seem to remember that the clipboard, as opposed to the selection,
required actively transmitting the content at the time of selection.
Since most selections are not going to be pasted (in particular all
temporary selections during something like shift-selection), that is a
performance issue, particularly on non-local X displays.

The selection, in contrast, needs transmission to the X server only if
it is being pasted.

I may be wrong, but I think there is definitely some performance issue
involved with the defaults.

-- 
David Kastrup

Re: Selection changes in revno 100822

[Jan Djärv]

2010-08-16 13:27, David Kastrup skrev:

> I seem to remember that the clipboard, as opposed to the selection,
> required actively transmitting the content at the time of selection.
> Since most selections are not going to be pasted (in particular all
> temporary selections during something like shift-selection), that is a
> performance issue, particularly on non-local X displays.
>
> The selection, in contrast, needs transmission to the X server only if
> it is being pasted.
>

This is only an issue if you run a clipboard hoarding program like klipper 
that tries to copy clipboard as soon as a program changes it.

> I may be wrong, but I think there is definitely some performance issue
> involved with the defaults.
>

The default (i.e. no klipper) don't really care what the selections are 
called.  They are all treated the same by the X server.  You can create your 
own selections and they will be treated just as PRIMARY/CLIPBOARD/SECONDARY by 
the X server. The drag and drop protocl Xdnd has its own selection for example.

	Jan D.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 18:21:05 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: cyd@stupidchicken.com, jan.h.d@swipnet.se, emacs-devel@gnu.org
> 
> clipboards aren't overwritten when you merely select text.
> clipboards are overwritten when you cut/copy (C-x/C-c)
> clipboards are not inserted when you click mouse-2.
> clipboards are inserted when you paste (C-v)
> (w32 clipboard, ns general pasteboard, x11 clipboard*).
> 
> primary selections are overwritten when you merely select text.
> primary selections are not overwritten when you cut/copy (C-x/C-c) (but 
> they've probably already just been overwritten because you selected text 
> just before you cut/copied).
> primary selections are inserted when you click mouse-2.
> primary selections are not inserted when you paste (C-v)

I see the logic and consistency of this, but that's not how Emacs
behaves, as of now, on X.  Cutting text does overwrite the primary
selection, probably due to select-active-regions being `lazy' by
default.  There's also a fundamental asymmetry in that C-w puts text
into the primary selection, but C-y does not yank it back.

As long as Emacs does not behave according to the above scheme, you
cannot use it as an argument to approve or reject certain behaviors
that contradict that scheme.

Re: Selection changes in revno 100822

[Jan Djärv]

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



14 aug 2010 kl. 17:18 skrev Eli Zaretskii <eliz@gnu.org>:

> 
> May I suggest to step back and post a clear set of requirements for
> when Emacs should and shouldn't put selected text into the primary
> selection and into the clipboard?  Forget the w32 case for now; let's
> just spell out the requirements for X.
> 

Good idea. Also spell out if selecting text by different mechanisms (mouse, shift- select, C-@ movement) shall behave differently.
 

> What behavior is that?  What other apps have something similar to the
> kill ring?
> 

X or Freedesktop does not say anything about things like the kill ring. 
We can do what we want here.


     Jan D.


[-- Attachment #2: Type: text/html, Size: 1294 bytes --]

Re: Selection changes in revno 100822

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> May I suggest to step back and post a clear set of requirements for
> when Emacs should and shouldn't put selected text into the primary
> selection and into the clipboard?  Forget the w32 case for now; let's
> just spell out the requirements for X.

Here is a summary of the current scheme:

  1. Each time the mark is deactivated, the selected text is added to
  the primary selection.  If deactivation occurs as a result of a buffer
  modification, the text that is added is the text in the region prior
  to the modification.

  2. If the region is temporarily active after a command (e.g. after a
  mouse drag or shift selection), the selected text is added to the
  primary selection, even if the mark is not deactivated.

  3. If you deactivate the mark with C-g, the selected text is not added
  to the primary selection.

  4. Any kill command sets clipboard in addition to the kill-ring; any
  yank command inserts the clipboard contents, if possible
  (x-select-enable-clipboard).

  5. mouse-2 yanks primary.

The result of this is that shift-selection and mouse drags set primary,
similar to other X applications.  Also, if you use C-SPC and cursor
motion to select region and then type C-w, that also sets primary,
similar to earlier versions of Emacs.  The latter property is the
"laziness" setting for select-active-regions.


A simpler alternative would be to replace 1-3 with:

  If the region is temporarily active after a command (e.g. after a
  mouse drag or shift selection), the selected text is added to the
  primary selection.

This is much simpler than the first scheme.  However, it does not make
any attempt to treat normal active regions and temporarily active
regions the same; normal active regions (made with C-SPC) never have
anything to do with the primary selection.  This means that if you mark
a region with C-SPC and do C-w, you won't be able to paste the text in
with mouse-2, unlike earlier Emacs versions.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: David De La Harpe Golden <david@harpegolden.net>, jan.h.d@swipnet.se,
>         emacs-devel@gnu.org
> Date: Sat, 14 Aug 2010 17:52:22 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > May I suggest to step back and post a clear set of requirements for
> > when Emacs should and shouldn't put selected text into the primary
> > selection and into the clipboard?  Forget the w32 case for now; let's
> > just spell out the requirements for X.
> 
> Here is a summary of the current scheme:
> 
>   1. Each time the mark is deactivated, the selected text is added to
>   the primary selection.  If deactivation occurs as a result of a buffer
>   modification, the text that is added is the text in the region prior
>   to the modification.
> 
>   2. If the region is temporarily active after a command (e.g. after a
>   mouse drag or shift selection), the selected text is added to the
>   primary selection, even if the mark is not deactivated.
> 
>   3. If you deactivate the mark with C-g, the selected text is not added
>   to the primary selection.

This is not the level on which I wanted to discuss this.  You are
describing the behavior in terms of deactivating the mark, which is an
implementation detail.  I'm sure you have a very clear idea when the
mark gets deactivated, but my idea about that is somewhat vague, and
I'm quite sure many users have no idea at all about that.

From the user's perspective, there are several ways of selecting text:
with C-SPS (with or without transient-mark-mode), with
shift-selection, and with the mouse.  Let's talk on this level: which
methods should set the primary and which shouldn't, and why?

Re: Selection changes in revno 100822

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> From the user's perspective, there are several ways of selecting text:
> with C-SPS (with or without transient-mark-mode), with
> shift-selection, and with the mouse.  Let's talk on this level: which
> methods should set the primary and which shouldn't, and why?

* For consistency with other apps which set the primary, it seems that
  mouse-drag should set the primary.  Shift-select also seems to set the
  primary in some other apps (firefox), but I have fewer such apps to try.

* For consistency within Emacs, C-SPC <movement> in transient-mark-mode
  should set the primary.

* For C-SPC <movement> _not_ in transient-mark-mode, I think it
  _shouldn't_ set the primary, since "selection" in this mode is
  visually very distinct from the above types of selection (I don't
  think users are likely to be confused by this).

Users _shouldn't have to think very hard about this_, and thus simple
rules are important.  In this case I think a good simple rule is:

   If you _see_ a selected region in Emacs (no matter how it was
   selected), it's available as the primary for pasting in other apps.

-Miles

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sun, 15 Aug 2010 10:11:16 +0900
> 
> Users _shouldn't have to think very hard about this_, and thus simple
> rules are important.  In this case I think a good simple rule is:
> 
>    If you _see_ a selected region in Emacs (no matter how it was
>    selected), it's available as the primary for pasting in other apps.

That's something I had in mid, too, so I very much agree.

Re: Selection changes in revno 100822

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Miles Bader <miles@gnu.org>
>> Date: Sun, 15 Aug 2010 10:11:16 +0900
>>
>> Users _shouldn't have to think very hard about this_, and thus simple
>> rules are important.  In this case I think a good simple rule is:
>>
>>    If you _see_ a selected region in Emacs (no matter how it was
>>    selected), it's available as the primary for pasting in other apps.
>
> That's something I had in mid, too, so I very much agree.

It's a convincing argument, leaving the issue of efficiency aside for
the moment.  The rule, however, should be something like:

>>    If you _change_ a selected region in Emacs (no matter how it was
>>    selected), it's available as the primary.

That's because if you make a selected region in one application, and
then select some text in a second application, the second application
grabs primary.

Anyway, we can give this a try as the default.

Instead of "lazy" setting, we can provide an optional (non-default)
value of select-active-regions, where only shift-selection and
mouse-dragging sets primary, while C-SPC + motion does not.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Miles Bader <miles@gnu.org>, emacs-devel@gnu.org
> Date: Sun, 15 Aug 2010 11:05:45 -0400
> 
> >>    If you _see_ a selected region in Emacs (no matter how it was
> >>    selected), it's available as the primary for pasting in other apps.
> >
> > That's something I had in mid, too, so I very much agree.
> 
> It's a convincing argument, leaving the issue of efficiency aside for
> the moment.  The rule, however, should be something like:
> 
> >>    If you _change_ a selected region in Emacs (no matter how it was
> >>    selected), it's available as the primary.
> 
> That's because if you make a selected region in one application, and
> then select some text in a second application, the second application
> grabs primary.

But this is a norm on X, isn't it?  Primary selection is ephemeral; if
you want more persistence, you should use the clipboard.  Right?  Why
should Emacs behave differently?

> Anyway, we can give this a try as the default.

Yes, let's do it!

> Instead of "lazy" setting, we can provide an optional (non-default)
> value of select-active-regions, where only shift-selection and
> mouse-dragging sets primary, while C-SPC + motion does not.

Yes, except that C-SPC+motion _should_ do it when transient-mark-mode
is on (which it is, by default).

Re: Selection changes in revno 100822

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> >>    If you _see_ a selected region in Emacs (no matter how it was
>> >>    selected), it's available as the primary for pasting in other apps.
>> >
>> > That's something I had in mid, too, so I very much agree.
>
>> Anyway, we can give this a try as the default.
>
> Yes, let's do it!

OK, applied to the trunk.

Re: Selection changes in revno 100822

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> >>    If you _see_ a selected region in Emacs (no matter how it was
>>> >>    selected), it's available as the primary for pasting in other apps.
>>> >
>>> > That's something I had in mid, too, so I very much agree.
>>
>>> Anyway, we can give this a try as the default.
>>
>> Yes, let's do it!
>
> OK, applied to the trunk.

Doesn't that imply that merely visibly selecting a region is sufficient
for pasting from one Emacs instance to another, but not from one Emacs
frame to another of the same Emacs instance?

-- 
David Kastrup

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 16 Aug 2010 04:50:25 +0200
> 
> Doesn't that imply that merely visibly selecting a region is sufficient
> for pasting from one Emacs instance to another, but not from one Emacs
> frame to another of the same Emacs instance?

Pasting with mouse-2 should work inside the Emacs session as it should
outside it, AFAIU.

Re: Selection changes in revno 100822

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 16 Aug 2010 04:50:25 +0200
>> 
>> Doesn't that imply that merely visibly selecting a region is sufficient
>> for pasting from one Emacs instance to another, but not from one Emacs
>> frame to another of the same Emacs instance?
>
> Pasting with mouse-2 should work inside the Emacs session as it should
> outside it, AFAIU.

AFAIU, the highlighting in the first frame goes away when you press
mouse-2 in the second frame of the same Emacs session.  Since the
highlighting is supposedly connected with the selection, that means the
selection will no longer be taken by Emacs, and the paste will be from
the top of the kill ring.  Since the region never was entered into the
killring, the result will appear differently than pasting a highlighted
selection from a different Emacs frame (which does not lose the
selection when doing mouse-2 in a different Emacs session).

I have not yet compiled the new code, but from the description that
would appear to me to be the case.

One nuisance of typical X operation is that there is basically only one
selection that counts, but every application will have its own
highlighting/active region.  So you don't notice an application losing
the selection until you try pasting.  Since multiple Emacsen can have an
active highlighted region at the same time, they participate in that
kind of lazy silent selection loss scheme.  But I don't think that
multiple frames of the same Emacs session can have an active highlighted
region at the same time.  At least that seems to be the case in my
currently compiled Emacs.

-- 
David Kastrup

Re: Selection changes in revno 100822

[Jan Djärv]

2010-08-16 09:07, David Kastrup skrev:
> Eli Zaretskii<eliz@gnu.org>  writes:
>
>>> From: David Kastrup<dak@gnu.org>
>>> Date: Mon, 16 Aug 2010 04:50:25 +0200
>>>
>>> Doesn't that imply that merely visibly selecting a region is sufficient
>>> for pasting from one Emacs instance to another, but not from one Emacs
>>> frame to another of the same Emacs instance?
>>
>> Pasting with mouse-2 should work inside the Emacs session as it should
>> outside it, AFAIU.
>
> AFAIU, the highlighting in the first frame goes away when you press
> mouse-2 in the second frame of the same Emacs session.  Since the
> highlighting is supposedly connected with the selection, that means the
> selection will no longer be taken by Emacs, and the paste will be from
> the top of the kill ring.  Since the region never was entered into the
> killring, the result will appear differently than pasting a highlighted
> selection from a different Emacs frame (which does not lose the
> selection when doing mouse-2 in a different Emacs session).
>
> I have not yet compiled the new code, but from the description that
> would appear to me to be the case.
>

This is not so.  The selection remains, you just can't see it unless the frame 
with the selection has focus (on X at least).

Two frames on the same Emacs with the same buffer behaves badly w.r.t. the 
selection, but this is a very old problem.  I think it always behaved badly.

	Jan D.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 16 Aug 2010 09:07:59 +0200
> 
> One nuisance of typical X operation is that there is basically only one
> selection that counts, but every application will have its own
> highlighting/active region.

Is that really so?  AFAIR, when you select text in some application on
X, if another app had selected highlighted text prior to that, that
other app deselects its text and loses the highlight.  If Emacs does
not behave like that on X (i.e. is not sensitive to some other
application setting PRIMARY), perhaps it should.

> But I don't think that multiple frames of the same Emacs session can
> have an active highlighted region at the same time.  At least that
> seems to be the case in my currently compiled Emacs.

They can, if you set highlight-nonselected-windows non-nil.

Re: Selection changes in revno 100822

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Is that really so?  AFAIR, when you select text in some application on
> X, if another app had selected highlighted text prior to that, that
> other app deselects its text and loses the highlight.

Some apps do that (e.g. gnome-terminal), some do not (e.g. firefox).

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: Selection changes in revno 100822

[Jan Djärv]

2010-08-16 04:50, David Kastrup skrev:
> Chong Yidong<cyd@stupidchicken.com>  writes:
>
>> Eli Zaretskii<eliz@gnu.org>  writes:
>>
>>>>>>     If you _see_ a selected region in Emacs (no matter how it was
>>>>>>     selected), it's available as the primary for pasting in other apps.
>>>>>
>>>>> That's something I had in mid, too, so I very much agree.
>>>
>>>> Anyway, we can give this a try as the default.
>>>
>>> Yes, let's do it!
>>
>> OK, applied to the trunk.
>
> Doesn't that imply that merely visibly selecting a region is sufficient
> for pasting from one Emacs instance to another, but not from one Emacs
> frame to another of the same Emacs instance?
>

Emacs handles asking for selections from itself, so you can paste between 
frames in the same Emacs instance.

However, this isn't working correctly, I'm filing a bug report.

	Jan D.

Re: Selection changes in revno 100822

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> 2010-08-16 04:50, David Kastrup skrev:
>> Chong Yidong<cyd@stupidchicken.com>  writes:
>>
>>> Eli Zaretskii<eliz@gnu.org>  writes:
>>>
>>>>>>>     If you _see_ a selected region in Emacs (no matter how it was
>>>>>>>     selected), it's available as the primary for pasting in other apps.
>>>>>>
>>>>>> That's something I had in mid, too, so I very much agree.
>>>>
>>>>> Anyway, we can give this a try as the default.
>>>>
>>>> Yes, let's do it!
>>>
>>> OK, applied to the trunk.
>>
>> Doesn't that imply that merely visibly selecting a region is sufficient
>> for pasting from one Emacs instance to another, but not from one Emacs
>> frame to another of the same Emacs instance?
>>
>
> Emacs handles asking for selections from itself, so you can paste
> between frames in the same Emacs instance.
>
> However, this isn't working correctly, I'm filing a bug report.

I have the suspicion that it has lost the selection already when it asks
itself for it.

-- 
David Kastrup

Re: Selection changes in revno 100822

[Jan Djärv]

2010-08-16 09:09, David Kastrup skrev:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> 2010-08-16 04:50, David Kastrup skrev:
>>> Chong Yidong<cyd@stupidchicken.com>   writes:
>>>
>>>> Eli Zaretskii<eliz@gnu.org>   writes:
>>>>
>>>>>>>>      If you _see_ a selected region in Emacs (no matter how it was
>>>>>>>>      selected), it's available as the primary for pasting in other apps.
>>>>>>>
>>>>>>> That's something I had in mid, too, so I very much agree.
>>>>>
>>>>>> Anyway, we can give this a try as the default.
>>>>>
>>>>> Yes, let's do it!
>>>>
>>>> OK, applied to the trunk.
>>>
>>> Doesn't that imply that merely visibly selecting a region is sufficient
>>> for pasting from one Emacs instance to another, but not from one Emacs
>>> frame to another of the same Emacs instance?
>>>
>>
>> Emacs handles asking for selections from itself, so you can paste
>> between frames in the same Emacs instance.
>>
>> However, this isn't working correctly, I'm filing a bug report.
>
> I have the suspicion that it has lost the selection already when it asks
> itself for it.
>

No, that is not it.  If I make a new selection in another frame without 
setting point, the old one gets pasted with mouse-2.

	Jan D.

RE: Selection changes in revno 100822

[Drew Adams]

> Users _shouldn't have to think very hard about this_,

I sure agree with that.

Just to check, however: Do you think that Emacs users have had to think very
hard in the past about this?  I don't think so - I think Emacs copy/cut/paste
(kill/yank) has been pretty simple to learn and use - both for keyboard and
mouse.

(I do agree with some of your observations in the last year or two that this has
gotten somewhat less straightforward, notably wrt Shift selection etc.)

> simple rules are important... a good simple rule is:
> 
>    If you _see_ a selected region in Emacs (no matter how it was
>    selected), it's available as the primary for pasting in other apps.

I'm not sure I understand you right, but it sounds like you're saying that
someone who wants to repeatedly paste/yank the same bit of text, whether using
mouse-2 or C-y, would have to re-activate the region each time before doing so,
so that it first becomes visible.

If that's what you mean, then it sounds a whole lot less convenient than what
Emacs has offered users in the past.  No matter how you select text, you have
always been able to paste/yank it repeatedly using either mouse-2 or C-y,
without caring whether the region is visible.

(I'm not distinguishing paste from yank or mouse-2 from C-y here.  I imagine
that you are.  But I'm not sure that matters for what I want to say in this
regard.)

Re: Selection changes in revno 100822

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> simple rules are important... a good simple rule is:
>> 
>>    If you _see_ a selected region in Emacs (no matter how it was
>>    selected), it's available as the primary for pasting in other apps.
>
> I'm not sure I understand you right, but it sounds like you're saying that
> someone who wants to repeatedly paste/yank the same bit of text, whether using
> mouse-2 or C-y, would have to re-activate the region each time before doing so,
> so that it first becomes visible.

No, I'm not saying that.  I'm commenting on how the primary selection
gets set; that shouldn't affect other parts of emacs cut/paste
(e.g. C-y) at all...

-Miles

-- 
Cannon, n. An instrument employed in the rectification of national boundaries.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 14 Aug 2010 21:48:53 -0700
> Cc: 
> 
> I'm not distinguishing paste from yank or mouse-2 from C-y here.

You should: it sounds like the plan is to make them different, as that
is how other applications behave on X nowadays.  I don't envy whoever
will need to change the manual to reflect the new behavior.

Re: Selection changes in revno 100822

[Stephen J. Turnbull]

Miles Bader writes:

 >    If you _see_ a selected region in Emacs (no matter how it was
 >    selected), it's available as the primary for pasting in other
 >    apps.

But that is normally *not true* in Windows, without C-c or C-x (or the
menu equivalents) first.  The traditional Windows interface for
pasting the primary is drag and drop, not C-v.  C-v will replace the
primary without saving it, with the current content of the clipboard.

See my reply to Eli for more detail on why this is so.

If you want X11 and Windows (and Mac, for that matter) to have similar
interfaces here, then you could disable middle-click-to-paste (by
default) on X11, and use "drag to paste" consistently.  For
consistency with Mac and Windows behavior, almost surely drag to paste
within a buffer should *move* the content, while drag to paste to a
different app should certainly *copy* the content.  Drag to paste
between Emacs buffers I'm not sure about, but I suspect that should
mostly copy.  (Dragging between Dired buffers probably ought to *move*
the file, OTOH.)

Of course wizened (or seasoned) X users probably would want to
reenable middle click to paste.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 15 Aug 2010 23:04:10 +0900
> Cc: emacs-devel@gnu.org
> 
> Miles Bader writes:
> 
>  >    If you _see_ a selected region in Emacs (no matter how it was
>  >    selected), it's available as the primary for pasting in other
>  >    apps.
> 
> But that is normally *not true* in Windows, without C-c or C-x (or the
> menu equivalents) first.

Miles was talking about X, not about Windows; and so was I.  We need
to decide on behavior on X before we decide how to map that to
Windows.

> The traditional Windows interface for
> pasting the primary is drag and drop, not C-v.  C-v will replace the
> primary without saving it, with the current content of the clipboard.
> 
> See my reply to Eli for more detail on why this is so.

See my message near the beginning of this thread, where I said that on
Windows Emacs should not by default set the clipboard upon selection.

> If you want X11 and Windows (and Mac, for that matter) to have similar
> interfaces here, then you could disable middle-click-to-paste (by
> default) on X11, and use "drag to paste" consistently.

IMO, that would be bad for users on X, because mouse-2 pasting from
PRIMARY is standard there.

As of yesterday, mouse-2 on Windows pastes from the clipboard (and
falls back on the emulated PRIMARY if the clipboard is empty).  I
think this is a reasonable compromise, in that it makes Emacs behave
quite consistently, at least as far as user expectations go.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 15/08/10 16:20, Eli Zaretskii wrote:

> As of yesterday, mouse-2 on Windows pastes from the clipboard (and
> falls back on the emulated PRIMARY if the clipboard is empty).

Er... really? Did you mean paste from the emulated primary and fall back 
to the clipboard?

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sun, 15 Aug 2010 18:27:37 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: "Stephen J. Turnbull" <stephen@xemacs.org>, emacs-devel@gnu.org, 
>  miles@gnu.org
> 
> On 15/08/10 16:20, Eli Zaretskii wrote:
> 
> > As of yesterday, mouse-2 on Windows pastes from the clipboard (and
> > falls back on the emulated PRIMARY if the clipboard is empty).
> 
> Er... really? Did you mean paste from the emulated primary and fall back 
> to the clipboard?

No, I meant what I said:

  (let ((primary
         (cond
          ((fboundp 'x-get-selection-value) ; MS-DOS and MS-Windows
           (or (x-get-selection-value)
               (x-get-selection 'PRIMARY)))
          ;; FIXME: What about xterm-mouse-mode etc.?
          (t
           (x-get-selection 'PRIMARY)))))

Unless I'm seriously confused, x-get-selection-value accesses the
clipboard, see w32-fns.el.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 15/08/10 18:59, Eli Zaretskii wrote:
>> Date: Sun, 15 Aug 2010 18:27:37 +0100
>> From: David De La Harpe Golden<david@harpegolden.net>
>> CC: "Stephen J. Turnbull"<stephen@xemacs.org>, emacs-devel@gnu.org,
>>   miles@gnu.org
>>
>> On 15/08/10 16:20, Eli Zaretskii wrote:
>>
>>> As of yesterday, mouse-2 on Windows pastes from the clipboard (and
>>> falls back on the emulated PRIMARY if the clipboard is empty).
>>
>> Er... really? Did you mean paste from the emulated primary and fall back
>> to the clipboard?
>

Ah, w32 x-get-selection-value is only returning the clipboard the first 
time it is called, subsequent calls return nil if the clipboard is 
unchanged, it's following the interprogram-paste-function  protocol.

I thought you meant you were inserting the clipboard if the clipboard 
was nonempty every time, and was wondering how that made any sense given 
AFAIK the w32 clipboard is seldom empty except momentarily when it's 
just been emptied before an app puts something on it, so the emulated 
primary would basically never be inserted.

Still, I'm not at all sure this is what you wanted, even leaving aside 
higher-level "david thinks it's fundamentally wrong"* issues:

A C-y after such a mouse-2 won't insert the current w32 clipboard unless 
it has changed since the mouse-2, because it's already been "consumed" 
(put on w32 x-last-selected-text)   Nor will the mouse-2 have put it on 
the kill ring, so it won't be available via M-y either.
What happens when you press mouse-2 twice in a row when it's inserted 
from the w32 clipboard.

All a tad weird for my taste, but /I/ don't have to use it.

* I _still_ think it'd be better to bind mouse-2 back to 
mouse-yank-at-click, then supply customizations that allow control over 
whether mouse-yank-at-click gets from the primary, the clipboard (or 
both), and whether it side-effects the kill-ring (pushes what it just 
got onto it
as well as inserting it into the buffer).

Then on w32, w32-specific defaults to those customizations could mean 
mouse-2 could then get from the clipboard, maybe even side effect the 
kill-ring, until such a time as w32's primary is ready.

Seems I started proposing something like that around Feb 2008*, so, 
well, obviously I'm failing to communicate why it's desirable.

At the time, I used the variable names:

(mouse-yank-enable-kill-ring nil)
(mouse-yank-enable-system-clipboard nil)
(mouse-yank-enable-system-current-selection t)


* See (emacs-devel list archive isn't responding for me, sorry no link):

Message-ID: <8e24944a0802161938i736d4bb2x854e37a4042076bb@mail.gmail.com>
Date: Sun, 17 Feb 2008 03:38:14 +0000
From: "David De La Harpe Golden" <david.delaharpe.golden@gmail.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Subject: Re: Improving X selection?
Cc: "Horsley, Tom" <Tom.Horsley@ccur.com>,
	"Stephen J. Turnbull" <stephen@xemacs.org>,
	"Jan D." <jan.h.d@swipnet.se>, rms@gnu.org, emacs-devel@gnu.org
In-Reply-To: <jwvk5lfczjk.fsf-monnier+emacs@gnu.org>

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sun, 15 Aug 2010 20:50:23 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: stephen@xemacs.org, emacs-devel@gnu.org, miles@gnu.org
> 
> Ah, w32 x-get-selection-value is only returning the clipboard the first 
> time it is called, subsequent calls return nil if the clipboard is 
> unchanged, it's following the interprogram-paste-function  protocol.

Right.  The same happens with the DOS version of
x-get-selection-value.

> A C-y after such a mouse-2 won't insert the current w32 clipboard unless 
> it has changed since the mouse-2, because it's already been "consumed" 
> (put on w32 x-last-selected-text)   Nor will the mouse-2 have put it on 
> the kill ring, so it won't be available via M-y either.

This is because mouse-2 no longer calls `yank'.  It's unrelated to the
change I made, which was the minimal change to get mouse-2 back to
Windows users.  This is a temporary change; I intend to start a
discussion about some of the fallout issues when the dust settles a
bit.

> What happens when you press mouse-2 twice in a row when it's inserted 
> from the w32 clipboard.

What happens when you do that on X?  What happens on X when you type
C-y after mouse-2?

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 15/08/10 21:19, Eli Zaretskii wrote:


>> What happens when you press mouse-2 twice in a row when it's inserted
>> from the w32 clipboard.
>
> What happens when you do that on X?

Press mouse-2 twice? primary inserted twice.

> What happens on X when you type
> C-y after mouse-2?

You get a clipboard/kill-ring yank.  The mouse-2 primary insertion 
preceding is pretty irrelevant to the process other than the fact it 
will have set the point to just after the thing it just inserted.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sun, 15 Aug 2010 21:40:35 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: stephen@xemacs.org, emacs-devel@gnu.org, miles@gnu.org
> 
> On 15/08/10 21:19, Eli Zaretskii wrote:
> 
> 
> >> What happens when you press mouse-2 twice in a row when it's inserted
> >> from the w32 clipboard.
> >
> > What happens when you do that on X?
> 
> Press mouse-2 twice? primary inserted twice.

Then that's a difference between X and w32, after my change.
Shouldn't be hard to fix if people want to have the text inserted each
time.

> > What happens on X when you type
> > C-y after mouse-2?
> 
> You get a clipboard/kill-ring yank.

That's identical to what you get on w32 with my change.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 15/08/10 22:13, Eli Zaretskii wrote:


>>> What happens on X when you type
>>> C-y after mouse-2?
>>
>> You get a clipboard/kill-ring yank.
>
> That's identical to what you get on w32 with my change.

Um. Copy some text in notepad.exe, then hit mouse-2 in emacs.exe, then 
C-y, hopefully you'll see the problem. Or maybe you'll decide it's a 
feature.

e.g.

"I am a fish" select it then M-w copy in emacs

"hello there" select it then C-c copy in notepad

mouse-2 in emacs =>
"hello there" inserted in emacs (inserting the current w32 clipboard)

C-y in emacs =>
"I am a fish" inserted in emacs (not inserting the current w32 clipboard 
but rather the head of emacs kill ring. I would have expected the 
current w32 clipboard, as an x11 user).

C-v in notepad =>
"hello there" inserted in notepad (inserting the current w32 clipboard)



*** Then there's:

"I am a duck" select it in emacs

"goodbye then" C-c copy in notepad

mouse-2 in emacs =>
"goodbye then" inserted in emacs (inserting the current w32 clipboard)

mouse-2 in emacs =>
"I am a duck" inserted in emacs (inserting the emacs emulated primary 
selection)

C-v in notepad =>
"goodbye then" inserted in notepad (inserting the current w32 clipboard)

RE: Selection changes in revno 100822

[Drew Adams]

> "I am a fish" select it then M-w copy in emacs
> "hello there" select it then C-c copy in notepad
> mouse-2 in emacs =>
> "hello there" inserted in emacs
>   (inserting the current w32 clipboard)
> C-y in emacs =>
> "I am a fish" inserted in emacs
>   (not inserting the current w32 clipboard but rather the
>    head of emacs kill ring. I would have expected the 
>    current w32 clipboard, as an x11 user).
> C-v in notepad =>
> "hello there" inserted in notepad
>   (inserting the current w32 clipboard)
> 
> "I am a duck" select it in emacs
> "goodbye then" C-c copy in notepad
> mouse-2 in emacs =>
> "goodbye then" inserted in emacs
>   (inserting the current w32 clipboard)
> mouse-2 in emacs =>
> "I am a duck" inserted in emacs
>   (inserting the emacs emulated primary selection)
> C-v in notepad =>
> "goodbye then" inserted in notepad
>   (inserting the current w32 clipboard)

Thank you, David.  That is precisely the kind of example that makes clear the
behavior, whether problematic and unintentional as (presumably) in this case or
intended as part of the proposed changes.

The parenthetical references to "primary" and "clipboard" are just that:
parenthetical, accessory.  The behavior is 100% understandable to an Emacs user
without those references (even if the refs might help some people who are
familiar with the terms to understand better).

Let's please see more such operational description.  Tell us what the proposed
changes (all of them) mean in just such user-behavior terms, please.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sun, 15 Aug 2010 22:42:56 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: stephen@xemacs.org, emacs-devel@gnu.org, miles@gnu.org
> 
> On 15/08/10 22:13, Eli Zaretskii wrote:
> 
> 
> >>> What happens on X when you type
> >>> C-y after mouse-2?
> >>
> >> You get a clipboard/kill-ring yank.
> >
> > That's identical to what you get on w32 with my change.
> 
> Um. Copy some text in notepad.exe, then hit mouse-2 in emacs.exe, then 
> C-y, hopefully you'll see the problem. Or maybe you'll decide it's a 
> feature.

It's a consequence of the fact that there's only one interprogram
selection on Windows.  No matter how hard we try, we cannot get 100%
compatibility with X here, only come close.

What you describe matches my expectations for Windows.  Maybe that's
just me; time will tell.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 15/08/10 15:04, Stephen J. Turnbull wrote:

> If you want X11 and Windows (and Mac, for that matter) to have similar
> interfaces here, then you could disable middle-click-to-paste (by
> default) on X11, and use "drag to paste" consistently.
>
> Of course wizened (or seasoned) X users probably would want to
> reenable middle click to paste.

In practice, on x11, the drag/drop you describe typically coexists 
happily with middle-click-paste-selection.

While the w32 text drag and drop is indeed a bit more like an x11 
primary than the w32 clipboard is in terms of effect and purpose, in 
actual implementation terms on x11, 'XdndSelection and 'PRIMARY are 
again different x11 selections (former is already handled somewhat by 
x11 emacs* lisp/x-dnd.el, though x11 emacs doesn't appear to allow 
intra-emacs text drag/drop, it does appear to accept text dragged into 
it), so there is an analog of the w32 drag/drop on x11 and it's the x11 
drag/drop rather than x11 primary as such.

Mind you, the XDND spec does then go on to suggest as an extension 
making allowance for older apps that don't support XDND (citing emacs as 
an example, I guess wouldn't have at the time it was written) by 
simulating a middle click into them on the assumption they will try to 
yank primary when they see the simulated middle click, and responding to 
the ensuing matched (via known timestamps) request for the primary as if 
it was request for the XdndSelection. Which is a bit of a bodge, I don't 
presently know if dnd-source x11 apps in the wild typically implement 
that bit.

It is likely possible to reuse various w32 bits and pieces (actually in 
the rat's nest of w32 apis there's probably quite a few different ways) 
to produce a w32 primary-oid that works inter-application for 
applications that know to look for it (presumably other emacs sessions).


[* Actually there's more than one protocol for DnD on x11, just to 
complicate matters, but x11 emacs also supports the motif one]

Re: Selection changes in revno 100822

[James Cloos]

>>>>> "MB" == Miles Bader <miles@gnu.org> writes:

MB> * For consistency within Emacs, C-SPC <movement> in transient-mark-mode
MB>   should set the primary.

MB> * For C-SPC <movement> _not_ in transient-mark-mode, I think it
MB>   _shouldn't_ set the primary, since "selection" in this mode is
MB>   visually very distinct from the above types of selection (I don't
MB>   think users are likely to be confused by this).

MB> Users _shouldn't have to think very hard about this_, and thus simple
MB> rules are important.  In this case I think a good simple rule is:

MB>    If you _see_ a selected region in Emacs (no matter how it was
MB>    selected), it's available as the primary for pasting in other apps.

That is exactly the right thing to do.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Selection changes in revno 100822

[Stefan Monnier]

>    If you _see_ a selected region in Emacs (no matter how it was
>    selected), it's available as the primary for pasting in other apps.

That was my reasoning for arguing it should be handled in
a redisplay-hook.


        Stefan

RE: Selection changes in revno 100822

[Drew Adams]

> Here is a summary of the current scheme:

First, thanks for this summary.  It doesn't seem complete, but it is a start,
helping us understand what is being proposed.

>   1. Each time the mark is deactivated, the selected text is added to
>   the primary selection.  If deactivation occurs as a result 
>   of a buffer modification, the text that is added is the text in
>   the region prior to the modification.
> 
>   2. If the region is temporarily active after a command (e.g. after a
>   mouse drag or shift selection), the selected text is added to the
>   primary selection, even if the mark is not deactivated.
> 
>   3. If you deactivate the mark with C-g, the selected text 
>   is not added to the primary selection.
> 
>   4. Any kill command sets clipboard in addition to the kill-ring; any
>   yank command inserts the clipboard contents, if possible
>   (x-select-enable-clipboard).
> 
>   5. mouse-2 yanks primary.

You don't say here whether selecting using the mouse copies to the kill-ring.  

And you don't say whether C-y after selecting with the mouse yanks what was
selected.

> if you mark a region with C-SPC and do C-w, you won't be able
> to paste the text in with mouse-2, unlike earlier Emacs versions.

My primary concern right now (because it is what I use most now) is the behavior
on Windows, but I do care also about the behavior on other platforms.

And I'm curious.  What is the rationale for such behavior (C-w followed by
mouse-2 will prevent it from yanking what was killed)?

Apparently C-SPC plus motion to select, followed by mouse-2, does yank what was
selected (good), but if you use C-w (or M-w, for that matter) before clicking
mouse-2 then nothing is yanked (bad).

Do people really feel it is convenient to _not_ be able to use mouse-2 to yank
the front of the kill ring?

Sounds like we'd be giving up some convenient Emacs copy+yank behavior.  What's
the upside to compensate for the loss?  What would users gain by this change?

I really don't understand what is going on (why).  Is this all just about
limiting Emacs to make it more like other apps on X?

If so, then please tell us more about what we will gain in Emacs, besides
standardization/compatibility?  I've always found Emacs copy/kill/yank to be
superior to what I've seen elsewhere, in which case standardization would mean a
downgrade.  But I'm no expert on this.  Please tell us what good we'll be
getting.

AFAICS we haven't yet gotten a simple description of the proposed changes, in
terms of how they will affect users: use cases, pros & cons, what will change
and why.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <jan.h.d@swipnet.se>, <emacs-devel@gnu.org>,
>         "'David De La Harpe Golden'" <david@harpegolden.net>
> Date: Sat, 14 Aug 2010 21:48:50 -0700
> 
> You don't say here whether selecting using the mouse copies to the
> kill-ring.

Since the default value of mouse-drag-copy-region is now nil, it
doesn't by default.

> And you don't say whether C-y after selecting with the mouse yanks what was
> selected.

No, it doesn't yank, for the same reason (I think).

> > if you mark a region with C-SPC and do C-w, you won't be able
> > to paste the text in with mouse-2, unlike earlier Emacs versions.
> 
> My primary concern right now (because it is what I use most now) is the behavior
> on Windows, but I do care also about the behavior on other platforms.
> 
> And I'm curious.  What is the rationale for such behavior (C-w followed by
> mouse-2 will prevent it from yanking what was killed)?

Apparently, the GUI recommendations on X are now that the primary
selection is used only in conjunction with the mouse, while the
clipboard is used only in conjunction with keyboard cut/paste (C-c,
C-v, etc.).  IOW, mouse selection and mouse-2 style copy/paste is no
longer regarded as _the_ copy/cat-n-paste operations, only the
keyboard ops are.

See David's mail a few hours ago in this thread.

> Apparently C-SPC plus motion to select, followed by mouse-2, does
> yank what was selected (good)

Since C-SPC+motion selects the text, and selected text is "yank"able
with mouse-2, yes.

> but if you use C-w (or M-w, for that matter) before clicking
> mouse-2 then nothing is yanked (bad).

If the text was selected with the mouse (or any other way that
activates the mark) prior to C-w, then you can still "yank" with
mouse-2, by virtue of that selection.  So this is still "good" in most
use-cases.

> I really don't understand what is going on (why).  Is this all just about
> limiting Emacs to make it more like other apps on X?

That's my current understanding, yes.  "User expectations" and all
that.

> AFAICS we haven't yet gotten a simple description of the proposed changes, in
> terms of how they will affect users: use cases, pros & cons, what will change
> and why.

David's mail comes close, except that Emacs currently does not behave
100% according to what he describes:

  clipboards aren't overwritten when you merely select text.
  clipboards are overwritten when you cut/copy (C-x/C-c)
  clipboards are not inserted when you click mouse-2.
  clipboards are inserted when you paste (C-v)
  primary selections are overwritten when you merely select text.
  primary selections are not overwritten when you cut/copy (C-x/C-c)
   (but they've probably already just been overwritten because you
    selected text just before you cut/copied).
  primary selections are inserted when you click mouse-2.
  primary selections are not inserted when you paste (C-v)

Re: Selection changes in revno 100822

[Jan Djärv]

Eli Zaretskii skrev 2010-08-15 08.01:

> Apparently, the GUI recommendations on X are now that the primary
> selection is used only in conjunction with the mouse,  ...


Actually it is
"selecting but with no explicit copy should only set PRIMARY,
  never CLIPBOARD"

How text is selected (mouse or keyboard) isn't mentioned.

	Jan D.

Re: Selection changes in revno 100822

[Miles Bader]

Jan Djärv <jan.h.d@swipnet.se> writes:
>> Apparently, the GUI recommendations on X are now that the primary
>> selection is used only in conjunction with the mouse,  ...
>
> Actually it is "selecting but with no explicit copy should only set
> PRIMARY, never CLIPBOARD"
>
> How text is selected (mouse or keyboard) isn't mentioned.

... and firefox at least, _does_ set the primary based on
keyboard-driven selection.

-Miles

-- 
Logic, n. The art of thinking and reasoning in strict accordance with the
limitations and incapacities of the human misunderstanding.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sun, 15 Aug 2010 09:19:09 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii skrev 2010-08-15 08.01:
> 
> > Apparently, the GUI recommendations on X are now that the primary
> > selection is used only in conjunction with the mouse,  ...
> 
> 
> Actually it is
> "selecting but with no explicit copy should only set PRIMARY,
>   never CLIPBOARD"
> 
> How text is selected (mouse or keyboard) isn't mentioned.

You are right, of course, but I didn't mean to imply anything
different.  What I meant by "in conjunction with the mouse" refers
only to the action that copies or pastes the text, I did not mean the
selection process itself.

I must say that once mouse-2 is no longer a synonym to "yank" it
became a tad harder to explain what one means.  Is there a widely
accepted term for what mouse-2 does in this context?  The spec
everybody seem to quote still calls this "paste", so if there's no
better term, we will have to get used to saying "paste from PRIMARY",
"paste from CLIPBOARD", etc.  And, of course, there's the
Emacs-specific gripe that only one of them is no a synonym to "yank".

Re: Selection changes in revno 100822

[Jan Djärv]

Eli Zaretskii skrev 2010-08-15 11.27:

> I must say that once mouse-2 is no longer a synonym to "yank" it
> became a tad harder to explain what one means.  Is there a widely
> accepted term for what mouse-2 does in this context?  The spec
> everybody seem to quote still calls this "paste", so if there's no
> better term, we will have to get used to saying "paste from PRIMARY",
> "paste from CLIPBOARD", etc.  And, of course, there's the
> Emacs-specific gripe that only one of them is no a synonym to "yank".

"Paste the current selection" perhaps?  It is not technically correct, a 
program can set PRIMARY without using selections, but it is close enough.

	Jan D.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 15/08/10 11:25, Jan Djärv wrote:
>
>
> Eli Zaretskii skrev 2010-08-15 11.27:
>
>> I must say that once mouse-2 is no longer a synonym to "yank" it
>> became a tad harder to explain what one means. Is there a widely
>> accepted term for what mouse-2 does in this context? The spec
>> everybody seem to quote still calls this "paste", so if there's no
>> better term, we will have to get used to saying "paste from PRIMARY",
>> "paste from CLIPBOARD", etc. And, of course, there's the
>> Emacs-specific gripe that only one of them is no a synonym to "yank".
>
> "Paste the current selection" perhaps? It is not technically correct, a
> program can set PRIMARY without using selections, but it is close enough.

At the GUI level, "Paste Selection" vs. "Paste" is used in 
xfce4-terminal [1].

In a kde app that mentions it (klipper, kde's clipboard history and 
munging daemon) primary is referred to as "selection" [2] (aside: note 
how klipper provides another option for x11 users who don't like the 
separate clipboard and primary, you can choose to have it sync them 
desktop-wide.)

"Yank Selection" vs. "Yank" might be consistent with a s/paste/yank/g 
approach.

The emacs menu already says "Cut/Copy/Paste" for 
kill/kill-ring-save/yank, so a "Paste Selection" could perhaps also be 
fitted in just below "Paste" like in the xfce4-terminal example.

Of course we have one instance of "yank-primary" at the elisp level in 
mouse-yank-primary.

[1] http://imgur.com/H2b1m.png
[2] http://imgur.com/omaek.png

Re: Selection changes in revno 100822

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Drew Adams" <drew.adams@oracle.com>
>> Cc: <jan.h.d@swipnet.se>, <emacs-devel@gnu.org>,
>>         "'David De La Harpe Golden'" <david@harpegolden.net>
>> Date: Sat, 14 Aug 2010 21:48:50 -0700
>> 
>> You don't say here whether selecting using the mouse copies to the
>> kill-ring.
>
> Since the default value of mouse-drag-copy-region is now nil, it
> doesn't by default.
>
>> And you don't say whether C-y after selecting with the mouse yanks what was
>> selected.
>
> No, it doesn't yank, for the same reason (I think).
>
>> > if you mark a region with C-SPC and do C-w, you won't be able
>> > to paste the text in with mouse-2, unlike earlier Emacs versions.
>> 
>> My primary concern right now (because it is what I use most now) is the behavior
>> on Windows, but I do care also about the behavior on other platforms.
>> 
>> And I'm curious.  What is the rationale for such behavior (C-w followed by
>> mouse-2 will prevent it from yanking what was killed)?
>
> Apparently, the GUI recommendations on X are now that the primary
> selection is used only in conjunction with the mouse, while the
> clipboard is used only in conjunction with keyboard cut/paste (C-c,
> C-v, etc.).  IOW, mouse selection and mouse-2 style copy/paste is no
> longer regarded as _the_ copy/cat-n-paste operations, only the
> keyboard ops are.
>
> See David's mail a few hours ago in this thread.
>
>> Apparently C-SPC plus motion to select, followed by mouse-2, does
>> yank what was selected (good)
>
> Since C-SPC+motion selects the text, and selected text is "yank"able
> with mouse-2, yes.
>
>> but if you use C-w (or M-w, for that matter) before clicking
>> mouse-2 then nothing is yanked (bad).
>
> If the text was selected with the mouse (or any other way that
> activates the mark) prior to C-w, then you can still "yank" with
> mouse-2, by virtue of that selection.  So this is still "good" in most
> use-cases.
>
>> I really don't understand what is going on (why).  Is this all just about
>> limiting Emacs to make it more like other apps on X?
>
> That's my current understanding, yes.  "User expectations" and all
> that.
>
>> AFAICS we haven't yet gotten a simple description of the proposed changes, in
>> terms of how they will affect users: use cases, pros & cons, what will change
>> and why.
>
> David's mail comes close, except that Emacs currently does not behave
> 100% according to what he describes:
>
>   clipboards aren't overwritten when you merely select text.
>   clipboards are overwritten when you cut/copy (C-x/C-c)
>   clipboards are not inserted when you click mouse-2.
>   clipboards are inserted when you paste (C-v)
>   primary selections are overwritten when you merely select text.
>   primary selections are not overwritten when you cut/copy (C-x/C-c)
>    (but they've probably already just been overwritten because you
>     selected text just before you cut/copied).
>   primary selections are inserted when you click mouse-2.
>   primary selections are not inserted when you paste (C-v)

What is described here seem to be with CUA mode activated (C-x/C-c/C-v)
isn't it? :-(
So can you describe what yank/kill with defaults setting is actually
supposed to do?


-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Sun, 15 Aug 2010 09:22:44 +0200
> 
> > David's mail comes close, except that Emacs currently does not behave
> > 100% according to what he describes:
> >
> >   clipboards aren't overwritten when you merely select text.
> >   clipboards are overwritten when you cut/copy (C-x/C-c)
> >   clipboards are not inserted when you click mouse-2.
> >   clipboards are inserted when you paste (C-v)
> >   primary selections are overwritten when you merely select text.
> >   primary selections are not overwritten when you cut/copy (C-x/C-c)
> >    (but they've probably already just been overwritten because you
> >     selected text just before you cut/copied).
> >   primary selections are inserted when you click mouse-2.
> >   primary selections are not inserted when you paste (C-v)
> 
> What is described here seem to be with CUA mode activated (C-x/C-c/C-v)
> isn't it? :-(

It is described in CUA terms, presumably because that's how other apps
behave.  The intent is to have Emacs behave like that with C-W/M-w and
C-y.

> So can you describe what yank/kill with defaults setting is actually
> supposed to do?

The same, see above.

P.S. Could you please quote only the relevant parts of the message you
are responding to?

Re: Selection changes in revno 100822

[Stefan Monnier]

> Here is a summary of the current scheme:
[...]
>   5. mouse-2 yanks primary.

Question: how do I yank the primary from the keyboard?
I used to do that with C-y very happily.


        Stefan

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  jan.h.d@swipnet.se,  emacs-devel@gnu.org,  David De La Harpe Golden <david@harpegolden.net>
> Date: Mon, 16 Aug 2010 13:03:59 +0200
> 
> > Here is a summary of the current scheme:
> [...]
> >   5. mouse-2 yanks primary.
> 
> Question: how do I yank the primary from the keyboard?
> I used to do that with C-y very happily.

Gotta tinker with x-select-enable-primary, I think.

Re: Selection changes in revno 100822

[Stefan Monnier]

>> > Here is a summary of the current scheme:
>> [...]
>> >   5. mouse-2 yanks primary.
>> 
>> Question: how do I yank the primary from the keyboard?
>> I used to do that with C-y very happily.

> Gotta tinker with x-select-enable-primary, I think.

We need a better answer.


        Stefan

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cyd@stupidchicken.com,  jan.h.d@swipnet.se,  emacs-devel@gnu.org,  david@harpegolden.net
> Date: Mon, 16 Aug 2010 15:47:17 +0200
> 
> >> > Here is a summary of the current scheme:
> >> [...]
> >> >   5. mouse-2 yanks primary.
> >> 
> >> Question: how do I yank the primary from the keyboard?
> >> I used to do that with C-y very happily.
> 
> > Gotta tinker with x-select-enable-primary, I think.
> 
> We need a better answer.

I'm not sure what to make of this remark.

What I wanted to say is that with the default values of
x-select-enable-primary and other relevant variables, you can only
paste from primary with mouse-2.

Re: Selection changes in revno 100822

[Stefan Monnier]

>> >> > Here is a summary of the current scheme:
>> >> [...]
>> >> >   5. mouse-2 yanks primary.
>> >> Question: how do I yank the primary from the keyboard?
>> >> I used to do that with C-y very happily.
>> > Gotta tinker with x-select-enable-primary, I think.
>> We need a better answer.
> I'm not sure what to make of this remark.

That I think it needs to be possible to do it from the keyboard, even
with the default settings.


        Stefan

Re: Selection changes in revno 100822

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >> >> > Here is a summary of the current scheme:
 > >> >> [...]
 > >> >> >   5. mouse-2 yanks primary.
 > >> >> Question: how do I yank the primary from the keyboard?
 > >> >> I used to do that with C-y very happily.
 > >> > Gotta tinker with x-select-enable-primary, I think.
 > >> We need a better answer.
 > > I'm not sure what to make of this remark.
 > That I think it needs to be possible to do it from the keyboard,
 > even with the default settings.

If that's what you want, how about adding "copy text from primary and
paste it" functionality to yank itself?  Then (on X11 only) you could
use C-y to yank from selections in other applications.

This would be independent of the decision whether to copy primary to
clipboard or kill-ring, although it would seem that the position
"what was good enough for Grampaw RMS is good enough for me" is going
to prevail, and Emacs is going to continue to DWI don't M (for values
of "I" = "me"), and automatically copy primary to the kill ring.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>     david@harpegolden.net,
>     cyd@stupidchicken.com,
>     jan.h.d@swipnet.se,
>     emacs-devel@gnu.org
> Date: Tue, 17 Aug 2010 11:43:28 +0900
> 
> Stefan Monnier writes:
> 
>  > >> >> > Here is a summary of the current scheme:
>  > >> >> [...]
>  > >> >> >   5. mouse-2 yanks primary.
>  > >> >> Question: how do I yank the primary from the keyboard?
>  > >> >> I used to do that with C-y very happily.
>  > >> > Gotta tinker with x-select-enable-primary, I think.
>  > >> We need a better answer.
>  > > I'm not sure what to make of this remark.
>  > That I think it needs to be possible to do it from the keyboard,
>  > even with the default settings.
> 
> If that's what you want, how about adding "copy text from primary and
> paste it" functionality to yank itself?

`yank' already supports such a functionality (that's how
`mouse-yank-at-click' works).  But it is currently triggered only when
`yank' is called from a mouse click.  What is needed is a way to do
that e.g. with some special value of a prefix arg.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cyd@stupidchicken.com,  jan.h.d@swipnet.se,  emacs-devel@gnu.org,  david@harpegolden.net
> Date: Tue, 17 Aug 2010 00:44:28 +0200
> 
> >> >> > Here is a summary of the current scheme:
> >> >> [...]
> >> >> >   5. mouse-2 yanks primary.
> >> >> Question: how do I yank the primary from the keyboard?
> >> >> I used to do that with C-y very happily.
> >> > Gotta tinker with x-select-enable-primary, I think.
> >> We need a better answer.
> > I'm not sure what to make of this remark.
> 
> That I think it needs to be possible to do it from the keyboard, even
> with the default settings.

With C-y?  The fact that C-y doesn't access PRIMARY _was_ the crux of
these changes, to make explicit keyboard-initiated paste operation
access the clipboard instead.

Re: Selection changes in revno 100822

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> That I think it needs to be possible to do it from the keyboard, even
>> with the default settings.
>
> With C-y?  The fact that C-y doesn't access PRIMARY _was_ the crux of
> these changes, to make explicit keyboard-initiated paste operation
> access the clipboard instead.

How bout providing a separate command to paste PRIMARY?  (Does any other
X app provides a way to paste PRIMARY with the keyboard?  I'm not aware
of any.)

Re: Selection changes in revno 100822

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>> With C-y?  The fact that C-y doesn't access PRIMARY _was_ the crux of
>> these changes, to make explicit keyboard-initiated paste operation
>> access the clipboard instead.
>
> How bout providing a separate command to paste PRIMARY?  (Does any other
> X app provides a way to paste PRIMARY with the keyboard?  I'm not aware
> of any.)

I don't think other X apps are generally a very good guide for "how to
work with the keyboard"...

-Miles

-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Selection changes in revno 100822

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
>>> With C-y?  The fact that C-y doesn't access PRIMARY _was_ the crux of
>>> these changes, to make explicit keyboard-initiated paste operation
>>> access the clipboard instead.
>>
>> How bout providing a separate command to paste PRIMARY?  (Does any other
>> X app provides a way to paste PRIMARY with the keyboard?  I'm not aware
>> of any.)
>
> I don't think other X apps are generally a very good guide for "how to
> work with the keyboard"...

Also note that this is my _most_ common way of operating... I select
some text in another app with the mouse, then do C-y in emacs to paste
it... (with the appropriate defaults changed to make it possible of
course)

-Miles

-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, jan.h.d@swipnet.se,
>         emacs-devel@gnu.org, david@harpegolden.net
> Date: Tue, 17 Aug 2010 11:12:45 -0400
> 
> How bout providing a separate command to paste PRIMARY?

Will those who want this wish to learn a new command?  If they won't,
it's better to provide a mode or option that makes C-y paste from
PRIMARY.

We could make that some variation of C-y, like with some special value
of prefix arg, but this again bumps into the question I asked above.

Re: Selection changes in revno 100822

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> How bout providing a separate command to paste PRIMARY?
>
> Will those who want this wish to learn a new command?  If they won't,
> it's better to provide a mode or option that makes C-y paste from
> PRIMARY.
>
> We could make that some variation of C-y, like with some special value
> of prefix arg, but this again bumps into the question I asked above.

Well of course there's currently an option to let you do it (I use it).

-Miles

-- 
We have met the enemy, and he is us.  -- Pogo

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Wed, 18 Aug 2010 01:50:50 +0900
> 
> Well of course there's currently an option to let you do it (I use it).

Doesn't that option also set PRIMARY upon selection?

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 17/08/10 19:14, Eli Zaretskii wrote:
>> From: Miles Bader<miles@gnu.org>
>> Date: Wed, 18 Aug 2010 01:50:50 +0900
>>
>> Well of course there's currently an option to let you do it (I use it).
>
> Doesn't that option also set PRIMARY upon selection?


Sometimes: If mouse-drag-copy-region is t _and_
x-select-enable-primary is t, then mouse-selection will set primary
as well as putting the selection on the kill-ring.

If mouse-drag-copy-region is nil and x-select-enable-primary is nil
and select-active-regions is t, then both mouse/keyboard selection will 
set primary, but _without_ putting it on kill ring.


I am confident a behaviour-only backward compatible set of less 
confusing customisations would be possible (i.e. you could achieve the 
same effects as older emacs, but with different customisations), I 
proposed one some years ago.

I am confident a fully backward compatible set of customisations that 
are apparently confusing as hell is possible. (i.e. you achieve the same 
effects  as older emacs with the same customisations (including 
reverting any changed defaults)) - that's what we have.

I am not confident a fully backward compatible set of customisations 
that aren't confusing as hell is possible.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 17/08/10 16:12, Chong Yidong wrote:


> How bout providing a separate command to paste PRIMARY?  (Does any other
> X app provides a way to paste PRIMARY with the keyboard?  I'm not aware
> of any.)
>

Turns out several terminal emulators do support Shift-Insert to paste 
_primary_ (sometimes without mentioning it), probably based on xterm.

Terminal emulator x11 apps:

                Shift-Ctrl-V  Shift-Insert  Ctrl-Shift-Ins mouse-2
xfce4-terminal  clipboard     primary      clipboard      primary
gnome-terminal  clipboard     primary      clipboard      primary
kde-konsole     clipboard     clipboard    primary        primary
xterm           ?             primary      primary        primary
rxvt            ?             primary      ?              primary



Non-terminal-emulator x11 apps:

              Ctrl-V     Shift-Insert  Ctrl-Shift-Ins  mouse-2
firefox      clipboard  clipboard     -               primary
thunderbird  clipboard  clipboard     -               primary
kate         clipboard  clipboard     -               primary
gedit        clipboard  clipboard     -               primary
oowriter     clipboard  clipboard     -               primary

Re: Selection changes in revno 100822

[Miles Bader]

David De La Harpe Golden <david@harpegolden.net> writes:
> Turns out several terminal emulators do support Shift-Insert to paste
> _primary_ (sometimes without mentioning it), probably based on xterm.

Not surprising, since I think a certain class of simpler apps simply
don't have any concept of cut/copy/paste at all, they _only_ use
primary.

-Miles

-- 
History, n. An account mostly false, of events mostly unimportant, which are
brought about by rulers mostly knaves, and soldiers mostly fools.

Re: Selection changes in revno 100822

[James Cloos]

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

CY> How bout providing a separate command to paste PRIMARY?  (Does any
CY> other X app provides a way to paste PRIMARY with the keyboard?  I'm
CY> not aware of any.)

It is not uncommon for shift-insert to paste PRIMARY.

A reasonable and, outside of gtk+ and the like, typical algo is to
insert PRIMARY if it is set and to fall back to CLIPBOARD otherwise.

I think that should work well for Emacs, too.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Selection changes in revno 100822

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

> One other issue we should consider IMO is what is the semantics of
> mouse-2 in sessions that support the mouse, but cannot access
> selections.  One such example is a TTY with a GPM mouse.  I don't have
> access to such a build of Emacs, but I'm quite sure mouse-2 there will
> either do nothing or signal an error.

Yes, xterm-mode-mode and gpm-mouse-mode are broken (both selection and
paste say "X windows are not in use or not initialized").

Re: Selection changes in revno 100822

[Eli Zaretskii]

> From: Johan Bockgård <bojohan@gnu.org>
> Date: Sat, 14 Aug 2010 14:28:14 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > One other issue we should consider IMO is what is the semantics of
> > mouse-2 in sessions that support the mouse, but cannot access
> > selections.  One such example is a TTY with a GPM mouse.  I don't have
> > access to such a build of Emacs, but I'm quite sure mouse-2 there will
> > either do nothing or signal an error.
> 
> Yes, xterm-mode-mode and gpm-mouse-mode are broken (both selection and
> paste say "X windows are not in use or not initialized").

Thanks for testing.  Please submit a bug report about this.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 11:00:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > We could change mouse-yank-primary so that it calls yank if no primary
> > selection exists.  But maybe that is too confusing.
> 
> This is directly relevant to the issue at (my) hand: how to restore
> the expected behavior of selections on Windows.  If it is okay to call
> `yank' when there's no primary selection, then that's one way of
> fixing the bug on Windows.  But then note that `yank' does not only
> insert text, it also does other non-trivial things to the kill ring
> etc.; so if the primary selection _does_ exist, all those things won't
> be done.  This is unlike the old code, which accessed the selection
> from inside `yank', and then treated it in the same way as if it came
> from the kill ring.
> 
> An alternative way of fixing the bug on Windows would be to modify the
> Windows implementation of x-get-selection to get the text from the
> clipboard if the (emulated) primary selection does not exist.
> 
> Which of these ways is the best one, depends on clearing up the above
> confusions.

For now, I fixed the Windows build by using x-get-selection-value in
preference to the primary selection.  This change is in revno 101080.
Whether any changes are needed in x-get-selection emulation on Windows
depends on the rest of this thread: how we want to behave wrt selected
text and primary selection on X and wrt the clipboard on w32.

> One other issue we should consider IMO is what is the semantics of
> mouse-2 in sessions that support the mouse, but cannot access
> selections.  One such example is a TTY with a GPM mouse.  I don't have
> access to such a build of Emacs, but I'm quite sure mouse-2 there will
> either do nothing or signal an error.

This is still broken and need to be fixed.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 14/08/10 16:59, Eli Zaretskii wrote:


> For now, I fixed the Windows build by using x-get-selection-value in
> preference to the primary selection.  This change is in revno 101080.


I did already suggest reverting the rebinding of mouse-2 to 
mouse-yank-at-click, but then adding a mouse-yank-selection-only (or 
other name) customization to it so that its side-effect on the kill-ring 
could be removed.

Then that could just be turned off for w32, instead of mangling what was 
the straightforward single-purpose mouse-yank-primary.

That would also have the advantage of preserving compatibility with 
third-party packages and other call sites of mouse-yank-at-click,
and mean switching between new and "classic" (ahem) emacs behaviour 
would just be a matter of boolean customizations instead of 
customisation (easy) and rebinding (hard).

Sigh.

Message-ID: <4C4C6713.2070608@harpegolden.net>
Date: Sun, 25 Jul 2010 17:32:19 +0100
From: David De La Harpe Golden <david@harpegolden.net>
Subject: Re: Selection changes
To: emacs-devel@gnu.org, Chong Yidong <cyd@stupidchicken.com>,
  Eli Zaretskii <eliz@gnu.org>

http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01184.html

Re: Selection changes in revno 100822

[David De La Harpe Golden]

> I did already suggest reverting the rebinding of mouse-2 to
> mouse-yank-at-click,

I mean bind it to mouse-yank-at-click again, sorry.

> but then adding a mouse-yank-selection-only (or
> other name) customization to it so that its side-effect on the kill-ring
> could be removed.

"it" being mouse-yank-at-click.

Re: Selection changes in revno 100822

[Eli Zaretskii]

> Date: Sat, 14 Aug 2010 19:49:15 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> I did already suggest reverting the rebinding of mouse-2 to 
> mouse-yank-at-click, but then adding a mouse-yank-selection-only (or 
> other name) customization to it so that its side-effect on the kill-ring 
> could be removed.

But no one acted on that suggestion, so it sounds like it was silently
rejected.  Or maybe no one, including yourself, was interested in
fixing a Windows-only problem.

> Then that could just be turned off for w32, instead of mangling what was 
> the straightforward single-purpose mouse-yank-primary.

Please don't call names perfectly correct code just because you
disagree with its idea.  Windows users were asking for the fix to this
bug for weeks now; it seems no one else was interested in fixing it
except your truly.  Since I did the work, I get to choose the tools
and the way of doing it, and I see nothing wrong with the idea I
implemented.  If anyone was interested in doing it some other way,
they had more than a month to beat me to it.

> That would also have the advantage of preserving compatibility with 
> third-party packages and other call sites of mouse-yank-at-click,
> and mean switching between new and "classic" (ahem) emacs behaviour 
> would just be a matter of boolean customizations instead of 
> customisation (easy) and rebinding (hard).

Sorry, I don't understand what you mean here.  Specific examples of
incompatibilities are welcome, as are bug reports about any such
problems.

Re: Selection changes in revno 100822

[David De La Harpe Golden]

> Windows users were asking for the fix to this
> bug for weeks now; it seems no one else was interested in fixing it
> except your truly.

I was interested, I established a w32 build environment for that purpose 
to test on.  I supplied a patch. It was, as you say, apparently silently 
rejected, for whatever reason. Shrug.