I understand what you were getting at now. I agree that wrapped lines shouldn't end up with embedded newlines that weren't entered by the user.
Do you have an idea about how to correct the behavior?
On Nov 21, 8:53am, jordan%cockroachlabs.com@localhost (Jordan Lewis) wrote:
-- Subject: Re: lib/53682
| But this "breaking into multiple lines" is precisely the behavior that we're
| trying to preserve. If the input was multiple lines (newlines entered during
| entry of text), then the pasted "output" should be multiple lines too.
| libedit
| currently modifies the history from the perspective of the copy/pasting user
| by inserting padding spaces instead of those newlines *that were inputted*.
Yes, these newlines should be preserved.
| Another way to see what's broken here is window resizing. Try entering a
| multi-line string, scrolling up to it via history, then resizing the
| window. You'll
| see that the retrieved, historical one breaks in funny ways because of the
| added padding spaces, but the actual user-inputted one doesn't break.
Yes, still if the user did not enter a newline, then when cutting and pasting
the single line it should not end up as two lines, don't you agree?
christos