Kevin Rodgers wrote:
Jan Djärv wrote:
Chris Moore skrev:
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?
Yes, but it is not encoded as a single byte in UTF-8, it would be 2
bytes: o303 o200 (xC3 x80).
But that is as it should be, UTF8_STRING says data is in UTF-8, so Emacs
sends o303 o200. gtk_selection_data_get_text does not complain on that.
Anyway, xfce should not loop like that, gtk_selection_data_get_text does
not loop, it just prints one error message and returns.
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?
Doesn't that all depend on buffer-file-coding-system and
selection-coding-system being set correctly?
Yes, but I kind of assumed that was the case.
Anyway, I will fix this somehow, we should not be sending non-UTF8 as a
UTF8_STRING.
Jan D.
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug