From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57434: 28.1.91; Terminal Emacs Mac OS flickering. Date: Wed, 31 Aug 2022 19:34:28 +0300 Message-ID: <83ler4s76z.fsf@gnu.org> References: <83edx1znjl.fsf@gnu.org> <83czclzms4.fsf@gnu.org> <83ler7vx3o.fsf@gnu.org> <838rn6x4h2.fsf@gnu.org> <834jxux3kd.fsf@gnu.org> <831qsyx2lr.fsf@gnu.org> <142be6aa-f25f-fad2-5597-6e02b0e3e4f6@gmail.com> <8335dcu0sg.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3749"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 57434@debbugs.gnu.org To: Dmitrii Kuragin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 31 18:36:26 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oTQhV-0000p3-Uk for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 31 Aug 2022 18:36:26 +0200 Original-Received: from localhost ([::1]:33868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oTQhU-00018V-S2 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 31 Aug 2022 12:36:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTQgA-0000kd-QT for bug-gnu-emacs@gnu.org; Wed, 31 Aug 2022 12:35:11 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50584) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oTQgA-0003a7-F7 for bug-gnu-emacs@gnu.org; Wed, 31 Aug 2022 12:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oTQg9-0001Yi-VP for bug-gnu-emacs@gnu.org; Wed, 31 Aug 2022 12:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 31 Aug 2022 16:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57434 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 57434-submit@debbugs.gnu.org id=B57434.16619636545936 (code B ref 57434); Wed, 31 Aug 2022 16:35:01 +0000 Original-Received: (at 57434) by debbugs.gnu.org; 31 Aug 2022 16:34:14 +0000 Original-Received: from localhost ([127.0.0.1]:40333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTQfO-0001Xf-4V for submit@debbugs.gnu.org; Wed, 31 Aug 2022 12:34:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTQfJ-0001XO-Ds for 57434@debbugs.gnu.org; Wed, 31 Aug 2022 12:34:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48590) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTQfE-0003SO-2p; Wed, 31 Aug 2022 12:34:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=iTEvFXINBBTTrBRdFQHANUfz1nUNxwBxDBGCm2N5MMA=; b=UhPFtBrEppYD 1/NPLR3kbRFdccoBVEKoe4a7rr1Q2wS928+5SUofCQyX5KrkbfBN5/rArn/gpA7Lr/6aBJqN6BHXw VmS1lu2+XCBgAYZVdfZPIRdOIl6UDs3PcTNtYleV5fkpy78olaFVIsTJhtvb+kWuKeAZHqLKGLGi1 L6iIyX4gnY+b1EXY0wY/GdbpH/j/fepRSyShnGYjbzmm2s3BdatZPuy16o0X03XV2UXirxd4UEg82 Nh7GDZhRizeiy3IPRy7aLYYCx6MCCndtLgfS7V9rv6OsVJpZgyucXNq3pvLvBylboIxYBeFfrYTnD Wlf6u96cW5ojF7ID/uFvFA==; Original-Received: from [87.69.77.57] (port=1876 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTQfD-0005z9-HJ; Wed, 31 Aug 2022 12:34:03 -0400 In-Reply-To: (message from Dmitrii Kuragin on Wed, 31 Aug 2022 09:21:00 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:241212 Archived-At: > 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. > 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?