Subject: RE: bug#6689: 24.0.50; No primary selection

From: "Drew Adams" <[email-masked]>
Date: Wed, 4 Aug 2010 17:19:14 -0700

>  > 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".