bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6689: 24.0.50; No primary selection


From: Drew Adams
Subject: bug#6689: 24.0.50; No primary selection
Date: Thu, 22 Jul 2010 14:35:41 -0700

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]