Re: Emacs puts binary junk into the clipboard, marking it as text

["Jan D." <jan.h.d@swipnet.se>]

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.