Chris Moore skrev:
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I run the Xfce 4 desktop environment, along with the
xfce4-clipman-plugin applet which collects clipboard entries and
allows me to chose between them from a menu.
I have x-select-enable-clipboard set to t in Emacs, so whenever I
'kill' regions of the buffer, they get sent to the clipboard.
Occasionally the clipman applet will start consuming all available
CPU. This happens when I copy certain binary characters. Seems the
clipman gets stuck in a loop trying to convert illegal an illegal UTF8
string.
A very simple case which reproduces the bug:
I made a 1-byte file containing just character 0300 (octal),
copied that using Emacs, and clipman started printing its error
message over and over again.
I reported this bug firstly to the Xfce BTS:
http://bugzilla.xfce.org/show_bug.cgi?id=1945
but they told me it was a gtk bug, so I raised the same bug in the
GNOME tracker:
http://bugzilla.gnome.org/show_bug.cgi?id=349856
and they tell me it's an Emacs bug, saying:
Well, if emacs puts binary junk into a text property it is not gtk's
fault.
Look at gtk_selection_data_get_text(): We only try to convert
something to
utf8 if the sender claims that it is text...
So I'm raising it here too!
Isn't 0300 a valid unicode character? Anyway, when Emacs gets a selection
request for the clipboard with type UTF8_STRING, it eventually ends up in
xselect-convert-to-string. This function does:
((eq type 'UTF8_STRING)
(setq str (encode-coding-string str 'utf-8)))
As far as I can tell, it does not check if str is all text, it seems to return
non-text unconverted. Should we check str first? And if it does contain
non-text, what should Emacs send back as type? STRING, TEXT?
Jan D.
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
