Re: lib/53682

[Jordan Lewis <jordan%cockroachlabs.com@localhost>]

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

From: Jordan Lewis <jordan%cockroachlabs.com@localhost>
To: Christos Zoulas <christos%zoulas.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:39:03 -0500

 --000000000000eba4b7057b2db627
 Content-Type: text/plain; charset="UTF-8"
 
 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 Wed, Nov 21, 2018, 09:23 Christos Zoulas <christos%zoulas.com@localhost wrote:
 
 > 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
 >
 
 --000000000000eba4b7057b2db627
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable
 
 <div dir=3D"auto"><div>I understand what you were getting at now. I agree t=
 hat wrapped lines shouldn&#39;t end up with embedded newlines that weren&#3=
 9;t entered by the user.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
 >Do you have an idea about how to correct the behavior?<br><br><div class=
 =3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Wed, Nov 21, 2018, 09:23 =
 Christos Zoulas &lt;<a href=3D"mailto:christos%zoulas.com@localhost";>christos@zoulas.=
 com</a> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
  0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Nov 21,=C2=A0 8:5=
 3am, <a href=3D"mailto:jordan%cockroachlabs.com@localhost"; target=3D"_blank" rel=3D"n=
 oreferrer">jordan%cockroachlabs.com@localhost</a> (Jordan Lewis) wrote:<br>
 -- Subject: Re: lib/53682<br>
 <br>
 | But this &quot;breaking into multiple lines&quot; is precisely the behavi=
 or that we&#39;re<br>
 | trying to preserve. If the input was multiple lines (newlines entered dur=
 ing<br>
 | entry of text), then the pasted &quot;output&quot; should be multiple lin=
 es too.<br>
 | libedit<br>
 | currently modifies the history from the perspective of the copy/pasting u=
 ser<br>
 | by inserting padding spaces instead of those newlines *that were inputted=
 *.<br>
 <br>
 Yes, these newlines should be preserved.<br>
 <br>
 | Another way to see what&#39;s broken here is window resizing. Try enterin=
 g a<br>
 | multi-line string, scrolling up to it via history, then resizing the<br>
 | window. You&#39;ll<br>
 | see that the retrieved, historical one breaks in funny ways because of th=
 e<br>
 | added padding spaces, but the actual user-inputted one doesn&#39;t break.=
 <br>
 <br>
 Yes, still if the user did not enter a newline, then when cutting and pasti=
 ng<br>
 the single line it should not end up as two lines, don&#39;t you agree?<br>
 <br>
 christos<br>
 </blockquote></div></div></div>
 
 --000000000000eba4b7057b2db627--