> 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.
Probably, it is caused by slowness of SSH and/or and my misunderstanding of the terminal capabilities, but I didn't see the problem when I was connected to Linux using SSH.
> 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.
It also might be caused by my limited knowledge of TTY. But, I see that we redraw linest not from top to bottom, but actually we try to redraw different portions of the screen at different times. (I am looking into `do_scrolling`).
And my assumption is that we cleared some portion of the screen and prepared it for new contents, but due to unsynced frame rates, the terminal redraws that partial state. And only then, we add some content in those empty lines and then the terminal redraws it again and we see what we needed to see.
Do we always draw frame as a single atomic operation or those things aren't synchronized at all?
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?
I tried bigger/smaller and delete the condition completely, it didn't help....
Also, I want to point out that `baud-rate` works and reduces part of the flickering and improves the situation overall. but `tty->line_ins_del_ok = 0;` fixes it completely.