GNOME Bugzilla – Bug 1704
problem pasting \r characters
Last modified: 2011-02-04 16:09:10 UTC
Package: gtk+ Version: 1.2.3 When opening a file in a gtk editor which has carriage returns, such as the attached, you cannot copy. -- http://www.slidellweb.com/dcougle ICQ #3795561 Lunarbard on AOL(Instant Messenger) Proverbs 15:3 Linux, operating system of the future "We will not be the alternative, we will set the trend" ------- Additional Comments From otaylor@redhat.com 1999-08-06 14:37:33 ---- Subject: Pasting with ^M From: Owen Taylor <otaylor@redhat.com> To: 1704@bugs.gnome.org Message-Id: <ybeoggksqky.fsf@fresnel.labs.redhat.com> Date: 06 Aug 1999 14:37:33 -0400 The problem here is that \r is not a legitimate character to be transferred by the X selections; the only control characters allowed are \n and \t. When transferring non-internationalized text via the STRING, you can get away with it; however, GTK+ will transfer via COMPOUND_TEXT when communicating with itself, and thereby goes through the X conversion routines, which refuse to accept strings with invalid control characters. [ though they happily generate them when converting the other way ] There are a couple of possible solutions: 1) Strip out control characters before converting to compound text. 2) For strings that are only ASCII + C0, transfer by default as STRING instead of COMPOUND_TEXT and include the C0 characters verbatim, even though they are (strictly speaking) also allowed for STRING. I'll put in at least 2). The problem with 1) is that some multi-byte encodings might include control characters. This will all work better in future versions of GTK+ when we move to using Unicode. Regards, Owen ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-27 14:46 ------- This bug was previously known as bug 1704 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=1704 Originally filed under the gtk+ product and general component. The original reporter (lunarbard@moonman.com) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, gtk-bugs@gtk.org.
I've committed a change now to GTK+-1.2.x that should fix this problem. Unfortunately, it is hard for me to test, since it was also fixed in XFree86 Xlib some time ago. (The change takes the result of stripping the invalid characters out of the _result_ of converting to compound text, since that only involves knowing what is valid in ctext, not knowing what is valid in the locale encoding.)