From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely Date: Thu, 15 Sep 2022 22:07:24 +0200 Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f8ea7605e8bccb24" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32969"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 15 22:08:20 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 1oYv9o-0008OO-Iq for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 22:08:20 +0200 Original-Received: from localhost ([::1]:48788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYv9n-0001Qw-LE for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 16:08:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYv9X-0001Qo-1d for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:08:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42336) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYv9W-0002Bo-O5 for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYv9W-00047T-Fw for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Sep 2022 20:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57804 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 57804-submit@debbugs.gnu.org id=B57804.166327246515813 (code B ref 57804); Thu, 15 Sep 2022 20:08:02 +0000 Original-Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:07:45 +0000 Original-Received: from localhost ([127.0.0.1]:59268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYv9F-00046z-2Q for submit@debbugs.gnu.org; Thu, 15 Sep 2022 16:07:45 -0400 Original-Received: from mail-ed1-f45.google.com ([209.85.208.45]:38465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYv9D-00046l-AR for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 16:07:44 -0400 Original-Received: by mail-ed1-f45.google.com with SMTP id e17so28603705edc.5 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 13:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=LvEoviZE17G+Fty/bHPzbP4QSMjDzBEoSkkFvHfNY+Y=; b=ipu3E4NKwF9XknC5c/x8Nq7NLQlL0IYznf5cjN58cWrv1KTInxT369tRZ27yuh9m+S LdOewbOfrC2J+i+zMWhOFr9lCDKzOlUluVkbwubTZweEfLjWJ+bX4F7ak5cZ2Gdcsyfe 6bOKbMbnU/mXL1sjcmxtlQMzWCsrMP5ubzEaOXKd7OtfbQzSxblEoM1x8EiTiq8jePb5 MdbN1zQ7MzPiMcG1+B1mR2BhD0H/mgNx/ArSOexQScfRVeNa3MxY/sn1/Be1dqXkjjDM dmowt6s1WlI2TQ5ul+e54bRQWGjT1u5fcFsj9AJmc0LipSPgXbNdUrty2lhYQ8wXXvr0 hQMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=LvEoviZE17G+Fty/bHPzbP4QSMjDzBEoSkkFvHfNY+Y=; b=1xeQpVCHngisSeJEVNtaKCAOlsc+irlHC1w4gOCJTBCdvLfjqP00aytURVMgJHyDEq pZz8g3z1ac2LsgCshFDwzkK8xV7dKPz9K4EIReIdFbnfyShji+irI3CktFkucvE0T4x3 tMlsYke8Pyv9e6NCdKabfOKzhrfJXzrfzp/DMDdyqyRRt3NbWwnXkq2eGvIpzBSWGuOP bbprpbhw//L9PLy5jxHqeLWWEmK4MxWEZR1CsKDXZAPDPAUyl8+Q2dG5Y9p8gtbKFeCa W8ahGPYurPatHi0ELiCb+OrRX77x+b9oHZ3R0lszNh4XBf1D/7qMZia0/tRa/YmxDITt izHg== X-Gm-Message-State: ACrzQf30+j5Kxi+DsjSDWBrqX1lXmt0qAvyCcbKBnklMGzQP0Du9wtVn G9MpUA9Xs70mHwLYwvat5OjtsXagicMngbuevA== X-Google-Smtp-Source: AMsMyM4BHPi3ow4uo4/zMflNASDbPNCn0XVlH69ZQVdVgUw0HqexbeDKrJP2Z1Ti/bvXZqvuC3OGnsJ6DDD7g8eIgsg= X-Received: by 2002:a50:a69d:0:b0:44e:bf40:395f with SMTP id e29-20020a50a69d000000b0044ebf40395fmr1289145edc.234.1663272457135; Thu, 15 Sep 2022 13:07:37 -0700 (PDT) In-Reply-To: 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:242644 Archived-At: --000000000000f8ea7605e8bccb24 Content-Type: text/plain; charset="UTF-8" > Why did you immediately set it to nil instead of trying to making it > sufficiently large? You said that some lines in the Logview buffer > are long, but I bet they are never longer than, say, 100000 > characters. How do I decide what is sufficiently large? With this optimization Logview can fall into that infloop in fontification code, at which point Emacs becomes completely frozen, with the only way out to restart it. As have been determined in this thread, this is not a bug. I still kinda want to avoid this non-bug, because it is a bit disruptive to my work. With long lines I can suffer slow and not-quite-responsive (but still not hung to death) Emacs, which is much more bearable. Usually that only happens when I open or grep something like a minified JS file by mistake anyway. For you this long-line optimization is probably very important, maybe you often work with files that trigger this and make using Emacs a pain without it. But for me it's a minor feature that I have barely noticed, but that incidentally completely broke my normal workflow by making Emacs seemingly randomly freeze (until I found time to debug it, which was not easy as Emacs would not respond to anything). > As I told you, the general fix will be to adapt Logview to handle locked > narrowing, by explicitly unlocking the locked narrowing when it needs to > access a larger portion of the buffer. You were somewhat reluctant at > that idea. Maybe I misunderstood you. If I have to add a one-time adjustment to the code to the effect of "unlock the narrowing it inside this block", then it is fine for me. Now that I reread: > the "fully cooked" narrowing will not magically solve that > problem, though. Logview will have to be adapted to deal with > the possibility of a locked narrowing. I don't see implications that unlocking would be impossible. If I only would have to use sth. like sketched (I don't insist on it looking like this): (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t)) (widen) ... ) once the branch is finished and merged (and that it would work for all kinds of tags or whatever at once), then sorry for misunderstanding and starting a heated discussion for nothing. Paul On Thu, 15 Sept 2022 at 21:44, Gregory Heytings wrote: > > >> already told you thrice that a simple way to fix your problem is to set > >> long-line-threshold to a larger value (or to nil). > > > > Thanks, I added `(setf long-line-threshold nil)' to Emacs startup > > configuration file a couple of days before. But unless I'm missing > > something, this is not a fix, only a workaround. > > > > Why did you immediately set it to nil instead of trying to making it > sufficiently large? You said that some lines in the Logview buffer are > long, but I bet they are never longer than, say, 100000 characters. > > As I told you, the general fix will be to adapt Logview to handle locked > narrowing, by explicitly unlocking the locked narrowing when it needs to > access a larger portion of the buffer. You were somewhat reluctant at > that idea. --000000000000f8ea7605e8bccb24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Why did you immediately set it to nil instead of tryi= ng to making it
> sufficiently large?=C2=A0 You said that some lines = in the Logview buffer
> are long, but I bet they are never longer tha= n, say, 100000
> characters.

How do I decide what is sufficien= tly large? With this optimization
Logview can fall into that infloop in = fontification code, at which
point Emacs becomes completely frozen, with= the only way out to
restart it. As have been determined in this thread,= this is not a
bug. I still kinda want to avoid this non-bug, because it= is a bit
disruptive to my work.

With long lines I can suffer slo= w and not-quite-responsive (but still
not hung to death) Emacs, which is= much more bearable. Usually that
only happens when I open or grep somet= hing like a minified JS file by
mistake anyway.

For you this long= -line optimization is probably very important, maybe
you often work with= files that trigger this and make using Emacs a
pain without it. But for= me it's a minor feature that I have barely
noticed, but that incide= ntally completely broke my normal workflow by
making Emacs seemingly ran= domly freeze (until I found time to debug
it, which was not easy as Emac= s would not respond to anything).

> As I told you= , the general fix will be to adapt Logview to handle locked
> narrowi= ng, by explicitly unlocking the locked narrowing when it needs to
> a= ccess a larger portion of the buffer.=C2=A0 You were somewhat reluctant at<= br>> that idea.

Maybe I misunderstood you. If I have to add a one= -time adjustment to
the code to the effect of "unlock the narrowing= it inside this block",
then it is fine for me. Now that I reread:<= br>
=C2=A0 =C2=A0 > the "fully cooked" narrowing will not m= agically solve that
=C2=A0 =C2=A0 > problem, though.=C2=A0 Logview wi= ll have to be adapted to deal with
=C2=A0 =C2=A0 > the possibility of= a locked narrowing.

I don't see implications that unlocking wou= ld be impossible. If I only
would have to use sth. like sketched (I don&= #39;t insist on it looking
like this):

=C2=A0 =C2=A0 (= let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t))
=C2= =A0 =C2=A0 =C2=A0 (widen)
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2= =A0 )

once the branch is finished and merged (and that it would work= for all
kinds of tags or whatever at once), then sorry for misunderstan= ding
and starting a heated discussion for nothing.

Paul
=

= On Thu, 15 Sept 2022 at 21:44, Gregory Heytings <gregory@heytings.org> wrote:

>> already told you thrice that a simple way to fix your problem is t= o set
>> long-line-threshold to a larger value (or to nil).
>
> Thanks, I added=C2=A0 `(setf long-line-threshold nil)' to Emacs st= artup
> configuration file a couple of days before. But unless I'm missing=
> something, this is not a fix, only a workaround.
>

Why did you immediately set it to nil instead of trying to making it
sufficiently large?=C2=A0 You said that some lines in the Logview buffer ar= e
long, but I bet they are never longer than, say, 100000 characters.

As I told you, the general fix will be to adapt Logview to handle locked narrowing, by explicitly unlocking the locked narrowing when it needs to access a larger portion of the buffer.=C2=A0 You were somewhat reluctant at=
that idea.
--000000000000f8ea7605e8bccb24--