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.