1) This is a regression since Emacs-23.4.  That is, large selections work
in emacs prior to emacs 24
2) I've been able to reproduce in a more standard x environment the
report-emacs-bug report is essentially the same except for:
....
In GNU Emacs 24.2.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.1)
 of 2013-01-10 on drdws0066.nyc.desres.deshaw.com
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
System Description: CentOS release 5.7 (Final)
....


On Sat, Jan 19, 2013 at 12:19 PM, Stefan Monnier
<monnier@iro.umontreal.ca>wrote:

> >> http://www.straightrunning.com/XmingNotes/, a packaging of 'mainly
> >> from the X.org source code with patches applied'.
> > Ah, so you are running Emacs through a remote X connection.  That is the
> > reason for the slowdown: the Emacs binary needs to transfer the X
> > primary selection to the server over the network.
>
> IIUC in his example, only the ownership of the selection needs to be
> transferred, not the selection itself, so the size of the selection
> shouldn't matter.
> Unless he has some extra software (like some clipboard applets) that
> systematically keeps takes a copy of those things, tho I don't remember
> hearing of a case where the PRIMARY was (mis)handled this way (contrary
> to the CLIPBOARD selection, where there've been many such mishandling
> by naive applets).
>
>
>         Stefan
>