Re: lib/53682

[christos%zoulas.com@localhost (Christos Zoulas)]

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