From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724
Description of problem:
When using pico in a gnome terminal, if you cut some multi-line text from a
gnome application and paste it in pico, it comes out all crooked. I think this
is a pico bug as paste seems to work fine in vi.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Open a test file in gedit, select a few lines and "copy" them
2.Open a text file in pico, under a gnome terminal and "paste"
Actual Results: The pasted lines seem to be mixed up with the text already in pico
Expected Results: Paste should work in pico.
Pasting works with a text file in vi, so I'm not inclined to think it's a
Please attach a screenshot of this corruption.
Created attachment 68846 [details]
Screenshot of pico before pasting text into it
Created attachment 68847 [details]
Screenshot of pico after pasting a few lines from gedit into it
I've posted a couple of screenshots to illustrate what is happening. The first
screenshot has pico in gnome-terminal open with a text file. The cursor position
is at the beginning of line 6.
The second screenshot has a three line selection in gedit that was copied using
Edit/Copy from the menu. After, a Edit/Paste was done in the gnome-terminal
window. This resulted in what we see in the screenshot. In other words, I can't
copy from gedit and paste into pico running in gnome-terminal.
The problem is a cooperation between Pico and gedit. From what I see, Pico is
receiving a CTRL-J command. This command comes probably from the input, that
is to say from gedit. What I believe it must be happening is that gedit ends
its lines with ^J (Line Feed), and when Pico reads this input, it receives
the character as a command which causes it to justify the text.
Adding a little bit of information on how Pico works. When you paste text
into Pico, what you are doing is creating a continuous input, where each
character is read, and the corresponding command is executed. For example
when you enter the letter "A", which is not associated to any command, then
the letter "A" will be inserted in the text, but when a control character
is entered, the command associated to that character will be executed. Pico
can not distinguish between you entering the character ^J from the keyboard
or from a cut'n paste operation.
I know you don't want to read this, but the only work aorund that I can think
of is that you don't paste more than one line at the time.
That's what seems to be going on. If other editors work, and they
seem to work fine in my testing, then it must be a bug in how
gedit's cut and paste works.
Reassigning to gedit.
There is presumably a spec for what linefeeds are allowed in the various paste
The same problem occurs when copying and pasting from two picos open in two
gnome-terminals. So, it's probably not an isolated gedit bug.
I'm pretty positive this is a vte bug, though I don't know the full
details. (I've seen this behavior on occasion with other apps.)
As far as cut-and-paste types go:
STRING and COMPOUND_TEXT are defined to have \n as the only legimate
UTF8_STRING is unclear (the recommendations in the spec are highly broken)
text/plain is defined to have \r\n as the line separator, but most people
who have implemented it as a Xdnd drop type haven't paid attention
Luckily, I don't think sorting this out is needed for VTE .. VTE should
just translate any of \n, \r, or \r\n into the same input sequence as
the user hitting the return key.
The standard GTK+ widgets canonicalize to \n for STRING and COMPOUND_TEXT on
output, but simply pass line separators through verbatim for STRING and
COMPOUND_TEXT on input and UTF8_STRING for both directions.
(lost nalin on the CC from the last mail ... misguessed who the owner of
the 'vte' package was.)
The widget should be converting newlines to carriage-returns on paste now, so
this should be fixed in vte 0.7.1 and later.
This is working pretty well with vte-0.7.4-1.