From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#45898: 27.1; wedged in redisplay again Date: Sat, 25 Jun 2022 11:49:42 +0200 Message-ID: <56F03F59-40AD-48F2-92C8-9858C2423327@gmail.com> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <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> <83zgigu3e0.fsf@gnu.org> <500e4b9c69f2a90e7cf05b956178d71b@webmail.orcon.net.nz> <835yl3tnv3.fsf@gnu.org> <83iloyo0x7.fsf@gnu.org> <83mte5jukr.fsf@gnu.org> <837d57gbed.fsf@gnu.org> <83o7yicx3p.fsf@gnu.org> < 0B5FE52E-BC81-4A05-86F1-91C6AFCB6F7D@gmail.com> <83r13db6hp.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37880"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45898@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 25 11:50:25 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 1o52Qq-0009hi-PD for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jun 2022 11:50:24 +0200 Original-Received: from localhost ([::1]:51158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o52Qp-0005uF-Ed for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jun 2022 05:50:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49572) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o52QU-0005ti-57 for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 05:50:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50258) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o52QT-0004MC-T0 for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 05:50:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o52QT-00077W-Pi for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 05:50:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Jun 2022 09:50: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.165615059227351 (code B ref 45898); Sat, 25 Jun 2022 09:50:01 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 25 Jun 2022 09:49:52 +0000 Original-Received: from localhost ([127.0.0.1]:44155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o52QK-000774-BF for submit@debbugs.gnu.org; Sat, 25 Jun 2022 05:49:52 -0400 Original-Received: from mail-ed1-f43.google.com ([209.85.208.43]:39507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o52QH-00076q-RH for 45898@debbugs.gnu.org; Sat, 25 Jun 2022 05:49:50 -0400 Original-Received: by mail-ed1-f43.google.com with SMTP id eq6so6544798edb.6 for <45898@debbugs.gnu.org>; Sat, 25 Jun 2022 02:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZFklzMEmYOmqwKrzn5W+DcDDqrYaiiocABZT93+1BhE=; b=aXiyOaI43Lb3HdpaOL+HFfajwqwdopyMoLDyxWpi+nOHhcnbMT62Q6uWb8buwW/RlW C5BeX52/Nn/shmms0hWevEFjbH3lvrJhgiC9RutL0oyr4ydrwN7FNliuLAsbX+UEkDQ5 PsseCMpimG848iUyLiSpV/4JGaqdbOw3wc3fNA+dw0gKTtQDwFn/QkZWTEicFql4wDeD qF+RNMvSAYuR/KUMnHCEAlfsGxIaBEgw4igb7s+Y3+2ANEJc0kfKZPQYEF2YRXIZczQ6 OQQEdY5sVH+44gt08jbX3rOk2Q2oryAfNzXW/61VyL9s209ODhrzoDaI+T01v5RbL6p3 1G4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZFklzMEmYOmqwKrzn5W+DcDDqrYaiiocABZT93+1BhE=; b=F56oLRPwPK6bnlyqW4oI850JXmR4INn/Tz+xwxt6PC/psz9rf8fQEzTI2f2fkRB3lv YxwBj6R2ZQSPS4BhUqpt7Rf6V0PzLGmZaoqe+FLUMXsdKZekHBzu5wVUudXO0q3TcqqQ VxOKWPsFBPkVHsACGeArdOchcfnh0Mp8DZAGSjbjtn2oj9Mbcz0+oN/c4IAjJ5DRtFyq B8k8L2feE5SNqHu0x9spOv/Xsz3HK9qvdWq2f84gjfLONJ4+fTRpcdpih96c2zJ7naID YuI8W/EIQ9LTQ3ceg5O9iYVOwe+nIFY80/kzBWVrM/QKpVmc7qxU5DMtbiL2b0/6zMOP +q3g== X-Gm-Message-State: AJIora8Yj5Dbie3ISGY9mfBCKTMqZro2vul33HF+DsgsB2K54D3OE/CD rRxK1Ct9c6l6YEKLEHzvXkA= X-Google-Smtp-Source: AGRyM1sgi3vo2susV49UW5qeFmrRqZKXEtaX7PMNFJ1TjR6aNfS4ScdtE41IVVqduAUgifJuiyu+AA== X-Received: by 2002:aa7:c846:0:b0:431:6c7b:26af with SMTP id g6-20020aa7c846000000b004316c7b26afmr4042070edt.123.1656150583620; Sat, 25 Jun 2022 02:49:43 -0700 (PDT) Original-Received: from smtpclient.apple (p4fe3a040.dip0.t-ipconnect.de. [79.227.160.64]) by smtp.gmail.com with ESMTPSA id u17-20020a056402111100b0042deea0e961sm3807455edv.67.2022.06.25.02.49.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jun 2022 02:49:42 -0700 (PDT) In-Reply-To: <83r13db6hp.fsf@gnu.org> X-Mailer: Apple Mail (2.3696.100.31) 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:235243 Archived-At: > On 2022-06-25,, at 8:29 , Eli Zaretskii wrote: >=20 >> One of the first things that came to my mind is a new category "time = fuse" (in German Zeitz=C3=BCnder), >> something counting ticks, and detonating (signaling) at some point. = I admit that I find the names you used >> with redisplay in them confusing. Especially in the regexp code and = so. >=20 > That's mainly to keep the names from getting too long to be useful. I > could have used something like update_display_code_iteration_ticks, > but it looked to me that "redisplay" is a good way of saying "display > code" shorter. Well... update_display_code_iteration_ticks also makes me twitch because = I think of the tick/signal business not part of "display". What I have = in my head is regexp -> ticks, and iterator -> ticks, where "ticks" = would be replaced with some suitable name. I think regexp should also be = interrupted with long lines, when we match a line that is too long. Or = not? Or maybe "ticks" is already a good enough name? We could then simply = have update_ticks and good. Or eticks to not confuse it with time = ticks, if that ever happens. >=20 >> Functionality-wise, Iterator now signals an error that redisplay = catches.=20 >=20 > Yes, that's the main idea. But note that in some cases Iterator is > called directly from Lisp, not from Redisplay, in which case the error > is caught by the command loop (not sure where that is in your > taxonomy? is that also Lisp?), not by Redisplay. Case in point: C-n. Yes, that's what I meant by lisp -> iterator, using the move_it* "API". I left out the command-loop, but it's also something I'd consider a = category. >=20 >> The error is signaled when a global tick counter exceeds a max value. = Each movement of an iterator >> increments the global tick counter. The counter is global because = you want to sum up all the ticks that >> occur between a given start point where the tick counter is set to 0, = and the point where the ticks exceed the >> maximum, regardless of iterator -> lisp -> iterator nesting. >>=20 >> The global tick counter is also incremented from regexp. I think = font-lock plays a role here. One scenario is >> redisplay or lisp -> iterator, iterator needs font-lock to run (-> = lisp), font-lock matches a regexp (lisp -> >> regexp), and we get stuck on a long line. Likewise with other stuff, = like syntax. >=20 > Right. But I want to explain why I count ticks in regexp, in > syntax.c, and in some places in bidi.c. The reason is that a single > call to set_iterator_to_next, which basically counts as one tick, can > sometimes result in prolonged operations. So some ticks are "more > equal" than others, and I looked for a way of expressing that. What > you see in those other places is the result of that: it makes > iteration steps that trigger prolonged examination of buffer text to > count as more than one tick. I've seen that, and I think that's fine. >=20 >> (BTW, the call to update the tick in regexp can lead to a GC when the = error is signaled, in the same way as >> in bug 56108 with maybe_quit. So we might need that, too.) >=20 > Yes, it could cause GC, but I'm not sure what you mean by "we might > need that". What is "that" here? =20 I meant a fix for that bug. =20 Might be something specific to German. People say "I need that bug for = the next release", and mean the fix, because they have the bug already = :-). > Did you mean we should count ticks > inside GC as well? If so, we'd need to have some way of preventing a > signal when the tick count reaches the threshold, because we cannot > signal an error inside GC. No, I didn't think of that. >> The meaning of display_working_on_window_p is not clear to me. I see = what setting it does in the end, but I >> can't tell what this means: >>=20 >> /* True while some display-engine code is working on layout of some >> window. >=20 > The reason for that kludge is the urge to avoid signaling an error > when regexp or syntax.c is called in the context that is not related > to any display code whatsoever. Since these functions don't know > whether they are invoked by some code in Iterator or by Lisp, they > will count the ticks regardless, and I don't want them to signal an > error if they happen to count too many ticks. You mean a case, where small numbers of ticks sum up by calling these = Lisp functions often enough? >=20 >> Do you want me to take a deeper look at specific places? >=20 > As you wish. I just wanted a second opinion on the overall design, > and my main worry besides that is whether there are situations where > this simple mechanism could cause trouble. E.g., Lars already > uncovered one such situation, see >=20 > https://lists.gnu.org/archive/html/emacs-diffs/2022-06/msg00761.html >=20 > (I will redirect that to here, as emacs-diffs is not for discussions > of this sort.) Apart from features I don't know, I don't see any fundamental problem = with your approach.