bug#57727: 29.0.50; Optimize tty display updates

[Stefan Monnier]

> 1. Multi-tty make me feel it's natural to make the behavior terminal
> dependent.  At least I don't consider unreasonable for a user to expect
> being able to tailor the behavior depending on the terminal.

I guess the reason why I think it's over-engineered is that I feel it's
not something which end-users will want to play with or configure
per-terminal: we should have a setting that works well everywhere.

The config vars are only needed to help find that universal setting.

My guess is that the exact setting won't matter very much anyway as long
as it's big enough to cover most redisplays (since we `fflush` anyway at
the end of `update_frame`).

For that same reason, I expect that using the OS's default will be
good enough and it will be difficult to come up with good ways for users
to test other values and report meaningful information about the impact.

> 3. The coupling of setting the buffer size with not flushing is a bit
> strange, but my reasoning would be that setting a larger buffer and
> still flushing is kind of nonsensical.

Agreed.

> 4. From the recent discussion of supporting images on ttys I take away
> that using a large buffer might help with that because of more data
> being sent to the terminal.

Could be.  Tho I suspect we'd usually want to send a file name rather
a file's data, but in any case, this is still hypothetical, so I see no
need to cross this bridge yet.

>> If someone wants to try out different buffer sizes, I suspect that
>> recompiling is a good enough solution (or provide a DEFVAR_INT for that
>> and let the tester(s) call `suspend/resume-tty` by hand).
> I didn't do that because of multi-tty.  But letting users suspend/resume
> manually is of course an option.

To the extent that I see it as a "debugging" functionality, it seems
sufficient (another option is to tell people to use an Emacs daemon so
they can set the var before opening the tty).


        Stefan