Re: lib/53682

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

The following reply was made to PR lib/53682; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: Jordan Lewis <jordan%cockroachlabs.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, lib-bug-people%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/53682
Date: Wed, 21 Nov 2018 09:22:53 -0500

 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