Hi,
I've reproduced the following with my copy of sexy, this is therefore
a bugreport for us. At least I think so. It really doesn't surprise
me if XE developers ignore this though.
If I can find out anything about X programming, I may attempt to fix
this. If anyone else can, please be my guest. I'd also like some
pointers about how to learn X (Xt?) programming.
Johann
Esben Mose Hansen <kde@xxxxxxxxxxxxx> writes:
> Hi,
>
> being a maintainer of a clipboard manager is so much fun, and even more so
> when your favorite editor is acting up ;-)
>
> I believe XEmacs has a bug in it's XSelectionEvent handling, somewhere.
> Could somebody please attempt this?
>
> 1. Create a file 262041 bytes long (Just under 256K)
> $ perl -e "print 'a'x262041;" > tmp.txt
> 2. Open this file in an XEmacs instance.
> $ xemacs tmp.txt &
> 3. Open another instance of XEmacs (not another frame or buffer, but a new
> instance)
> $ xemacs &
> 4. Select the entire buffer of the first instance (the one with tmp.txt)
> c-x c-h
> 5. Click with the middle mouse bottom in the other xemacs instance.
> 6. Notice how both xemacs instances locks up. Pressing ctrl-g fixes this.
> 7. Repeat, using one less byte. Everything works as expected.
>
> This is with
> [version 21.4.15; December 2004]
>
> Pasting into XEmacs is not an issue.
>
> It is one thing, (even reasonable), to refuse to copy a large selection. But
> this behavior freezes the other program. And plays havoc with clipboard
> managers.
>
> I believe this is the real reason for this bug:
>
> http://bugs.kde.org/show_bug.cgi?id=33747
>
> Also, for some reason XEmacs doesn't want to provide a TIMESTAMP on it's
> selection, forcing me to request TARGETS, which is wasteful.
>
> Thanks for your time!
>
> --
> regards, Esben
>
--
This line is left blank intentionally
|