From: Kevin Rodgers <ihs_4664@yahoo.com>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs puts binary junk into the clipboard, marking it as text
Date: Fri, 15 Sep 2006 10:30:41 -0600 [thread overview]
Message-ID: <eeekgq$j5o$1@sea.gmane.org> (raw)
In-Reply-To: <450A514E.6020205@swipnet.se>
Jan Djärv wrote:
>
>
> 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?
Yes, but it is not encoded as a single byte in UTF-8, it would be 2
bytes: o303 o200 (xC3 x80).
> 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?
--
Kevin
next prev parent reply other threads:[~2006-09-15 16:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1158280855.14121.69.camel@chrislap.madeupdomain.com>
2006-09-15 7:07 ` Emacs puts binary junk into the clipboard, marking it as text Jan Djärv
2006-09-15 16:30 ` Kevin Rodgers [this message]
2006-09-16 11:31 ` Jan D.
2006-09-16 17:25 ` Jan D.
2006-09-19 5:05 ` Kenichi Handa
2006-09-19 6:15 ` Jan Djärv
2006-09-19 7:14 ` Kenichi Handa
2006-09-19 10:54 ` Stefan Monnier
2006-09-19 11:14 ` Kenichi Handa
2006-09-19 16:15 ` Stefan Monnier
2006-09-19 19:32 ` Jan D.
2006-09-20 2:20 ` Kenichi Handa
2006-10-19 7:19 ` Jan Djärv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='eeekgq$j5o$1@sea.gmane.org' \
--to=ihs_4664@yahoo.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).