[Leonard Hecker (lhecker)]

PR Summary

This bumps the chunk size for stdin from 16 to 1024 chars.

PR Context

It would be very unusual to read() from a file with a 16-byte buffer.
The same is true for stdin, but counter-intuitively it's actually
a lot "more true" for stdin than it would be for any file:
Since the stdin pipe is unbuffered and synchronous, the round-trip
overhead for reading from it is exorbitantly high. To put it into
perspective, on Windows the call overhead alone is roughly the same
as subsequentially reading in the order of 100K characters.

The increased buffer size has an immediately noticeable effect on
the interactive shells I've tested. Pasting content into a prompt now
appears immediately and atomically, while previously it would only
progressively arrive and get syntax highlighted repeatedly (= flicker).

Another nice benefit is that some shells have trouble determining
whether an escape character is a sequence inducer or a lone escape
character. Increasing the buffer size reduces the chance for hitting
this edge case from 1/16th (6%) to 1/1024th (0.1%) and makes it
very unlikely to occur at all for inputs <1024 characters.
This issue is what prompted me to make this modification.

[Tess Gauthier (tgauth)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Tess Gauthier (tgauth)]

Thanks Leonard Hecker (@lhecker)!

[DougSmythies]

I believe the issue addressed herein is the cause of my troubles when pasting from the clipboard into a file being edited with the nano editor on a linux computer, which uses "bracketed pastes". Sometimes the "end of pasted text" ESCAPE sequence is being broken up. PuTTY works fine, but the windows ssh client has issues. I started a discussion here a few days ago.