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: Sat, 25 Jun 2022 09:29:54 +0300 Message-ID: <83r13db6hp.fsf@gnu.org> 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> 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="15349"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45898@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 25 08:32: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 1o4zLF-0003qk-IX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jun 2022 08:32:25 +0200 Original-Received: from localhost ([::1]:50776 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4zLD-0003Sn-J4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jun 2022 02:32:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4zJw-0003RN-55 for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 02:31:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50118) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4zJu-0000la-98 for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 02:31:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o4zJu-0002GV-4P for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 02:31: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: Sat, 25 Jun 2022 06:31: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.16561386088611 (code B ref 45898); Sat, 25 Jun 2022 06:31:02 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 25 Jun 2022 06:30:08 +0000 Original-Received: from localhost ([127.0.0.1]:44015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4zJ1-0002EA-Nc for submit@debbugs.gnu.org; Sat, 25 Jun 2022 02:30:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4zIz-0002DD-AO for 45898@debbugs.gnu.org; Sat, 25 Jun 2022 02:30:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54382) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4zIu-0000PR-2p; Sat, 25 Jun 2022 02:30:00 -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=rGaqgkm8hv6JLqWAVjJZQ57+sgNDrcUybBMEOpmwxL8=; b=Jh9CSeWxJXjEgpfGbVXx L3ckjhV6mZ/2g/swKTzoY5+bmczjhhVOg71DQ20CCEEoCFBDweXQ0si54WvBpzSSq6PBdctAKroyS LyrmoscO7mnvZrwYTtR4o8TfKsmDR9WsosXTxt/KBP74xXCVSt++bMg7PGCgHUtFwSKYB/AhLiieo amC6ZiDv16K2c33VVoTKiKMRko+S3wGgAQ7i4FnvHA6+KjsowlbjZmm4CMKKweJE/INbPd8Dmq680 WsOB01Df+6BsT/aabdMQomb2xa1Gd8dYbZOKUFGjABeADkdEU1eFIWk9TeeupNCHR2R4TUf5Jq3FP luT8TUTO4/8g3Q==; Original-Received: from [87.69.77.57] (port=2291 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 1o4zIt-0006VT-Im; Sat, 25 Jun 2022 02:29:59 -0400 In-Reply-To: <0B5FE52E-BC81-4A05-86F1-91C6AFCB6F7D@gmail.com> (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sat, 25 Jun 2022 06:54: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:235233 Archived-At: > From: Gerd Möllmann > Date: Sat, 25 Jun 2022 06:54:19 +0200 > Cc: 45898@debbugs.gnu.org > > I think it helps me in the following when I briefly describe the model of Emacs’ internals I have in my head. > That way, I can write about things in terms in which I think. So, let me try. When I think of Emacs' design, I > think of functions and categories they belong to. Categories in the sense of animal, dog, human, plant. A > bit like modules, but not quite, but if it’s helpful, just think of modules instead. > > The categories I'd like to use here, are lisp, redisplay, iterator, update, regexp. I leave the rest out. Here is > what I group under these categories: That's clear, thanks. > One of the first things that came to my mind is a new category "time fuse" (in German Zeitzünder), > 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. 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. > Functionality-wise, Iterator now signals an error that redisplay catches. 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. > 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. > > 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. 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. > (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.) Yes, it could cause GC, but I'm not sure what you mean by "we might need that". What is "that" here? 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. > Maybe we could disable the calls cheaply when max-ticks is 0? I mean, something that inlines > > if (max_ticks > 0) > update_ticks(...) Yes, maybe. > 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: > > /* True while some display-engine code is working on layout of some > window. 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. > Do you want me to take a deeper look at specific places? 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 https://lists.gnu.org/archive/html/emacs-diffs/2022-06/msg00761.html (I will redirect that to here, as emacs-diffs is not for discussions of this sort.)