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#45898: 27.1; wedged in redisplay again Date: Mon, 13 Jun 2022 15:57:59 +0300 Message-ID: <83zgigu3e0.fsf@gnu.org> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <87h74wh9x7.fsf@gnus.org> <83bkv47evy.fsf@gnu.org> <87k09rbcmn.fsf@gnus.org> <83a6an5jt3.fsf@gnu.org> <8335gf5er3.fsf@gnu.org> <87leu686z4.fsf@gnus.org> <83sfoe2k0j.fsf@gnu.org> <87zgim6qtt.fsf@gnus.org> <83mtem2dc9.fsf@gnu.org> <87y1y63qmq.fsf@gnus.org> <83h74t3k5u.fsf@gnu.org> <87tu8sx569.fsf@gnus.org> <83v8t6us8t.fsf@gnu.org> <87zgiinptk.fsf@gnus.org> <83mteiufih.fsf@gnu.org> <877d5kojbo.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4364"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org To: Lars Ingebrigtsen , Phil Sainty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 13 14:59:17 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 1o0jf3-0000xx-0O for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jun 2022 14:59:17 +0200 Original-Received: from localhost ([::1]:40494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0jf2-0007qa-2C for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jun 2022 08:59:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54148) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0jep-0007oz-0j for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 08:59:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o0jeo-0008Mo-Fk for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 08:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o0jeo-0001NN-Ef for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 08:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Jun 2022 12:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45898 X-GNU-PR-Package: emacs Original-Received: via spool by 45898-submit@debbugs.gnu.org id=B45898.16551251025235 (code B ref 45898); Mon, 13 Jun 2022 12:59:02 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 13 Jun 2022 12:58:22 +0000 Original-Received: from localhost ([127.0.0.1]:57573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0je9-0001MN-Pn for submit@debbugs.gnu.org; Mon, 13 Jun 2022 08:58:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0je7-0001M4-EB for 45898@debbugs.gnu.org; Mon, 13 Jun 2022 08:58:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38242) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0je1-0008Gf-Q2; Mon, 13 Jun 2022 08:58:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6icF7tsacamO05keJJ/eCR018GGhpMP6pc5l3EZTctg=; b=bOiD5w/S9RKguKHNPv+f NKEoEE5XoZOPfc9X5lOcY+VcrtpYSz510WBXUPiAdEGygtlCLUPokTSq4xrTp+xb9O4XaeLe2JCfm 3OrvMxYkcHhXtUgBI8bAR6d88wvxBM6SVrtDm9sllB6TxkDW+WNiTi/qXJxdlkGNJTlYQLleFpZPh +EaSsrmlDKm0lvfpy1Q3Bw/0CDh+5n2URuUDiHalC3YLxVp2SLGk+F6xDPbZAZyNVbRKB6pIHrmLx mWZXqqBuunc7sCpuqJ0h4hsq1ujUraFayrDrIpbeBs5Z1AodDC6WoiNFIJdvEwbQTkpze2bbuJoTs wmyRRt48bzolFA==; Original-Received: from [87.69.77.57] (port=4684 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 1o0je1-0000Hu-A5; Mon, 13 Jun 2022 08:58:13 -0400 In-Reply-To: <877d5kojbo.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 13 Jun 2022 14:10:19 +0200) 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:234396 Archived-At: > From: Lars Ingebrigtsen > Cc: Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org > Date: Mon, 13 Jun 2022 14:10:19 +0200 > > Eli Zaretskii writes: > > > Here's the first cut. It still needs polishing and some testing, but > > let me know what you think: > > [...] > > > +/* Update the redisplay-tick count for a window, and signal an error > > + if the tick count is above some threshold, indicating that > > + redisplay of the window takes "too long". > > Ah, instead of measuring the time elapsed, we use the number of iterator > "executions" as a proxy. That sounds promising. Yes. That idea came up while discussing this with Gerd Möllmann, btw. It's much simpler than measuring time (which would require high-resolution timing, which is much less portable and more tricky to get right, what with modern systems constantly adjusting their time). > One problem that occurs to me is if you're, say, only displaying a shell > buffer, and it's outputting data -- then I don't think we'll be changing > windows, but just accruing ticks? But I think that should be easy > enough to fix, since we'll be returning to command_loop and we could > just have that nixing out the tick count, too. Probably. Yes, zeroing out the count when redisplay is done is probably a good idea. It's on my todo, probably in mark_window_display_accurate_1 or thereabouts. The only consideration here is that a successful redisplay of a window could be followed by something like vertical-motion across the same window, which could take "too long", and we perhaps want the counters to be accumulated. Hmm... (Actually, output in a shell buffer is not a problem, because comint calls 'recenter' very frequently, at least by default, and 'recenter' resets the ticks count. But maybe there are other situations where this isn't guaranteed to happen. So yeah, maybe command_loop is a better place.) > A different problem is when we don't have many ticks, but each tick > takes a long time to execute. The classic problem here is when we have > a font-locking regexp that's very complicated (with lots of > backtracking). Then we don't update anything on the screen much -- we > spend (virtually) all the time in the regexp matcher. I don't see an > easy fix to that using this scheme... That's why update_redisplay_ticks accepts its first argument, instead of always adding 1: I thought about some potentially expensive operations that could be either more or less expensive than just processing a single character. E.g., font-lock calls regexp matching, so we should try to come up with some measure of its "expensiveness" based on...something. This will need some tuning, but all we need is some coarse correlation. > > For testing purposes, is it possible to have examples of files that > > could benefit from this feature, i.e. files where Emacs becomes not > > responsive enough? I'm not sure the few examples I have cover all the > > popular reasons for the slowness, as I think there are more than one > > or two. > > I don't have anything handy... anybody else have a setup that will > freeze Emacs redisplay that we can test with? "Freeze" is not actually a requirement; it's enough if Emacs's responses become very slow. For now, I used the file described here: https://lists.gnu.org/archive/html/help-gnu-emacs/2022-05/msg00070.html But it is only one kind of such files. Perhaps Phil could point me to additional examples; added to CC.