From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#45898: 27.1; wedged in redisplay again Date: Mon, 13 Jun 2022 14:10:19 +0200 Message-ID: <877d5kojbo.fsf@gnus.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13891"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 13 14:17:27 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 1o0j0Z-0003Mi-BU for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jun 2022 14:17:27 +0200 Original-Received: from localhost ([::1]:38358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0j0Y-0004Z0-3x for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jun 2022 08:17:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0iuM-0006W0-Ja for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 08:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35294) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o0iuM-0007eF-7p for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 08:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o0iuL-00043E-RP for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 08:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Jun 2022 12:11:01 +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.165512224515549 (code B ref 45898); Mon, 13 Jun 2022 12:11:01 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 13 Jun 2022 12:10:45 +0000 Original-Received: from localhost ([127.0.0.1]:57424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0iu4-00042i-Rp for submit@debbugs.gnu.org; Mon, 13 Jun 2022 08:10:45 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:36478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0itr-00042B-2U for 45898@debbugs.gnu.org; Mon, 13 Jun 2022 08:10:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=V2VfBHKA/7/bDSggS9RBi7Gt3E1CUR67zMjl/o7+Jdg=; b=ATLjyJFRMfBIan19aqmo6CVnWN IN0QYDeGGp78PkkQc/Y6lH+32cLltlcj4eW2cSKvKja19d1cFWmtf2Kw6j8Q7If+eqyz1nohu1alz Ph2Y5rrU8N/lNsSSFRZKh40Q8Kzlx825X/UMjNkYaHctJ2mR/31nS+MKo+OzbXunBAac=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o0itg-00085Y-JR; Mon, 13 Jun 2022 14:10:23 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEX89Obm3dLExsbI raetnpqrP06gX2aKZWf///+53gUxAAAAAWJLR0QIht6VegAAAAd0SU1FB+YGDQwDJG/XMTQAAAGz SURBVDjLjZK9c5wwEMVXwCStVsdQI8HhFgS5tAfodH2MqB2+0nuc+/sDHl8yXuyZbKPh/dint5IA /rOY/Ej1YvDKD3TfaPAqTmWO3/qqYYrqwYuw863fOwVGVsvJzTun0Jjr/OjmMwXZL1tfutnlFERL L4+dnXZWx5t7zm79uLM6XdyPq22nhraIrB9Nok2NBBxSd32udNaxHZj7rtJHR6xYWfWdzV7mnjS0 xrp+nt38kzS0VerW6i80U/k9dd1KOgISIYzrzG9D5mOFhtOk1MMQE7De26lWIh1pWBND0OSY7k6K xdtTQEUa/FdnxoGeYHR+FRBoR1TW26JUSkOFZ5DgNdIQANHT+gLDRklJvfJDwbRSwiQ0b1L6k1bG 0O2hKoVZSxd09AR5jKjWIQlQCjnjyGJGiGrQ44gecO+9WapQIAoJKN+3CCGLQgoUguRiiRLIcN3m rtw5owNs3/5dPBAgOC80KwE15HVdlOEbOFg+pFU6gB1hwMdxWd5AZGD6qkwNdoDO66Z/YAQT8Cnf wOLbxYb8L7h9ydtms1qCbDndQdhCE5x5CUkBkgHNTUt98sMfu55QrmcV2VoAAAAldEVYdGRhdGU6 Y3JlYXRlADIwMjItMDYtMTNUMTI6MDM6MzYrMDA6MDDqRQY3AAAAJXRFWHRkYXRlOm1vZGlmeQAy MDIyLTA2LTEzVDEyOjAzOjM2KzAwOjAwmxi+iwAAAABJRU5ErkJggg== X-Now-Playing: Wrangler's _Ni d'eve, ni d'adam_: "Harder" In-Reply-To: <83mteiufih.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Jun 2022 17:23:50 +0300") 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:234385 Archived-At: 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. 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. 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... > 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? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no