Avoid repeated TTY readline output with TERM=dumb

[JoelTowell]

Problem

Reline's dumb IO gate can be attached to a TTY, but it cannot repaint one.

When TERM=dumb is set, Reline selects Reline::Dumb. inner_readline still drives the display machinery: it renders the line editor, rerenders after input changes, renders the accepted line, and then moves the cursor back to column 0.

That is fine for an IO gate that can move the cursor over the previous frame. It is an issue for Reline::Dumb, where the cursor movement methods intentionally do nothing. Reline::Dumb#buffered_output also just yields, so those render writes go straight to output.

With a TTY, submitted input is already echoed by the terminal. Reline then appends intermediate render output after that. Typing hello can produce output like:

0> hello
hhehelhellhello0> hello
"hello"

This is related to #660.

Reproduction

The first commit on this branch adds failing coverage for this. It runs Reline.readline twice under a PTY with TERM=dumb, so both input and output are TTYs.

It can be checked out independently to see the current behaviour.

Solution

Buffer writes inside Reline::Dumb#buffered_output when input and output are both TTYs.

The first buffered render is still written, so the prompt is visible. Complete lines are also still written, so accepted input remains visible in captured TTY output. Other render frames are dropped, because Reline::Dumb has no cursor operation that could apply them in place.

When input or output is not a TTY, buffered_output keeps yielding directly and preserves the existing write path.

[tompng]

Rather than teaching Dumb to buffer/drop render frames heuristically, retiring Dumb itself and route TERM=dumb through the same non-interactive path as in #924 might be the better approach.

[JoelTowell]

Rather than teaching Dumb to buffer/drop render frames heuristically, retiring Dumb itself and route TERM=dumb through the same non-interactive path as in #924 might be the better approach.

Thanks @tompng, that makes sense.

I was thinking of this as a rendering issue in Reline::Dumb, but treating TERM=dumb as not supporting the interactive editor seems cleaner.

I can rework this as a small follow-up to #924: route TERM=dumb through the new non-interactive read path and keep a PTY regression for the repeated redraw output.

Would you prefer that I wait until #924 lands so the diff stays small, or stack this on top of #924 now?