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#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS Date: Wed, 03 May 2023 16:08:04 +0300 Message-ID: <835y99mukr.fsf@gnu.org> References: <87ilddec31.fsf@yahoo.com> <87edo0exct.fsf@yahoo.com> <83wn1sns1n.fsf@gnu.org> <87pm7kchqw.fsf@yahoo.com> <83pm7knpzi.fsf@gnu.org> <83354eordx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33134"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 63187@debbugs.gnu.org, aaronjensen@gmail.com To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 03 15:08:27 2023 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 1puCDb-0008NV-LI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 May 2023 15:08:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1puCDE-0006As-EM; Wed, 03 May 2023 09:08:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1puCDC-0006Ad-VL for bug-gnu-emacs@gnu.org; Wed, 03 May 2023 09:08:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1puCDC-0003Dc-EM for bug-gnu-emacs@gnu.org; Wed, 03 May 2023 09:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1puCDB-0003Ja-UG for bug-gnu-emacs@gnu.org; Wed, 03 May 2023 09:08: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, 03 May 2023 13:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63187 X-GNU-PR-Package: emacs Original-Received: via spool by 63187-submit@debbugs.gnu.org id=B63187.168311924812698 (code B ref 63187); Wed, 03 May 2023 13:08:01 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 3 May 2023 13:07:28 +0000 Original-Received: from localhost ([127.0.0.1]:45944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puCCe-0003Ik-1C for submit@debbugs.gnu.org; Wed, 03 May 2023 09:07:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puCCb-0003IU-EZ for 63187@debbugs.gnu.org; Wed, 03 May 2023 09:07:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1puCCU-000339-Sd; Wed, 03 May 2023 09:07:18 -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=4wBXnVRlSLYnti4cuEekANJeIp02AgLa6Bzm3hfwfVY=; b=WaRxE0XE6TaN 6tlGeoRaWUigUzvJ8hSbPHFSjqSgfHk6eG0rhbA7xL6sMt4nCfkP8bZrLxUqvtYEsd0ZudItDscSE SHGzJMPgTu+InfFb03234kAORri89An44JSDmS1Bx6p4oT6+qw012XfAGJTAqoDkbwMduonlRItuB DCLLyijmVB/Dh8pUjvR92XEXaiVU2y1yNs6WYRUQoCNxOhwaRXnpz19ZLd80Q/RfyzXbJHtwJyTTh qhrzC8SBBel71awf+SyPauMhiBMBCi24pM6OlYXUxwSwjIwI8v80/lRj8dEBDLNNCQYq24jNxXfbh 803Eb27NaaMOrCccgi2KgQ==; Original-Received: from [87.69.77.57] (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 1puCCU-00007B-2K; Wed, 03 May 2023 09:07:18 -0400 In-Reply-To: (message from Alan Third on Tue, 2 May 2023 23:36:34 +0100) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260976 Archived-At: > Date: Tue, 2 May 2023 23:36:34 +0100 > From: Alan Third > Cc: aaronjensen@gmail.com, luangruo@yahoo.com, 63187@debbugs.gnu.org > > On Tue, May 02, 2023 at 03:21:46PM +0300, Eli Zaretskii wrote: > > > Date: Tue, 2 May 2023 11:14:56 +0100 > > > From: Alan Third > > > Cc: Eli Zaretskii , Po Lu , > > > 63187@debbugs.gnu.org > > > > > > Although, on reflection, your description sounds more like it's just > > > not clearing the end of lines correctly, which wouldn't necessarily > > > have anything to do with scrolling as such... > > > > Can that happen in this case? You will see in the code that (AFAIU) > > it copies a rectangle whose width is the total width of the window, so > > why would (not) clearing ends of lines be an issue? > > It depends where the actual problem is occurring. It's hard to tell > from the screenshots whether the rogue glyphs appear spontaneously in > the middle of the window, or as a new line is scrolled onto the > screen. AFAIU, a new line scrolled into the screen is not handled by scroll_run_hook. Such a line is drawn anew, because there's no way we have it in the glyph matrices and/or on the glass, by definition. > As it scrolls further, Emacs no doubt is clever enough to know that it > doesn't need to clear more than it drew for the last line, so the > rogue characters at the end stay for the subsequent line, and so on > until it hits a line that is long enough to wipe it all out. I think you are describing something that happens only on TTY terminals, if ever. Emacs doesn't work that way on GUI terminals, and if scroll_run_hook is indeed the culprit (that remains yet to be proven, AFAIU), it is used in situations that are not necessarily "scrolling" from the user POV. This hook is run when Emacs determines that some part of the display is exactly what is needed to be displayed, but it is higher or lower on the screen than where it should be. Then (subject to some criteria of whether this optimization is worth our while), we call this hook, which is supposed to copy the pixels on the screen in the vertical direction, either up or down. It always copies the entire width of the window, so clearing to EOL should not be the issue here, since the "cleared" pixels are moved as well.