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): pine-4.44-10 How reproducible: Always 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" 3. Actual Results: The pasted lines seem to be mixed up with the text already in pico Expected Results: Paste should work in pico. Additional info: Pasting works with a text file in vi, so I'm not inclined to think it's a gnome-terminal bug...
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. Marc.
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 types.
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 line separator 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 to that. Confused yet? 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.