<div dir="ltr">Yes, using line endings as split points is somewhat arbitrary, anything that's a reasonable compromise between interruption responsiveness and low interrupt polling overhead would do. I feel that the lines are somewhat nicer since arbitrary splitting may lead to confusion and/or formatting ugliness.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 4:24 PM, Adrian McCarthy via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">amccarth accepted this revision.<br>
amccarth added a comment.<br>
<br>
LGTM.<br>
<br>
But just a thought:  Is it worth doing all the work to scan for line endings for the interruption points?  What if, instead, it just printed the next _n_ characters on each iteration until the entire buffer has been printed.  Sure, sometimes an interruption will split a line, and sometimes it won't.  I'm not sure that's important for interactive usage.  It would mean less fiddly code, faster output (because you don't have to scan every character), and a zillion short lines will print as fast as a smaller number of longer lines that represents the same volume of text.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D37923" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D37923</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>