bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57434: 28.1.91; Terminal Emacs Mac OS flickering.


From: Eli Zaretskii
Subject: bug#57434: 28.1.91; Terminal Emacs Mac OS flickering.
Date: Fri, 02 Sep 2022 10:26:45 +0300

> Cc: kuragin@google.com, 57434@debbugs.gnu.org
> Date: Fri, 02 Sep 2022 10:16:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> A natural place to emit these is in, respectively, update_begin_hook
> and update_end_hook.  These two hooks are currently set to NULL (in
> term.c) for TTY frames.  So as a first try, I suggest to define these
> hooks for TTY frames, and make them emit these two commands.  If doing
> so resolves the problem with flickering on alacritty, we can think how
> to add that cleanly only for alacritty.

Actually, I think we'll need one more small change.  These hooks are
called from update_begin and update_end like this:

      /* Update the display.  */
      if (FRAME_INITIAL_P (f))
        /* No actual display to update so the "update" is a nop and
           obviously isn't interrupted by pending input.  */
        paused_p = false;
      else
        {
          update_begin (f);
          paused_p = update_frame_1 (f, force_p, inhibit_hairy_id_p, 1, false);
          update_end (f);
        }

      if (FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))
        {
          if (FRAME_TTY (f)->termscript)
            fflush (FRAME_TTY (f)->termscript);
          if (FRAME_TERMCAP_P (f))
            fflush (FRAME_TTY (f)->output);
        }

I think the fact that we call fflush (FRAME_TTY (f)->output) after
update_end is a conceptual bug, which only goes unnoticed because
update_end is a no-op on TTY frames.  At least for the purpose of
testing the above possible fix, the order should be reversed: we
should fflush the terminal output _before_ we call update_end.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]