Version: 1.92 (using KDE Devel) Installed from: Compiled sources OS: Linux Type ls [new line] then copy starting from the l upto the end of the line (this should copy the newline) Hit paste with middle click. Desired result: Should enter ls with the newline which executes the ls command. Actual result : Enters ls but not the newline so you have to manually press enter.
This is a sideeffect of the multiple line selection fix - as a result linebreaks are removed from any selection that has a linebreak at the end of the selection, not just those linebreaks that are added by wrapping the output to the terminal. I wonder how to tell the two kinds of linebreak apart?
In kde3 konsole was smart enough to detect a linefeed *while* selecting. So if I select a linefeed the visual feedback immediately went to the end of the line, even if my mouse was still at half the screen. Try it yourself in kde3; select "foo\n" and you'll see it being 4 chars, select one char more to the right and it will detect the real linefeed and visualize to the end of the line. (the *past* linefeed is important here) The effect here is that you can put a real line-feed in the copy buffer at such a point. Whereas at the right side of the buffer you don't do this. Hope that helps.
(Relevant link-backs) Original thread: Bug 89299, Conv branched to Bug 64295, redirected here by me. I'm in favor of increasing the distance you need to move the cursor past the end of the line to select the newline from 1 char to 3 or 4 char, because the current behavior makes it very hard not to select the newline.
I agree with William (comment 3), but that's not the stated bug report (which I believe was fixed, i.e. Robert reverted to the old behavior). Are we repurposing this bug to an RFE making it easy to not select the newline?
> Are we repurposing this bug ... Let's not. I opened bug 158726 instead. Robert, can you please confirm if this bug is fixed now? I think you said it is...
This does appear to be fixed recently, marking as resolved