On Wed, Aug 31, 2022 at 9:34 AM Eli Zaretskii wrote: > > From: Dmitrii Kuragin > > Date: Wed, 31 Aug 2022 09:21:00 -0700 > > Cc: Eli Zaretskii , 57434@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. > Exactly, but it basically works for me. Which is what I need :) > > 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. I can try to add a new variable to configure/override the behavior. -- *If you get an email from me outside of the 9-5 it is *not* because I'm always on or expect an immediate response from you; it is because of work flexibility . Evening and weekend emails are a sign I allocated some regular working hours for other things (such as family, gym, friends,...). And I encourage you to feel free to do the same.