GNU bug report logs - #57434
28.1.91; Terminal Emacs Mac OS flickering.

Previous Next

Full log

Message #181 received at 57434 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitrii Kuragin <kuragin <at> google.com>
Cc: gerd.moellmann <at> gmail.com, 57434 <at> debbugs.gnu.org
Subject: Re: bug#57434: 28.1.91; Terminal Emacs Mac OS flickering.
Date: Wed, 31 Aug 2022 19:34:28 +0300

> From: Dmitrii Kuragin <kuragin <at> google.com>
> Date: Wed, 31 Aug 2022 09:21:00 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 57434 <at> debbugs.gnu.org
> 
> And here's one more video of default `baud-rate` vs 1000000 https://youtu.be/51EbX6bNP0M
> And here's a video how smooth vim works in the same setup: https://youtu.be/newP7XEA610
> 
> So, it is definitely not the terminal or Mac OS problem.

That's a wrong conclusion, AFAIU.  By "terminal or macOS problem" we
mean that some terminal commands, like those that insert and delete
lines in a region of a screen, cause flickering on those systems
and/or those terminals.  That vim doesn't show this flickering tells
us nothing: it might well be that vim doesn't use these terminal
commands.  After all, if we disable the use of those terminal commands
in Emacs, like you already tried, the flickering disappears.  So by
the same logic we could conclude that there's no problem at all.

> Additionally, I want to say that now I see the problem even when I connect to a remote linux machine using
> SSH.

Why did you expect the problem to disappear when you use Emacs via SSH
on the same terminal?  It's the same Emacs using the same algorithms
to decide which terminal commands to use in each case.

> Could it be that alacritty so fast that it gets into the state when the emacs pointing is in an unsynced state with
> terminal frequency? 

I don't see how this can happen.  Emacs outputs commands basically one
after the other, so their execution should be at the terminal's speed.

However, there's one place where we accumulate bytes before flushing
them: in update_frame_1:

	  if (FRAME_TERMCAP_P (f))
	    {
	      /* Flush out every so many lines.
		 Also flush out if likely to have more than 1k buffered
		 otherwise.   I'm told that some telnet connections get
		 really screwed by more than 1k output at once.  */
	      FILE *display_output = FRAME_TTY (f)->output;
	      if (display_output)
		{
		  ptrdiff_t outq = __fpending (display_output);
		  if (outq > 900
		      || (outq > 20 && ((i - 1) % preempt_count == 0)))
		    fflush (display_output);
		}
	    }

So maybe it's worthwhile to see if playing with the 900 figure here
helps in any way.  Or maybe __fpending doesn't work well on macOS?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.