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.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 08:53:14 -0500

 --000000000000f876f1057b2d12b2
 Content-Type: text/plain; charset="UTF-8"
 
 >
 > If you try
 > to cut and paste a multi-line string from a shell that uses libedit
 > using mouse selection, now it will break into multiple lines, where
 > before it would work just fine.
 
 
 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*.
 
 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.
 
 On Wed, Nov 21, 2018 at 3:29 AM Christos Zoulas <christos%zoulas.com@localhost> wrote:
 
 > On Nov 21,  4:15am, nikhil.benesch%gmail.com@localhost (Nikhil Benesch) wrote:
 > -- Subject: Re: lib/53682
 >
 > |  Apologies. It appears my email client is swallowing indentation. Here's
 > |  a link to the patch instead.
 > |
 > |
 > https://gist.githubusercontent.com/benesch/48ac40e76179ec7f71c58c6360f9c391/raw/150d515f7254256766869937923260fe0fd68e7a/term-no-space.patch
 > .
 > |
 > |  I've now tested this patch on macOS Terminal app 2.7.4 (388.1.2), GNOME
 > |  terminal 3.18.3, and XTerm 322 without observing any problems.
 > |
 >
 > As I mentioned before there will be no 'display' problems (well
 > you removed the loop too, so I don't know what happens if it needs
 > to move more than one line). You just removed the code that does
 > <space><backspace> in the automatic margins case to move the cursor
 > to the next line when it is at the right margin. This code is there
 > to avoid putting a newline into the character buffer. If you try
 > to cut and paste a multi-line string from a shell that uses libedit
 > using mouse selection, now it will break into multiple lines, where
 > before it would work just fine.
 >
 > christos
 >
 
 --000000000000f876f1057b2d12b2
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable
 
 <div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you t=
 ry<br>to cut and paste a multi-line string from a shell that uses libedit<b=
 r>using mouse selection, now it will break into multiple lines, where<br>be=
 fore it would work just fine.</blockquote><div><br></div><div>But this &quo=
 t;breaking into multiple lines&quot; is precisely the behavior that we&#39;=
 re</div><div>trying to preserve. If the input was multiple lines (newlines =
 entered during</div><div>entry of text), then the pasted &quot;output&quot;=
  should be multiple lines too. libedit</div><div>currently modifies the his=
 tory from the perspective of the copy/pasting user</div><div>by inserting p=
 adding spaces instead of those newlines *that were inputted*.</div><div><br=
 ></div><div>Another way to see what&#39;s broken here is window resizing. T=
 ry entering a</div><div>multi-line string, scrolling up to it via history, =
 then resizing the window. You&#39;ll</div><div>see that the retrieved, hist=
 orical one breaks in funny ways because of the</div><div>added padding spac=
 es, but the actual user-inputted one doesn&#39;t break.=C2=A0</div></div><b=
 r><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Nov 21, 2018 at 3:29 =
 AM Christos Zoulas &lt;<a href=3D"mailto:christos%zoulas.com@localhost";>christos@zoul=
 as.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
 argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Nov 21,=C2=
 =A0 4:15am, <a href=3D"mailto:nikhil.benesch%gmail.com@localhost"; target=3D"_blank">n=
 ikhil.benesch%gmail.com@localhost</a> (Nikhil Benesch) wrote:<br>
 -- Subject: Re: lib/53682<br>
 <br>
 |=C2=A0 Apologies. It appears my email client is swallowing indentation. He=
 re&#39;s<br>
 |=C2=A0 a link to the patch instead.<br>
 |=C2=A0 <br>
 |=C2=A0 <a href=3D"https://gist.githubusercontent.com/benesch/48ac40e76179e=
 c7f71c58c6360f9c391/raw/150d515f7254256766869937923260fe0fd68e7a/term-no-sp=
 ace.patch" rel=3D"noreferrer" target=3D"_blank">https://gist.githubusercont=
 ent.com/benesch/48ac40e76179ec7f71c58c6360f9c391/raw/150d515f72542567668699=
 37923260fe0fd68e7a/term-no-space.patch</a>.<br>
 |=C2=A0 <br>
 |=C2=A0 I&#39;ve now tested this patch on macOS Terminal app 2.7.4 (388.1.2=
 ), GNOME<br>
 |=C2=A0 terminal 3.18.3, and XTerm 322 without observing any problems.<br>
 |=C2=A0 <br>
 <br>
 As I mentioned before there will be no &#39;display&#39; problems (well<br>
 you removed the loop too, so I don&#39;t know what happens if it needs<br>
 to move more than one line). You just removed the code that does<br>
 &lt;space&gt;&lt;backspace&gt; in the automatic margins case to move the cu=
 rsor<br>
 to the next line when it is at the right margin. This code is there<br>
 to avoid putting a newline into the character buffer. If you try<br>
 to cut and paste a multi-line string from a shell that uses libedit<br>
 using mouse selection, now it will break into multiple lines, where<br>
 before it would work just fine.<br>
 <br>
 christos<br>
 </blockquote></div>
 
 --000000000000f876f1057b2d12b2--