bug#57727: 29.0.50; Optimize tty display updates

[Gerd Möllmann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +  return Fresume_tty(tty);
>                       ^^
>                       SPC

Thanks, I'll fix these.

> That seems a bit over-engineered to me.
> Why not just a DEVAR_BOOL to control whether we flush or not?

Ok.  My thoughts went like so:

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.

2. I don't believe that just avoiding fflush will be enough.  THe code
currently uses a buffer of size BUFSIZ, which is OS-specific.  On my
system, for instance, BUFSIZ = 1024.  Don't know about MS-Windows today,
but I remember it being 512 there at some time.  At work, we had one
Linux distribution that used 32K (maybe Arch, I don't remember).  And so
on.

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.

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.

(Not a reason, but I wonder if different buffer sizes might also help
reduce flickering with some terminal emulators, like Alacritty.
Whatever, just wanted to mention this.)

> 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.