bug#57727: 29.0.50; Optimize tty display updates

[Basil L. Contovounesios]

Sorry for crashing the party late:

Gerd Möllmann [2022-09-11 12:03 +0200] wrote:

> +DEFUN ("tty--output-buffer-size", Ftty__output_buffer_size,
> +       Stty__output_buffer_size, 0, 1, 0, doc:
> +       /* Return the output buffer size of TTY.
> +
> +TTY may be a terminal object, a frame, or nil (meaning the selected
> +frame's terminal).
> +
> +A value of zero means TTY uses the system's default value.  */)
> +  (Lisp_Object tty)
> +{
> +  struct terminal *terminal = decode_tty_terminal (tty);
> +  return make_fixnum (terminal->display_info.tty->output_buffer_size);

What should tty--output-buffer-size do when called from a graphical
terminal (i.e. when decode_tty_terminal returns NULL)?

It currently crashes, but that's what every other C program is doing,
very banal.  Maybe Emacs should do something more eccentric, like return
0 or -1, signal an error, or do my taxes as consolation.

> +DEFUN ("tty--set-output-buffer-size", Ftty__set_output_buffer_size,
> +       Stty__set_output_buffer_size, 1, 2, 0, doc:
> +       /* Set the output buffer size for a TTY.
> +
> +SIZE zero means use the system's default value.  If SIZE is
> +non-zero,this also avoids flushing the output stream.
> +
> +TTY may be a terminal object, a frame, or nil (meaning the selected
> +frame's terminal).
> +
> +This function temporarily suspends and resumes the terminal
> +device.  */)
> +  (Lisp_Object size, Lisp_Object tty)
> +{
> +  if (!TYPE_RANGED_FIXNUMP (size_t, size))
> +    error ("Invalid output buffer size");

Just curious: given this is an internal "--" function, do we want to
tell the user what a valid size would be?  E.g. along the lines of:

  size_t sz = check_uinteger_max (size, min (MOST_POSITIVE_FIXNUM, SIZE_MAX));

Or would that be too much?

BTW, is there a known upper limit for the buffer size in the OS?

> +  Fsuspend_tty(tty);
> +  struct terminal *terminal = decode_tty_terminal (tty);

Here, terminal should theoretically be non-NULL, as Fsuspend_tty would
have otherwise signalled.  Maybe we should eassert this assumption, or
explicitly check for NULL?

Thanks,

-- 
Basil