After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 1704 - problem pasting \r characters
problem pasting \r characters
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.2.x
Other other
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 1999-07-15 06:20 UTC by lunarbard
Modified: 2011-02-04 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
(7.20 KB, text/plain)
2001-01-27 19:46 UTC, Exported from Debbugs
Details

Description lunarbard 2001-01-27 19:46:35 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.

Comment 1 Owen Taylor 2001-02-22 20:39:38 UTC
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.)