bug#6689: 24.0.50; No primary selection

bug#6689: 24.0.50; No primary selection

[Drew Adams]

emacs -Q
 
In another Emacs session, select some text in any way and hit `M-w'.
 
Click mouse-2 in the new Emacs session.  You get the error "No primary
selection".  For example, try to yank the text into the prompt at
`report-emacs-bug' using mouse-2.  Note: C-y works, but mouse-2 does
not work.
 
I believe there have been a bunch of bug reports about selection
recently, but I haven't followed them.  It seems pretty broken, in any
case.
 
Please restore selection, copying/killing, and yanking to what it was
like before.  It was NOT broken - please do not "fix" it.
 
 
 
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-07-19 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/xpm/include'
 

bug#6689: 24.0.50; No primary selection

[David De La Harpe Golden]

On 21/07/10 16:06, Drew Adams wrote:
> emacs -Q
>
> In another Emacs session, select some text in any way and hit `M-w'.
>
> Click mouse-2 in the new Emacs session.  You get the error "No primary
> selection".

This is because w32 emacs' internal primary emulation is  presently 
intra-session only.  There may be a way to make it cross-session or even 
get primary-like behaviour to/from other w32 apps (involving 
accessibility apis), but it would be somewhat nontrivial.

"(global-set-key [mouse-2] 'mouse-yank-at-click)" will cause mouse-2 to 
revert to using the kill-ring/clipboard.

> Please restore selection, copying/killing, and yanking to what it was
> like before.

w32 in particular has actually long had a platform-specific default in 
place corresponding to the most major of the recent changes, funny enough.

Mind you, if you naively reversed the settings as presented in NEWS, it 
wouldn't actually restore the old settings on w32, because the fact w32 
e.g. already had x-select-enable-clipboard on by default isn't noted.

bug#6689: 24.0.50; No primary selection

[Drew Adams]

> > emacs -Q
> >
> > In another Emacs session, select some text in any way and hit `M-w'.
> > Click mouse-2 in the new Emacs session.  You get the error 
> > "No primary selection".
> 
> This is because w32 emacs' internal primary emulation is  presently 
> intra-session only.

Whatever the reason, the pesky fact remains that there was no problem prior to
the recent changes that broke this.

I do this all the time between Emacs sessions, sessions of the same release and
of different releases.  It works perfectly going back to at least Emacs 20.  Or
it did until the latest build I have.

Please get rid of this regression and restore the normal behavior.  We don't
need selection etc. to be "improved"; it just needs to work as usual.

> There may be a way to make it cross-session or even 
> get primary-like behaviour to/from other w32 apps (involving 
> accessibility apis), but it would be somewhat nontrivial.

There assuredly _is_ a way, however, to go back to what we had.
Please follow that path ASAP.

> "(global-set-key [mouse-2] 'mouse-yank-at-click)" will cause 
> mouse-2 to revert to using the kill-ring/clipboard.

Users should not need to jump through hoops to get the useful, stable behavior
in this regard that we've had for decades.  The Emacs mouse has better behavior
than elsewhere, not worse.  I don't give a mouse's ass for bringing the Emacs
mouse into line with other apps.

Please put any clever ideas for improvement into an _alternative_ setup: a new,
experimental option or a new minor mode.  And make sure that it is _opt-in_, not
opt-out.  Thanks.

> > Please restore selection, copying/killing, and yanking to 
> > what it was like before.
> 
> w32 in particular has actually long had a platform-specific 
> default in place corresponding to the most major of the
> recent changes, funny enough.

Such justification really doesn't matter.  The proof is in the pudding.  The
_behavior_ has changed.  It is the behavior that needs to be restored.

> Mind you, if you naively reversed the settings as presented 
> in NEWS, it wouldn't actually restore the old settings on w32,
> because the fact w32 e.g. already had x-select-enable-clipboard
> on by default isn't noted.

bug#6689: 24.0.50; No primary selection

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> Whatever the reason, the pesky fact remains that there was no problem
> prior to the recent changes that broke this.

The problem was that the way Emacs interacted with X selections was
non-standard.  The issue is subtle; you can read about it on the
emacs-devel archives.  Clearly, these changes need further adjustments.
But it's a non-starter to demand that everything be backed out in order
to avoid temporarily inconveniencing the users of the DEVELOPMENT
sources.

bug#6689: 24.0.50; No primary selection

[Drew Adams]

> > Whatever the reason, the pesky fact remains that there was 
> > no problem prior to the recent changes that broke this.
> 
> The problem was that the way Emacs interacted with X selections was
> non-standard.  The issue is subtle; you can read about it on the
> emacs-devel archives.  Clearly, these changes need further 
> adjustments.  But it's a non-starter to demand that everything
> be backed out in order to avoid temporarily inconveniencing the
> users of the DEVELOPMENT sources.

I have no problem with the DEVELOPMENT sources being broken.
I was not clear enough about that, no doubt. 

I do have a problem with our changing the default behavior.
Especially without a full discussion.

I don't see a clear proposal for a change in the default behavior on
emacs-devel.  And I don't see a proposal for a change as an opt-in option, an
alternative.

What I see - perhaps mistakenly - is that the default behavior has changed.

If the default behavior will not be changed, and there is only a temporary bug
in the DEVELOPMENT sources, then I have no problem with that.  (I should have
been clearer about that.)

Are you changing the default behavior or not?  That's the question.
Not whether there is some temporary problem.

bug#6689: 24.0.50; No primary selection

[Juanma Barranquero]

On Fri, Jul 23, 2010 at 00:34, Drew Adams <drew.adams@oracle.com> wrote:

> Are you changing the default behavior or not?  That's the question.
> Not whether there is some temporary problem.

There was no question in the original post for this bug. It was pretty
assertive:

   Please restore selection, copying/killing, and yanking to what it was
   like before.  It was NOT broken - please do not "fix" it.


    Juanma

bug#6689: 24.0.50; No primary selection

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 22 Jul 2010 15:34:48 -0700
> Cc: 6689@debbugs.gnu.org
> 
> I do have a problem with our changing the default behavior.
> Especially without a full discussion.
> 
> I don't see a clear proposal for a change in the default behavior on
> emacs-devel.  And I don't see a proposal for a change as an opt-in option, an
> alternative.
> 
> What I see - perhaps mistakenly - is that the default behavior has changed.
> 
> If the default behavior will not be changed, and there is only a temporary bug
> in the DEVELOPMENT sources, then I have no problem with that.  (I should have
> been clearer about that.)

Drew, please calm down.  Whatever changes were made, no one meant to
make them on Windows.  The motivation was behavior on Posix systems
wrt the clipboard and the primary selection.  As I wrote elsewhere, I
don't see any reasons to change the behavior on Windows, which lacks
the primary and secondary selections, and has just the clipboard.

Can you give a concise list of problems in the new behavior on
Windows?  I don't mean critique, I mean a list of what now behaves
differently from what it did before.  Such a list would help find the
damage and fix it.  TIA

bug#6689: 24.0.50; No primary selection

[Eli Zaretskii]

> Date: Thu, 22 Jul 2010 22:20:42 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> Cc: Chong Yidong <cyd@stupidchicken.com>, 6689@debbugs.gnu.org
> 
> There may be a way to make [w32 emacs' internal primary emulation]
> cross-session or even get primary-like behaviour to/from other w32
> apps (involving accessibility apis), but it would be somewhat
> nontrivial.

Why would it make sense to do such a thing?  Windows does not have any
"primary selection", it has only the clipboard.  Windows users do not
expect anything but the clipboard to work between applications.

> Mind you, if you naively reversed the settings as presented in NEWS, it 
> wouldn't actually restore the old settings on w32, because the fact w32 
> e.g. already had x-select-enable-clipboard on by default isn't noted.

Would reverting the defaults of all those variables except
x-select-enable-clipboard revert to the old behavior on Windows?

bug#6689: 24.0.50; No primary selection

[Drew Adams]

> Whatever changes were made, no one meant to make them on Windows.

Good to hear.  If similar symptoms appear on other platforms (dunno), then I
would hope they would be removed from there as well.

> The motivation was behavior on Posix systems
> wrt the clipboard and the primary selection.  As I wrote elsewhere, I
> don't see any reasons to change the behavior on Windows, which lacks
> the primary and secondary selections, and has just the clipboard.
> 
> Can you give a concise list of problems in the new behavior on
> Windows?

I gave concise, clear descriptions - see the original bug reports.  Do you want
me to repeat the recipes?

Here again is the one for this bug report (#6689):

> emacs -Q
>
> In another Emacs session, select some text in any way
> and hit `M-w'.
>
> Click mouse-2 in the new Emacs session.  You get the
> error "No primary selection".  For example, try to yank the
> text into the prompt at `report-emacs-bug' using mouse-2.
> Note: C-y works, but mouse-2 does not work.

What part of that description do you not follow?

Here's the other original report (#6694) recipe (again):

> I click mouse-1 at the left of some text and then
> mouse-3 at the right of it, to select it (a Lisp symbol).
> Then I try to yank it using `mouse-2':
> 
> Debugger entered--Lisp error: (wrong-type-argument
> char-or-string-p #<buffer throw-x-at-pt.el>)
> mouse-yank-primary((mouse-2 (#<window 8 on throw-x-at-pt.el>
> 4906 (392 . 488) 12477031 nil 4906 (49 . 33) nil (224 . 9)
> (8 . 14))))
>  call-interactively(mouse-yank-primary nil nil)
>
> Yanking it with C-y works OK.  So the problem is not with
> what was copied but with `mouse-yank-primary'.

I amended that within a couple of minutes as follows:

> Correction: Clicking mouse-1, then mouse-3 apparently
> does *not* copy the selection to the kill ring....
> Without M-w, C-y doesn't work either (after selecting using
> mouse-1, 3).

Is there something in that report that is not clear to you?  I don't have any
more information about it.  That's all I did and that's all I saw.

Those are the two bugs that I reported.  There are several other bug reports,
reported by others, that also have to do with mouse
selection/copying/killing/yanking.  It sounded to me like they were seeing
similar things, but I cannot speak for them or their platforms.  Clearly,
someone has been messing with the mouse recently ;-), and users on various
platforms are reporting problems.

I am relieved to hear people such as yourself agree that this changed behavior
represents a bug and not an intentional change.  That was *not* obvious, given
some of the rationalization and discussion of needed "improvements" in this
area.

That was one of the points I made: there was no clear proposal for a specified
change, followed by discussion and agreement.  Just some half-discussion and
then some code changes.

How to know whether a given behavior change observed is part of what was
intended for these "improvements" that were half talked about or just an
implementation mistake?  I don't know clearly what the proposed change _is_, so
it's hard to judge the real change that occurred - was it intended or not?  I'm
glad to hear you say it was not ("no one meant to make them on Windows").

It's still not clear (to me) what _problems_ the recent changes (unintentional
or intentional) were an effect (side-effect or intended effect) of trying to
fix.  What's the perceived problem or limitation that motivated such changes?

I'm using Windows now, but I'm also interested in proposed changes that will
affect Emacs on other platforms.  It's not clear to me what changes are in store
for us - on Windows and elsewhere.  The dev process is itself broken in this
regard, IMO.  We should see a clear proposal, discuss it, and agree on it,
before an attempt is made to implement it.  Without that, there is no way to
know whether some change is part of the plan or a bug.

bug#6689: 24.0.50; No primary selection

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>, <6689@debbugs.gnu.org>
> Date: Fri, 23 Jul 2010 07:57:26 -0700
> 
> I gave concise, clear descriptions - see the original bug reports.  Do you want
> me to repeat the recipes?

There's no need.  Are these two bug reports the only ones that
consider the behavior on Windows that changed because of this?

> Those are the two bugs that I reported.  There are several other bug reports,
> reported by others, that also have to do with mouse
> selection/copying/killing/yanking.

It was my impression that the other reports were for platforms other
than Windows.  If you know about bug reports regarding Windows, please
point me to their numbers.

> I am relieved to hear people such as yourself agree that this changed behavior
> represents a bug and not an intentional change.

IMO, it is definitely a bug on Windows.

> That was *not* obvious, given some of the rationalization and
> discussion of needed "improvements" in this area.

The intended improvements are on Posix platforms, which support both
the clipboard and the primary/secondary selections.

> That was one of the points I made: there was no clear proposal for a specified
> change, followed by discussion and agreement.  Just some half-discussion and
> then some code changes.

People who use Posix platforms are acutely aware of the difference
between how Emacs used the clipboard and the selections, and how other
applications do that.  That's why they didn't see any reason to
discuss the changes before making them.

> The dev process is itself broken in this regard, IMO.  We should see
> a clear proposal, discuss it, and agree on it, before an attempt is
> made to implement it.

That's not how the Emacs development works.  Core developers don't
need any approval for installing changes; they are trusted to not
break Emacs for others except in rare cases and then by mistake.  How
much they want to discuss before installing, is up to them.

bug#6689: 24.0.50; No primary selection

[Drew Adams]

> > I gave concise, clear descriptions - see the original bug 
> > reports.  Do you want me to repeat the recipes?
> 
> There's no need.  Are these two bug reports the only ones that
> consider the behavior on Windows that changed because of this?

Dunno.  They are the only two that I submitted.

> > I am relieved to hear people such as yourself agree that 
> > this changed behavior represents a bug and not an
> > intentional change.
> 
> IMO, it is definitely a bug on Windows.
> 
> > That was *not* obvious, given some of the rationalization and
> > discussion of needed "improvements" in this area.
> 
> The intended improvements are on Posix platforms, which support both
> the clipboard and the primary/secondary selections.

That wasn't clear to me.  I must have missed that.
But I still don't know what the intended improvements are.

> > That was one of the points I made: there was no clear 
> > proposal for a specified change, followed by discussion
> > and agreement.  Just some half-discussion and
> > then some code changes.
> 
> People who use Posix platforms are acutely aware of the difference
> between how Emacs used the clipboard and the selections, and how other
> applications do that.  That's why they didn't see any reason to
> discuss the changes before making them.

OK, they understand the problem.  And do they all understand and agree on the
solution?  And what about those who are not acquainted with the problem?

I still think a clear proposal that everyone can understand is important,
regardless of what those in-the-know might know (or think they know).  A spec
helps everyone, even those who think they understand it all.

> > The dev process is itself broken in this regard, IMO.  We should see
> > a clear proposal, discuss it, and agree on it, before an attempt is
> > made to implement it.
> 
> That's not how the Emacs development works.  Core developers don't
> need any approval for installing changes; they are trusted to not
> break Emacs for others except in rare cases and then by mistake.  How
> much they want to discuss before installing, is up to them.

Yes, of course they "don't need any approval" and "how much they want to
discuss...is up to them".  They are under no obligation to do or not do
anything.  That does not mean that it wouldn't be helpful to the community as a
whole for proposals to be made and discussion to follow proposals.

"Core developers" are under no obligation, but they live in an Emacs ecosystem,
and they take advantage of that ecosystem.  Users and other, non-"core"
developers can be useful, and their input can help.  There is no _obligation_
not to keep them in the dark and treat them like mushrooms.  But that is in no
one's interest, IMO.

bug#6689: 24.0.50; No primary selection

[Drew Adams]

I got the impression that these problems would soon be reverted for Windows
builds.

But I'm now seeing some of the same problems in a build from two days ago:

GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-08-02 on 3249CTO

I no longer have to do an explicit M-w after selecting with the mouse, so that
part has been fixed.

However, I still cannot select text in one Emacs session and yank it into
another Emacs session.  E.g. select text with mouse in a buffer in one session,
and try to yank it using mouse-2 into a buffer of another session. It does not
matter whether the Emacs sessions are the same build or even the same version.

I hope all of these selection regressions will be fixed soon, so I can start
using a recent Emacs build - and thus be able to help by reporting other
problems.

It's been about a month now that no version is really usable (for me).  This
selection madness is more than just an inconvenience.  Eli has stated (IIUC)
that nothing should have been changed for Windows, but it still does not work as
it did (= as it should).

bug#6689: 24.0.50; No primary selection

[David De La Harpe Golden]

On 04/08/10 21:43, Drew Adams wrote:

 > I no longer have to do an explicit M-w after selecting with the
 > mouse, so that part has been fixed.

Hmm.

 > I hope all of these selection regressions will be fixed soon, so
 > I can start  using a recent Emacs build

It is easy to revert to the old settings, as you must have gathered by 
this stage.

 > However, I still cannot select text in one Emacs session and yank it
 > into another Emacs session.  E.g. select text with mouse in a buffer
 > in one session, and try to yank it using mouse-2 into a buffer of
 > another session.

If you want emacs to copy the mouse selection to the windows clipboard 
and emacs kill-ring, turn on mouse-drag-copy-region.

If you want emacs to insert the windows clipboard/kill-ring on mouse-2, 
do (global-set-key [mouse-2] 'mouse-yank-at-click)

I already suggested to make the latter a boolean customisation so
that it can be more easily reverted again than by doing that.
http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01184.html

 > Eli has stated (IIUC)
 > that nothing should have been changed for Windows,

That is not necessarily true (unless you want emacs to continue to act 
weirdly on w32, and believe me I get that you yourself do want that).
I did respond to Eli on that point.
http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01170.html

bug#6689: 24.0.50; No primary selection

[Drew Adams]

>  > I hope all of these selection regressions will be fixed soon, so
>  > I can start  using a recent Emacs build
> 
> It is easy to revert to the old settings, as you must have 
> gathered by this stage.

Great.  Then please do revert Emacs to the "old" settings, and remove these
regressions as soon as possible.  Then we can all discuss possible improvements,
if you like.

>  > However, I still cannot select text in one Emacs session 
>  > and yank it into another Emacs session.  E.g. select text
>  > with mouse in a buffer in one session, and try to yank it
>  > using mouse-2 into a buffer of another session.
> 
> If you want emacs to copy the mouse selection to the windows 
> clipboard and emacs kill-ring, turn on mouse-drag-copy-region.

If you do not want Emacs to do as it has done, then set the options that you
want, to get the behavior you want for your own Emacs sessions.

> If you want emacs to insert the windows clipboard/kill-ring 
> on mouse-2, do (global-set-key [mouse-2] 'mouse-yank-at-click)

Ditto.  If for your own use you want a different behavior from what Emacs has
offered, then feel free to customize your copy of Emacs.

What gives you the right to change the default Emacs behavior for everyone, to
fit your preferences?  Maybe your preferences are wonderful, but if you want to
change the default behavior then you should ask emacs-devel, after making very
clear what changes you propose.

Honestly, I for one am open to being convinced that you have a better behavior
in mind.  You obviously know a lot about these things.

But so far I've seen no clear proposal.  All I've seen is behavior that is less
useful AFAICT.  Taking away the ability to copy & paste between Emacs sessions -
by default - is a minus.  I don't yet see a compensating plus, but I'm open to
argument or demonstration.

I speak only for myself, obviously, but I'm sure that others would also be
interested in hearing your proposal.

In the meantime, until a real discussion on the dev list and a decision to make
the changes you want, please revert them.  That should be easy, you say.

> I already suggested to make the latter a boolean customisation so
> that it can be more easily reverted again than by doing that.
> http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01184.html
> 
>  > Eli has stated (IIUC) that nothing should have been changed
>  > for Windows,
> 
> That is not necessarily true

It's not?  It seems to me that he did state that clearly.  He said:

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

He did not say more than that AFAIK.  He did not specify particular areas where
he thinks it does need to change.  Perhaps he will.

> (unless you want emacs to continue to act weirdly on w32, and
> believe me I get that you yourself do want that).

This is not about what I want to do for my own use.  If you want to put this in
terms of what I want then put it in terms of what I want for _Emacs_, not in
terms of what customized behavior I might want for myself.

I do not want Emacs to change so that one can no longer select text in one Emacs
session and yank it into another - and so on.  Call that "weird" behavior if you
like.  It is the way weird old Emacs has behaved until now, and it is very
useful.

_I_ am not proposing to change the default Emacs behavior.  Apparently you are.
Or rather you're just changing it without a proposal to the community.

> I did respond to Eli on that point.
> http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01170.html

You responded to him, but I do not see where he agreed with you.

In any case, I do not agree that users (at least Windows users) should no longer
be able, by _default_, to select text in one session and yank it into another
session.

Or at least I do not agree to such changes until I see a full proposal with a
rundown of the pros & cons, including all the consequences.  Maybe after
weighing the pros & cons I will agree with you.  For the moment I have only a
poor idea of everything that is involved.  All I see is changing behavior from
build to build, and so far I see no advantage to any of those changes.

It is not up to me to persuade you that those changes are bad.  It is up to you,
who are making changes, to persuade people that the changes are beneficial.  If
you persuade emacs-devel then I personally will either adopt the new or adapt by
customizing to get back the old.  It's not about my personal use.

I said earlier that just making such changes willy nilly without consulting
emacs-devel is not the right way to proceed.  Someone replied that I should not
react so quickly to such behavioral changes in recent builds, that they were
just bugs that were introduced accidentally and would soon be corrected.

But it's not clear to me just what is a temporary bug introduced by recent
changes, and which will ultimately be fixed, and what is an intended change in
behavior.  None of this is clear.  AFAIK you have not make a clear proposal
describing the changes you want to make.

Eli said:

  People who use Posix platforms are acutely aware of the difference
  between how Emacs used the clipboard and the selections, and how other
  applications do that.  That's why they didn't see any reason to
  discuss the changes before making them.

I would say that even people who do not use Posix currently should be brought
into the loop.  They might not use it, but they might still care about it and
like to know about it.  Why not describe the proposed changes so all can
understand?

In any case, wrt Windows I believe that Eli stated clearly that no behavior
change was called for.  For my part, I'm open to hearing about proposed changes,
but I do not like what I see so far.

And I do not think it is appropriate for people to discover changes without any
prior discussion.  If some changes just represent temporary bugs, no problem -
we all introduce bugs now and then.  But without a plan there is no way for us
to know what is a bug and what is a new "feature".

bug#6689: 24.0.50; No primary selection

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>> It is easy to revert to the old settings, as you must have gathered
>> by this stage.
>
> Great.  Then please do revert Emacs to the "old" settings, and remove
> these regressions as soon as possible.  Then we can all discuss
> possible improvements, if you like.

No, thanks.  The selection changes are missing some final pieces, but
the problem is not serious enough to warrant reversion.  It is better to
leave the development sources in place whil the wrinkles are ironed out.

Thanks for your patience.

bug#6689: 24.0.50; No primary selection

[Drew Adams]

> >> It is easy to revert to the old settings, as you must have gathered
> >> by this stage.
> >
> > Great.  Then please do revert Emacs to the "old" settings, 
> > and remove these regressions as soon as possible.  Then we
> > can all discuss possible improvements, if you like.
> 
> No, thanks.  The selection changes are missing some final pieces, but
> the problem is not serious enough to warrant reversion.  It 
> is better to leave the development sources in place whil the
> wrinkles are ironed out.

That's fine too.  I have lots of patience for bugs being fixed.  It's
frustrating that it is not clear which are bugs and which are intended changes.

When I mention a problem, such as not being able to yank text into a different
session, I'm told how I can customize Emacs to get the missing behavior.

That does not give the impression that this is recognized as a wrinkle that
needs to be ironed out.  That gives the clear impression that a change to the
default behavior is being made and users will need to customize Emacs to get
back the old behavior.

It is only to that kind of change (intentional) that I am reacting - not to
problems ironing out wrinkles.  I reported a wrinkle and was told (IIUC) that I
will need to customize Emacs from now on if I don't like that behavior.

> Thanks for your patience.

bug#6689: 24.0.50; No primary selection

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>, <6689@debbugs.gnu.org>
> Date: Wed, 4 Aug 2010 13:43:47 -0700
> 
> Eli has stated (IIUC) that nothing should have been changed for
> Windows, but it still does not work as it did (= as it should).

Eli had other things on his plate (see the logs), so he didn't yet
have time to put his money where his mouth is.

I will work on this when I have time, unless someone beats me to it.

bug#6689: 24.0.50; No primary selection

[Jason Rumney]

On 05/08/2010 08:19, Drew Adams wrote:
> Great.  Then please do revert Emacs to the "old" settings, and remove these
> regressions as soon as possible.  Then we can all discuss possible improvements,
> if you like.
>    

The changes that were made have been discussed numerous times in 
response to user complaints over many years. The only difference now is 
that someone actually did something, and now we have ONE user insisting 
that it be put back to the broken state it was in before, because... 
well actually, I'm not sure I've seen you offer a reason other than "it 
changed therefore it is now 'unusable'".

bug#6689: 24.0.50; No primary selection

[Drew Adams]

> The changes that were made have been discussed numerous times in 
> response to user complaints over many years.

Good to hear.  In which thread can I find a proposal summarizing the changes
being made?  Point me to the proposal and discussion of the proposed changes,
please.  I would love to see where we're headed.  I cannot tell the bugs from
the intentional changes.

Eli says that the intended changes are not for Windows anyway, which is
reassuring.  And he says they are obvious to people familiar with Posix
selection - and as a consequence of that there was _no_ proposal or discussion.
You apparently don't agree.  So where's the proposal?

> and now we have ONE user

There are several bug reports regarding recent selection changes, only two of
which I submitted (including this one).

> insisting that it be put back to the broken state it was in before

Seems that Yidong and Eli and... have also acknowledged that at least some of
the recent selection changes are bugs - at least on Windows, which is the only
platform I've spoken of from experience with the recent builds.

> I'm not sure I've seen you offer a reason 
> other than "it changed therefore it is now 'unusable'".

Perhaps you need to read again - and learn to quote fairly while you're at it.
I gave specific recipes, and others have agreed that what I described are bugs.
And some have been fixed.

Do you find it a _feature_ that you can no longer copy from one Emacs session
and yank to another (with the mouse)?  Do you find it a _feature_ that mouse
selection cannot be followed by `C-y' to yank the selected text (that has been
fixed, I believe - except cross-session).  Do you find it a _feature_ that mouse
selection followed by `M-w' raises an error "No primary selection" (that too has
been fixed, I believe).  And so on.  Were those changes "discussed numerous
times in response to user complaints over many years"?

I don't think so.  I think they are bugs.  Which is OK.  But I was not sure they
were not intentional changes until others confirmed that.  Why?  Because I know
that there are some intentional changes being made wrt selection, and I do not
know what they are (no proposal or summary of the changes to be made, AFAICT).
I am relieved to hear from Eli that they will not (ultimately) affect Windows,
but I did not know that at first.

What more do you need than such bug recipes in the way of _reasons_ to fix these
things?  There are clearly some "wrinkles to be ironed out".  And they are
getting ironed out, which means that we are progressively returning to the way
things were (on Windows).  Why do you suppose we would be returning to that
previous "broken state"?  Just because we have ONE user who insists on it?

bug#6689: 24.0.50; No primary selection

[Drew Adams]

FYI -

I still see this bug in the latest Windows build I have, which is from 8/09:

GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-08-09 on 3249CTO

You cannot copy using the mouse from one Emacs session and yank it into another
Emacs session.

This is a regression wrt Emacs 23 and prior.  Users should be able to use the
mouse to copy and yank between Emacs sessions (including between sessions of
different Emacs versions).

This bug is still open, so I assume you agree that it is a bug, and it is not an
intentional behavior change.  I have no problem waiting for a fix - this is just
an FYI/reminder.

bug#6689: 24.0.50; No primary selection

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>, <6689@debbugs.gnu.org>
> Date: Fri, 23 Jul 2010 07:57:26 -0700
> 
> Here again is the one for this bug report (#6689):
> 
> > emacs -Q
> >
> > In another Emacs session, select some text in any way
> > and hit `M-w'.
> >
> > Click mouse-2 in the new Emacs session.  You get the
> > error "No primary selection".  For example, try to yank the
> > text into the prompt at `report-emacs-bug' using mouse-2.
> > Note: C-y works, but mouse-2 does not work.

This bug should now be fixed (revno 101080).

If the cure turns out to be worse than the disease, please reopen this
bug.  If, OTOH, there are other issues with selections and cut/paste
on Windows due to the latest changes, please submit separate bug
reports.

> Here's the other original report (#6694) recipe (again):
> 
> > I click mouse-1 at the left of some text and then
> > mouse-3 at the right of it, to select it (a Lisp symbol).
> > Then I try to yank it using `mouse-2':
> > 
> > Debugger entered--Lisp error: (wrong-type-argument
> > char-or-string-p #<buffer throw-x-at-pt.el>)
> > mouse-yank-primary((mouse-2 (#<window 8 on throw-x-at-pt.el>
> > 4906 (392 . 488) 12477031 nil 4906 (49 . 33) nil (224 . 9)
> > (8 . 14))))
> >  call-interactively(mouse-yank-primary nil nil)
> >
> > Yanking it with C-y works OK.  So the problem is not with
> > what was copied but with `mouse-yank-primary'.
> 
> I amended that within a couple of minutes as follows:
> 
> > Correction: Clicking mouse-1, then mouse-3 apparently
> > does *not* copy the selection to the kill ring....
> > Without M-w, C-y doesn't work either (after selecting using
> > mouse-1, 3).

This bug was already fixed and Chong closed it.