From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 11:06:12 2022 Received: (at submit) by debbugs.gnu.org; 14 Sep 2022 15:06:12 +0000 Received: from localhost ([127.0.0.1]:55765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYTxs-0000fU-1Q for submit@debbugs.gnu.org; Wed, 14 Sep 2022 11:06:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:43330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYTxq-0000fN-RN for submit@debbugs.gnu.org; Wed, 14 Sep 2022 11:06:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYTxq-00082T-BL for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 11:06:10 -0400 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:41474) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYTxo-0002ZC-GG for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 11:06:10 -0400 Received: by mail-ej1-x636.google.com with SMTP id gh9so35448138ejc.8 for ; Wed, 14 Sep 2022 08:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=HfX8oxoz4YK2qJagf1k2ham4M5gdQOD71eP6x7j3nHQ=; b=CGmUftvrxLP1X9x0urz01Ymah8VOhH1LOl6L8o1ubNRg0zpW6TdYQ3J7X/j+Bmtre3 Er4X2qE1PHg75x8ynovSnjFFFq6QvwHVWid9WYtxDv+bWJt0hIaz9REt1B8+SVWrUENF 21kTrLct5eylAlUg2SnvB869oPZyhfJlGgLCb69t3cXouCjvZM/AZvizD4yJyhkgkmqF M69MrGKB9QJjaowKlmOsPAkt/JU65tQlcN4nRFIgK0eZl6suvT5USg/8pkl3BvIgT1sK gHqokwBOQ7SgfpQdM80Ict/m9TPR7o8FiVYtn6ycIcLyfiCmlsm7AV71dlCMFtFUiB1M Sung== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=HfX8oxoz4YK2qJagf1k2ham4M5gdQOD71eP6x7j3nHQ=; b=dsW/w7HbZpkLLJjPfZYkkE8ms40esSEDrLRYjwaUWZ4Wt3F6cK13khZNsjdjayh20B dEbHK08pWDgjx0UlQZRiACMsoZbaGjj9Wq3SDZy+4zLQ1/mAmQZAyGFn5zmBpRpmzoEi GSe03VeWzIvLZOEjPLIBlGNW0zGcV9ivFz6acD01WzRZaqOKO3/ehM2oLGgvQBkbh++N +UTPRIOQUWEbmbAYDBZOx2QNGGehWUT5P5ShZk3tjrra+P5gGk4fhDPTJn6RQjToraL+ XupGjbFOQfYMCJBWr5dm6GgmysJ8iC3h9E40M+o+TsdP1t8PfGyA0MTZtjewIbi8Wm9b oQmg== X-Gm-Message-State: ACgBeo0jJCUgtjEhevjHZFAfLkwhP3xIMw8CPw6buy57QBunIPPTbF8f Uy3z12IYE65GsgEysBP4sK00vyLd37xNmgTm6QVEKalyYw== X-Google-Smtp-Source: AA6agR4EcbrkSB87NITkaBAz5UHLolXeq35e9nvN5zx7nhG3SgjPu399/p17tLI+AmiQ/xbdz0wLgzNJ6k3udx7fj7A= X-Received: by 2002:a17:906:fe09:b0:77a:52b3:da5d with SMTP id wy9-20020a170906fe0900b0077a52b3da5dmr16866687ejb.57.1663167966338; Wed, 14 Sep 2022 08:06:06 -0700 (PDT) MIME-Version: 1.0 From: Paul Pogonyshev Date: Wed, 14 Sep 2022 17:05:54 +0200 Message-ID: Subject: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="000000000000d613ca05e8a47723" Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=pogonyshev@gmail.com; helo=mail-ej1-x636.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000d613ca05e8a47723 Content-Type: multipart/alternative; boundary="000000000000d613c705e8a47721" --000000000000d613c705e8a47721 Content-Type: text/plain; charset="UTF-8" To reproduce, save the attachment as `font-lock-hangs.el' and execute: $ emacs -Q -l font-lock-hangs.el C-g doesn't help anymore. The only thing you can do is to kill and start Emacs anew. Git commit fd1ee05977. To quote a discussion from another bug, the reply is from Eli Zaretski: > > By the way, it would really be nice if Emacs could do something about hangs irrespective of what causes > > that. Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop > > responding to C-g, leaving full restart as the only way out. > > I think that's impossible in general, unless we restrict what Lisp > programs can do. Every programming language can be used to write a > buggy program. > > However, it should be possible to prevent some cases of such > problematic behavior, certainly so when the infloop is caused by our > bug. But for that we need to know the details of the specific case in > order to investigate. Paul --000000000000d613c705e8a47721 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To reproduce, save the attachment as `font-lock-hangs= .el' and execute:

=C2=A0 =C2=A0 $ emacs -Q -l = font-lock-hangs.el

C-g doesn't help anymore. The on= ly thing you can do is to kill and start Emacs anew.

Git= commit=C2=A0fd1ee05977.

To quote a discussion fro= m another bug, the reply is from Eli Zaretski:

>= ; > By the way, it would really be nice if Emacs could do something abou= t hangs irrespective of what causes
> > that. Even if Elisp code i= s buggy, Emacs itself should never allow it to fall into an infinite loop a= nd stop
> > responding to C-g, leaving full restart as the only wa= y out.
>
> I think that's impossible in general, unless we= restrict what Lisp
> programs can do.=C2=A0 Every programming langua= ge can be used to write a
> buggy program.
>
> However, = it should be possible to prevent some cases of such
> problematic beh= avior, certainly so when the infloop is caused by our
> bug.=C2=A0 Bu= t for that we need to know the details of the specific case in
> orde= r to investigate.

Paul
--000000000000d613c705e8a47721-- --000000000000d613ca05e8a47723 Content-Type: text/x-emacs-lisp; charset="US-ASCII"; name="font-lock-hangs.el" Content-Disposition: attachment; filename="font-lock-hangs.el" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l81r98p00 KGRlZmluZS1kZXJpdmVkLW1vZGUgYnVnZ3ktbW9kZSBuaWwgImJ1Z2d5IgogIChzZXRmIGZvbnQt bG9jay1kZWZhdWx0cyAnKG5pbCBuaWwgdCBuaWwgKGZvbnQtbG9jay1mb250aWZ5LXJlZ2lvbi1m dW5jdGlvbiAuIGJ1Z2d5LWZvbnRpZmllcikpKQogIChmb250LWxvY2stbW9kZSAxKSkKCihkZWZ1 biBidWdneS1mb250aWZpZXIgKHN0YXJ0IGVuZCBsb3VkbHkpCiAgKGFkZC1mYWNlLXRleHQtcHJv cGVydHkgc3RhcnQgKG1pbiAoKyBzdGFydCAxNSkgZW5kKSAnYm9sZCkKICAod2hpbGUgdAogICAg Indob29wc2llIikKICBuaWwpCgooc3dpdGNoLXRvLWJ1ZmZlciAiKnNjcmF0Y2gqIikKKGRvdGlt ZXMgKGsgNTApCiAgKGluc2VydCAiTG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3Rl dHVyIGFkaXBpc2NpbmcgZWxpdCwgc2VkIGRvIGVpdXNtb2QgdGVtcG9yIGluY2lkaWR1bnQgdXQg bGFib3JlIGV0IGRvbG9yZSBtYWduYSBhbGlxdWEuIFV0IGVuaW0gYWQgbWluaW0gdmVuaWFtLCBx dWlzIG5vc3RydWQgZXhlcmNpdGF0aW9uIHVsbGFtY28gbGFib3JpcyBuaXNpIHV0IGFsaXF1aXAg ZXggZWEgY29tbW9kbyBjb25zZXF1YXQuIER1aXMgYXV0ZSBpcnVyZSBkb2xvciBpbiByZXByZWhl bmRlcml0IGluIHZvbHVwdGF0ZSB2ZWxpdCBlc3NlIGNpbGx1bSBkb2xvcmUgZXUgZnVnaWF0IG51 bGxhIHBhcmlhdHVyLiBFeGNlcHRldXIgc2ludCBvY2NhZWNhdCBjdXBpZGF0YXQgbm9uIHByb2lk ZW50LCBzdW50IGluIGN1bHBhIHF1aSBvZmZpY2lhIGRlc2VydW50IG1vbGxpdCBhbmltIGlkIGVz dCBsYWJvcnVtLlxuXG4iKSkKKGdvdG8tY2hhciAxKQooYnVnZ3ktbW9kZSkK --000000000000d613ca05e8a47723-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 12:07:09 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 16:07:09 +0000 Received: from localhost ([127.0.0.1]:55850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYUur-0004WR-2n for submit@debbugs.gnu.org; Wed, 14 Sep 2022 12:07:09 -0400 Received: from mail-ej1-f41.google.com ([209.85.218.41]:35735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYUuk-0004Vq-SB for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 12:07:07 -0400 Received: by mail-ej1-f41.google.com with SMTP id go34so35860466ejc.2 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 09:07:02 -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=SvHAU5M5ASPmBqFk+PQyGH/E57QyUEhPU0c2B4u8U6E=; b=V1haIYC+kdBn8EEG8+BDas7JrcgOkA+JqkU35/zHuQaZkaHQg45bODFAZj0n4JrzLX 9YBsiDG9kPW0iPenOuwrpE5fcZ3YghQGDglZQdSkL7K7hM9fd4wXJe1LVgTXb6depL9X qYExJHFuQe1XV+q0rhmHMFcdAwbI7TJrB9Jzs9VAKjVPXqm600TnvnwVmj5DrJNRxeDC tAWKPdN9RXYZ2O0E+rrunb7XtNED9PxIjvQoTPf+OS4TmlcnIjGivPZ01v14wVxE1rEZ 28Zec23SHo+B0g3gH1g9Ol2DUpOw3m57/awUG+PHEhdPmfYMnndkaw3pTn/rLPkDusgq f+zA== 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=SvHAU5M5ASPmBqFk+PQyGH/E57QyUEhPU0c2B4u8U6E=; b=3lt7cnurQTbH56ODA5t53WKjRhrs0seOKbX6GB9QKkuQZeJ7mjJ1Ur9BKg3raM29Cr Dma7AdVgAQrXDIlKoM+iGvviycA/grIpp5QXqrbR1yI3XRDU4gSdOpTdTp102/lUu/tL H2SUeP95COpfEiJ9S5NmU6eCFQQR48eNcS7zoeE4/2W+GQWb4DX4R32NEfgrJmnPWslq xcg8505Tlc/fBZYgQLAxv63yIDnC4ds+8Kp+erVaTueck7g8r9K9wLwc9Nd+N7OS5K0a 9wSmoXtb7KSvuPr+v5rew/JMAlCW4M2IrCSmXAA2Wu0jIPlXg1S/0SHT2Vdc45KmrBHU pMRQ== X-Gm-Message-State: ACgBeo2xAVRf6GCw3yQj1TqtmkVh+7nriRdc6MWnvXsJG2E57OMcGX/n CVkLnsY6aYRfaBhBw3CYrfeuALdCY+ISalNF8w== X-Google-Smtp-Source: AA6agR6U9IdUx+mJmNezemWXtDFdHQJonRG/MJI1b5A81efB1Hs7Qtx10VnUSITBGFF/TX3YuiWFUhVPJRuSWZPHW74= X-Received: by 2002:a17:906:6a0e:b0:77c:a049:7cfc with SMTP id qw14-20020a1709066a0e00b0077ca0497cfcmr11889989ejc.732.1663171617055; Wed, 14 Sep 2022 09:06:57 -0700 (PDT) MIME-Version: 1.0 References: <87h71aj698.fsf@dick> In-Reply-To: <87h71aj698.fsf@dick> From: Paul Pogonyshev Date: Wed, 14 Sep 2022 18:06:45 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: dick Content-Type: multipart/alternative; boundary="0000000000006f68fc05e8a5515b" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000006f68fc05e8a5515b Content-Type: text/plain; charset="UTF-8" > indicative of a young > person's rush to judgment and inclination to conflate Oh god, how much self-righteousness. Just fuck off if you don't understand anything about creating reproducers. Paul --0000000000006f68fc05e8a5515b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> indicative of a young
> person's rush to ju= dgment and inclination to conflate

Oh god, how much = self-righteousness. Just fuck off if you don't understand anything abou= t creating reproducers.

Paul
--0000000000006f68fc05e8a5515b-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 12:42:06 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 16:42:06 +0000 Received: from localhost ([127.0.0.1]:55901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVSg-0005Tv-Eo for submit@debbugs.gnu.org; Wed, 14 Sep 2022 12:42:06 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVSd-0005TM-2g for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 12:42:05 -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:Date:References: In-Reply-To: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=bTBey3Q+r14Cjdy6gi8c60skPhvcImnNTBVDb7KeEGk=; b=Yir+u2cWNJvFUlk6xXLpQyFm3N GjkTOG3IgXJ+HsNeHsKkFzlf0ch/EanqC143LHXffu1H9q2vAFCazJXi0lHm1Fo6gf/4YSKlMGdvQ vWCBfOie6fL89DAtxmimnCsJxZP+HlVy+f/SzuCg4X/W2kAdsStrvFP4pzGZu2TePtQc=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYVST-0008Qd-Nw; Wed, 14 Sep 2022 18:41:56 +0200 From: Lars Ingebrigtsen To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: (Paul Pogonyshev's message of "Wed, 14 Sep 2022 17:05:54 +0200") References: X-Now-Playing: Insides's _Soft Bonds_: "Ghost Music" Date: Wed, 14 Sep 2022 18:41:53 +0200 Message-ID: <87pmfx6h7y.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Pogonyshev writes: > C-g doesn't help anymore. The only thing you can do is to kill and start Emacs anew. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Paul Pogonyshev writes: > C-g doesn't help anymore. The only thing you can do is to kill and start Emacs anew. [...] > (define-derived-mode buggy-mode nil "buggy" > (setf font-lock-defaults '(nil nil t nil (font-lock-fontify-region-function . buggy-fontifier))) > (font-lock-mode 1)) > > (defun buggy-fontifier (start end loudly) > (add-face-text-property start (min (+ start 15) end) 'bold) > (while t > "whoopsie") > nil) Yes, it's really unfortunate that you can't get out of errors like this without killing Emacs. We've previously discussed making a certain key sequence disable font locking in a buffer -- or blacklist the particular functions that's inflooping somehow. For instance, if the user hits `C-g' three times (and Emacs doesn't idle in between), then we disable font-lock in that buffer. There's also `max-redisplay-ticks' -- but I'm not sure that would have helped here? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 12:57:43 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 16:57:43 +0000 Received: from localhost ([127.0.0.1]:55924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVhn-0005vU-1Z for submit@debbugs.gnu.org; Wed, 14 Sep 2022 12:57:43 -0400 Received: from mail-ej1-f45.google.com ([209.85.218.45]:35385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVhk-0005vG-UM for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 12:57:41 -0400 Received: by mail-ej1-f45.google.com with SMTP id go34so36193463ejc.2 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 09:57:40 -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=JuH4c7fIiOxw7wRV+uD1nilHBjXlhXYllZFNsif2i1s=; b=AB6yTBjBz8XxuXDyAnc1v0jRQ9fzHFxMwnSKM4Piuj9dhmaEZ1hEjRIKPH0R/pvtgi 5Bsq+PKQDyufg7DsyIr2V60jVEqbUGIsSLu9Wx575U7c4vtKlwY5YxXgQsema3qgAKRJ jUrp8RFnVD4sjmry7rLtncpp+mw7A61lBU4htoowM9yxb+cWey6jBv3Ynd0sxb3lNuGb E8kdhjsH4Z6KlqLmHQFLisG7z2osFOr673oSl57reqdoJis+5mR9Fa51d0yd3C1Fja3/ VEa1Q2bdseTqjebZXq+3c8TwbV8v08rNpAlUu04wh2xx0qdUiruwT1np6AMb7KtFPb8r 8vog== 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=JuH4c7fIiOxw7wRV+uD1nilHBjXlhXYllZFNsif2i1s=; b=MYPhmpepg5sysVsDpK+sWCZ1cCdAmYa3HQ+HV7MxwtlQXbEYZPCN0x7ZXB1hAIGij5 4J/+Po6KzeX7jDzhJXkFqk/khYPxSOCRhOnB9wMduUY1t+A8O2flmT2bKoiDsKY/v5lT PSpRW6a95ZD1Mrhbng6szcn/c0WHcvw/TaGLhNpb8H9QzExqxPT/nPt8H96S0vwPxGVm YC10p7iPfm/xgJHJ6Z1JYuhi7WpFxVs6tX6kKP96sF7nF1/sTxSZU2vDvGpKyUO39c+J OHnJ5NPPQLUY3Qb1fJxFxLnqHEHITbAv5VevXv3DUFKbHHEDIFKeJHYkXVkCVwJIxu+w uVNw== X-Gm-Message-State: ACgBeo134baiP6pIdn9KMGEcyz3C13u+Xf20ytULs6LY+EAmzIAaPBwT 6QO6gJzNoNdEtdcbtNC+MWJ8IUF5cqSaM259KA== X-Google-Smtp-Source: AA6agR5Y1+5Ofx6MM9Vj1JGStxKk0m9uyvGFCmGXulUXJS3nwm288mhUWqMwWQgXLSeWNj21tssUVrYKlegqFDLJbSs= X-Received: by 2002:a17:907:7b95:b0:731:113a:d7a2 with SMTP id ne21-20020a1709077b9500b00731113ad7a2mr25322640ejc.377.1663174654931; Wed, 14 Sep 2022 09:57:34 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> In-Reply-To: <87pmfx6h7y.fsf@gnus.org> From: Paul Pogonyshev Date: Wed, 14 Sep 2022 18:57:23 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Lars Ingebrigtsen Content-Type: multipart/alternative; boundary="00000000000081b7b105e8a60690" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000081b7b105e8a60690 Content-Type: text/plain; charset="UTF-8" > We've previously discussed making a certain key sequence disable font > locking in a buffer -- or blacklist the particular functions that's > inflooping somehow. I think from a user point of view a _special_ sequence is a bad idea, as most users won't know about it. Blacklisting I'd say is even worse, because that would mean a user first have to expirience a hang of Emacs, find out _which_ function caused it (remember, that Emacs is either unresponsive or is killed by now), find out that it is possible to blacklist it and do it. Way too much to expect from a user. Besides, a function may not be outright malicious, only buggy in certain corner-cases, so it would be much nicer to be able to force-abort it when that happens. E.g. in my case this happened in Logview mode, because it expected `widen' to, well, widen, but Emacs `master' introduced half-cooked narrowed locking that broke that expectation and then Logview fell into an infinite loop, because the buffer was not in the state the mode expected it to be. > For instance, if the user hits `C-g' three times (and Emacs doesn't idle > in between), then we disable font-lock in that buffer. That sounds much better. I know that `C-g' is what to press when Emacs is stuck. > There's also `max-redisplay-ticks' -- but I'm not sure that would have > helped here? If I add `(setf max-redisplay-ticks 100)' right after entering `buggy-mode', it seems to have some effect, but not exactly what I'd hope on. I suggest you try and see for yourself, hard to describe them. Paul --00000000000081b7b105e8a60690 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> We've previously discussed making a certain key s= equence disable font
> locking in a buffer -- or blacklist the partic= ular functions that's
> inflooping somehow.

I think from a= user point of view a _special_ sequence is a bad idea,
as most users wo= n't know about it.

Blacklisting I'd say is even worse, becau= se that would mean a user
first have to expirience a hang of Emacs, find= out _which_ function
caused it (remember, that Emacs is either unrespon= sive or is killed by
now), find out that it is possible to blacklist it = and do it. Way too
much to expect from a user.

Besides, a functio= n may not be outright malicious, only buggy in
certain corner-cases, so = it would be much nicer to be able to
force-abort it when that happens. E= .g. in my case this happened in
Logview mode, because it expected `widen= ' to, well, widen, but Emacs
`master' introduced half-cooked nar= rowed locking that broke that
expectation and then Logview fell into an = infinite loop, because the
buffer was not in the state the mode expected= it to be.

> For instance, if the user hits `C-g' three times= (and Emacs doesn't idle
> in between), then we disable font-lock= in that buffer.

That sounds much better. I know that `C-g' is w= hat to press when Emacs
is stuck.

> There's also `max-redi= splay-ticks' -- but I'm not sure that would have
> helped her= e?

If I add `(setf max-redisplay-ticks 100)' right after enterin= g
`buggy-mode', it seems to have some effect, but not exactly what I= 'd
hope on. I suggest you try and see for yourself, hard to describe=
them.

Paul
--00000000000081b7b105e8a60690-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 12:58:25 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 16:58:25 +0000 Received: from localhost ([127.0.0.1]:55929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYViT-0005wl-50 for submit@debbugs.gnu.org; Wed, 14 Sep 2022 12:58:25 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:34802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYUoM-0004LQ-GD for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 12:00:27 -0400 Received: by mail-qt1-f169.google.com with SMTP id g12so11122412qts.1 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 09:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date; bh=lFJ409rqM/fsD+U91nYe8RiFAqdJIc+LkG8i+/brmR0=; b=cVQv9xWlqr0XleilxX0cJgMbj+94Zu3yLNKb+pEckjJlai8Hofs5v56mk4Er8Assnu oZAJaZQACwshwq2SJW9I3v0WDc7IfDXohAuUXHvcq2a096ho5GuiOU4VoKedXDdVYWSe 8I8VEDmNoHFLWU/aC8Wc1PerpDSTl9IOA1zoAjYAOp0oycfwfzu2Nu5tUd8x/LmwJnfo OxXFBmu8Aws3JnRUWmHTMSQ5rq2Lhn5bWrpCI2V3bpDjD1OOS8TaSa2m8XyBu+iXc6Oe xW/JAv9ju5s6pPfc9mFE+GFwAnV1v1Pr5/CEIigTlPmBTFx8m48YA71lPY7f+HhvMUwI X8RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date; bh=lFJ409rqM/fsD+U91nYe8RiFAqdJIc+LkG8i+/brmR0=; b=Edoo3j/LuRR8vT0aokpOPopSmHjxRzb+GPmKbmo9gofDyrDSaWM6O/l0qPFZO8YYbb rayJAM52h/XW3nn9NhRcTUNuqxyDRuvQGTSt81ZFlJrA42ksRL7VETbLhGwiAkbYim5V e56En7ll1v0Xv/1r3VerOJz+pJA1aqfRWbwDf6SRHdy3TNjDIIl/eybbbrTHgSz0mvA9 xBAv9T0MHw4nAAuMebxRulcoxAZDdIBvuvhcNGyYtP1ypZrbQOUYIghP8ETypDG4eGhn G49Xc++ewI0OkSk1mw8IUnarmOgkIv7wtN/t/wgu14jE92AugbKrwuP6od2brT34gQSz cMjw== X-Gm-Message-State: ACgBeo1nIE37Zpb8noXGXBa4ryzmkM0ju1s+JJHCSKBbn9FGs+DLJsxc vXL7e6Y8Pfa+68yO/Wu4an8= X-Google-Smtp-Source: AA6agR4Dx/qBeF2maGAA/wRuhWzPRZMFgBryXkCCJwQoj6JNhTEqvGEne7ACaxXlbtD7pOHYLKxpLA== X-Received: by 2002:ac8:5ac3:0:b0:35b:b39a:978a with SMTP id d3-20020ac85ac3000000b0035bb39a978amr14371626qtd.497.1663171220822; Wed, 14 Sep 2022 09:00:20 -0700 (PDT) Received: from localhost (pool-173-56-234-28.nycmny.fios.verizon.net. [173.56.234.28]) by smtp.gmail.com with ESMTPSA id p8-20020a05622a00c800b0035bb8168daesm1992607qtw.57.2022.09.14.09.00.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 09:00:20 -0700 (PDT) From: dick To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: (Paul Pogonyshev's message of "Wed, 14 Sep 2022 17:05:54 +0200") References: Date: Wed, 14 Sep 2022 12:00:19 -0400 Message-ID: <87h71aj698.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14) Commercial/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 X-Mailman-Approved-At: Wed, 14 Sep 2022 12:58:21 -0400 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) That you think embedding the `(while t "whoopsie")` in a font-lock callback somehow make emacs more culpable is indicative of a young person's rush to judgment and inclination to conflate. I challenge you to find another single-threaded program in which "while (true)" doesn't require a kernel-level interrupt. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 12:58:25 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 16:58:25 +0000 Received: from localhost ([127.0.0.1]:55931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYViT-0005wt-Ej for submit@debbugs.gnu.org; Wed, 14 Sep 2022 12:58:25 -0400 Received: from mail-qt1-f181.google.com ([209.85.160.181]:41908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYV28-0004ha-4n for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 12:14:42 -0400 Received: by mail-qt1-f181.google.com with SMTP id c11so11533618qtw.8 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 09:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date; bh=mQV0gcyH/2vkIbt0VBC8ftqKc0n0gVTFJ3jxWBfTCvE=; b=oGzgLAoN10V0MR5LzvtRzC3h0MpS55bviVPA4z14JX/LDlCQMsoTvWoCfsjwYo/Zdd WEePQJzrRjZ3SzSUaMnPlvJjicHbhw49PKj9kFlhCUIBoI9/UyPtpkbG/nijxt30DKtm tm/5COthj3yHRxJTM8wTL9D5ouPWCU4IcE7gTIlKlCXFbJ5ib6i7KRbYaCqud4o5yChW tdozsWuLXNg79anUX9MHpoc2H9xHJ26EmQQZOc9BqLytiZaYKBImUuePh81wxyWobNFw fYJB7LJ+xlVXQW2Ig3CEX82gS6Tb9l6IbrRb/20sLMfnybI0jZaLZLSQn9XB9xZc3QGZ Qa/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date; bh=mQV0gcyH/2vkIbt0VBC8ftqKc0n0gVTFJ3jxWBfTCvE=; b=so/BrlJbg0jpMDIzrdXPTK+pZBjd8rjlDzUWJKmjvMDawJiysPtR1S7zNosdNY818e y6Ijur+GFYYj2aniHzjmuYwsdYsnUkuiQ6p/NF3A2rg+5BnsWq255MZIamJfNOifYMkP OF459yTo2XDsxkKtyed8mUNQ9Lel2R3Z7N08n3G9Rwo4/zqlH8XgP31vkmsVsFLylKvp U5OrL/iHeD9lK+zfJ2JS2kAW1k/ZW2LfPvA3qJgzmdFAMA4AyKtU22iB1+9p1W8oAZBJ vM+vsgV7ZXtYm2dwTuSGQPniEoIo79FF3O0go5dLZy8+DejPpFBUikCvlVwVo7o/Stck CC5A== X-Gm-Message-State: ACgBeo3yn9pKY8XfyAbth1c6yH/sPPRnx26ByBHLdY1+Na6/y/jFnV1Z mCrBP8YE3s5Px9XLW2h7itSLAdh38Pw= X-Google-Smtp-Source: AA6agR563ROxkB9NJrDU92FYICWCbtkuppS0CzyeiBkFWBTgrfM5yTdkHNJkrBHgC4PBarQME4vNcQ== X-Received: by 2002:ac8:5748:0:b0:35b:ac34:ff37 with SMTP id 8-20020ac85748000000b0035bac34ff37mr17909289qtx.630.1663172074430; Wed, 14 Sep 2022 09:14:34 -0700 (PDT) Received: from localhost (pool-173-56-234-28.nycmny.fios.verizon.net. [173.56.234.28]) by smtp.gmail.com with ESMTPSA id v15-20020a05620a0f0f00b0069fe1dfbeffsm2135110qkl.92.2022.09.14.09.14.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 09:14:33 -0700 (PDT) From: dick To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: (Paul Pogonyshev's message of "Wed, 14 Sep 2022 17:05:54 +0200") References: Date: Wed, 14 Sep 2022 12:14:33 -0400 Message-ID: <87a672j5li.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14) Commercial/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 X-Mailman-Approved-At: Wed, 14 Sep 2022 12:58:21 -0400 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Oh what a horse's ass am I. I see what you're saying. A simple evaluation of (while t) is C-g'able. jit-lock callbacks enjoy special status in that they're invoked out-of-band in redisplay C code. That's probably why they're not interruptible from the interpreter loop. But as you can tell from my earlier outburst, I'm constantly talking out of school. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:02:50 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:02:50 +0000 Received: from localhost ([127.0.0.1]:55950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVmj-00066B-SE for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:02:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVmf-00065f-FI; Wed, 14 Sep 2022 13:02:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33858) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYVma-0004cm-9e; Wed, 14 Sep 2022 13:02:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=uA1pvlMpUEAPYTfa5LsyOt25rBjbGqJJG4SDSnhHbBw=; b=VhKeFtTDkMyF Sarzrt63nu1ovKoXbXSfAOQKKIUxqzrD+ZpPEPujQVxvF28PjURViHRfd62QMuO3uAN2znXfRBM3x 9N3iKnrMXsh5rgGV3JICVSwxV/FTq3h34lOUzKzCvNvgGP2588KImJIoSTu6IDVFhTSSJNqeV918C sxK0Wd0CKvcMIgtyBiR0rBgPQqq6JFxERQraXcfI/TlXDuSuqoavYDcwdnIQl+H3S7wh5fg9W5u4u 94j80T+137dCe8J8kO7LOOGf8833xH84tdq5SwNJymuDzENfybO4tTIu+/UrAIxe9mT3hpMqArPGo jonkgd24wW+KPEHG3PrVgw==; Received: from [87.69.77.57] (port=2583 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 1oYVmZ-0003iO-MR; Wed, 14 Sep 2022 13:02:40 -0400 Date: Wed, 14 Sep 2022 20:02:30 +0300 Message-Id: <834jx93n4p.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Wed, 14 Sep 2022 17:05:54 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 57804 wontfix close 57804 thanks > From: Paul Pogonyshev > Date: Wed, 14 Sep 2022 17:05:54 +0200 > > To reproduce, save the attachment as `font-lock-hangs.el' and execute: > > $ emacs -Q -l font-lock-hangs.el > > C-g doesn't help anymore. The only thing you can do is to kill and start Emacs anew. > > Git commit fd1ee05977. > > To quote a discussion from another bug, the reply is from Eli Zaretski: > > > > By the way, it would really be nice if Emacs could do something about hangs irrespective of what > causes > > > that. Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop > > > responding to C-g, leaving full restart as the only way out. > > > > I think that's impossible in general, unless we restrict what Lisp > > programs can do. Every programming language can be used to write a > > buggy program. > > > > However, it should be possible to prevent some cases of such > > problematic behavior, certainly so when the infloop is caused by our > > bug. But for that we need to know the details of the specific case in > > order to investigate. This case is exactly one of those which I think we shouldn't try to fix, because it's the case of "buggy Lisp program", a.k.a. "don't do that". There's no reason for any useful Lisp program to have an infloop like this: > (while t > "whoopsie") So I'm closing this bug as "wontfix". From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:25:38 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:25:38 +0000 Received: from localhost ([127.0.0.1]:55977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYW8o-0000Og-5Y for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:25:38 -0400 Received: from mail-ej1-f47.google.com ([209.85.218.47]:46771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYW8d-0000OK-Br for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:25:37 -0400 Received: by mail-ej1-f47.google.com with SMTP id bj12so36305773ejb.13 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 10:25:27 -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=ugU8E7sjLj6j6Vf+waS+7P7aXwth95LY904IMw4efTg=; b=n0dNGDRg0SOLrTlUkSb0ydldN+XWb5yDrv4vhV6UpLohz6fYMU6La9B1CNrT80xIFj znJHrxi5ZRrbu2H3M94O/9D7ELTaN1YOZdFMgHk3FtU1Uzl3LoFH5ufH8Ou5XHO9GKBl MiUHNoqtjoq9Z+Yot5N0vFWonwvEU2HcNlBsvSusoTx8wvr50qUJYuPL/8x6893zhkwJ L8N+eL0D7D6NescvXg74LEtHHA6GiDcNy0nyGEnYH2yxsNrbJzeE6bFo14y6LLEHc1nB t6PXcWDpwUvKsnhLPcEMHzKU5htreJVOGB3bqm6JTo8b7P9g3yNt1PNykGYLCpbM4ZBM 0Tqw== 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=ugU8E7sjLj6j6Vf+waS+7P7aXwth95LY904IMw4efTg=; b=KoFyUl38Z0mqzbnzdFpkZMCORXe1rrAdrlctDB4y2dY//RjgQsAOes96oSW7H8TYyl Rzw3kO7oA7QkSfpjn0QxJauGRJbkTcx4FlbBOCLnqK0SJZtPhAs5UiWP3a0uHXROEYtT uIQGVMx8X2zd4sW88OGrUnSYWnCIrjFR3Trqh6hnPWAnH7LJzgGqxlPmfWbrfBTx9jcs 0bAWInmehBx8Htp8uu+HZFi1gKuCUV/6LHiApg9MC3t2kRfx4TvaOz6BLzqvKHYmVIst YUs04c699TCAiaNq06rrNquNCSbkY877frk0hoRzVcDtPP+N30wCSbqWbW+49+gf5sld SPdA== X-Gm-Message-State: ACgBeo1zBcD22IwyxLUs/speIok1olx9/9akFYVhDhaJlOICebj/58Jx p1GQh2TpZjGpQfHQe09ucj70ts4DB6BuVwtpCLybSfaclA== X-Google-Smtp-Source: AA6agR7UmilojR6LOI1vePbi9318hryLtvX70IcYqWaJLumjfc92SANizyv5N9LbI4zr5vy/A+I6NzOqZdLdSBafTjQ= X-Received: by 2002:a17:906:6a0e:b0:77c:a049:7cfc with SMTP id qw14-20020a1709066a0e00b0077ca0497cfcmr12105126ejc.732.1663176321417; Wed, 14 Sep 2022 10:25:21 -0700 (PDT) MIME-Version: 1.0 References: <834jx93n4p.fsf@gnu.org> In-Reply-To: <834jx93n4p.fsf@gnu.org> From: Paul Pogonyshev Date: Wed, 14 Sep 2022 19:25:09 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000d648a005e8a669ea" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d648a005e8a669ea Content-Type: text/plain; charset="UTF-8" > This case is exactly one of those which I think we shouldn't try to > fix, because it's the case of "buggy Lisp program", a.k.a. "don't do > that". There's no reason for any useful Lisp program to have an > infloop like this: > > > (while t > > "whoopsie") It is no wonder that Emacs is in such a poor state with 2 out 3 responding developers failing to make _one_ mental step from "while t" to "this could be a 100-line loop that accidentally falls into infinite recursion". And even because of incompatible change in Emacs itself. Just wish I didn't get accustomed to this pile of crap 20 years ago and just used a normal IDE like every smart person. Paul --000000000000d648a005e8a669ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> This case is exactly one of those which I think we sh= ouldn't try to
> fix, because it's the case of "buggy Li= sp program", a.k.a. "don't do
> that".=C2=A0 There= 's no reason for any useful Lisp program to have an
> infloop lik= e this:
>
> > =C2=A0 (while t
> > =C2=A0 =C2=A0 &q= uot;whoopsie")

It is no wonder that Emacs is in such a poor sta= te with 2 out 3
responding developers failing to make _one_ mental step = from "while t"
to "this could be a 100-line loop that acc= identally falls into
infinite recursion".=C2=A0 And even because of= incompatible change in Emacs
itself.

Just wish I didn't get = accustomed to this pile of crap 20 years ago
and just used a normal IDE = like every smart person.

Paul
--000000000000d648a005e8a669ea-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:26:03 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:26:03 +0000 Received: from localhost ([127.0.0.1]:55981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYW9D-0000Ph-GU for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:26:03 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYW98-0000P4-Q3 for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:26:02 -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:Date:References: In-Reply-To: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=b/C/2tz70sQMA7xuHWG+61HcC/tX4QOtbg7ryXHX9uI=; b=oj0Z+ms6pdM9nTSHNXH0zvINZd 1gBl7LT1SKm589B83sJgxdi7YKJlsgmuitw2NgRorh3Y1PviUttBceLVNGeymJ8iCK8MzeatF+A0H dVzqTQwZlYIGdFL3AOcbh4VirO8gkeiVy85Wg5MTdcafP76HeZh/ykHjINV8NvEuaVCA=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYW90-0000Jl-5l; Wed, 14 Sep 2022 19:25:52 +0200 From: Lars Ingebrigtsen To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: (Paul Pogonyshev's message of "Wed, 14 Sep 2022 18:57:23 +0200") References: <87pmfx6h7y.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXu7u3Y0NfGoK/P NkTdV2e3rsuZeYdLOkUTBw9kV14nEhlLJio2IiosGiP////Zf5E1AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YJDhEYCHAinlEAAAGOSURBVDjLrdK9TsJQFAfwYuJOE0kMkcHi4iq+AKUvwEA0xBV4Az4S WeV4oaNCBRcXLhe7Yk2ZhVSZ+xH6LrYF1J7WxMH/eH+959xzeznuKzz330nyPJ8Mr2Rzu5xtlxKC kD+RxKzkJ3cuSTvYE0VRkIRsTioUQju2OZB2yf/xPIlU9ZjfJAz7NbgpBSkiOJ0+xUPfaFXiIKUs G9/wY/pU8aESX6o0qsSXKtUqA9tbr96F4aLfrw5pS2nDbRjKzKR2GwAIgittDJN5DJTpmKrUA1zq EkyHAIlC2V3QWDj6WPt1SBRc1weg0R0r73tCZQwZdwlkOKXgIDhULZnN3y2QEaQpdHVdN2J6LLtz XVcdhnuoBmGMMAtDmvjDgRPZkWZTzYOXXhTWj8DgTXUjwEYe2E0jCg2v1HNzjU/F4BpkCosOBkJW /t3OiMmF3lWGBceFWdPGpZh35xQmA9wcZOIPYtcioAalVKWDwSLBr62bGOgGXhuoOQSPCmCi/ALd ezygBsw3gqGnseBhkTrHfQIpVOojvKi+iAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOS0xNFQx NzoyNDowOCswMDowMC0MBZkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDktMTRUMTc6MjQ6MDgr MDA6MDBcUb0lAAAAAElFTkSuQmCC X-Now-Playing: Anne Clark's _Hopeless Cases_: "Homecoming" Date: Wed, 14 Sep 2022 19:25:49 +0200 Message-ID: <8735ct6f6q.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Pogonyshev writes: >> For instance, if the user hits `C-g' three times (and Emacs doesn't idle >> in between), then we disable font-lock in that buffer. > > That sounds much better. I know that `C-g' is what to press wh [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Paul Pogonyshev writes: >> For instance, if the user hits `C-g' three times (and Emacs doesn't idle >> in between), then we disable font-lock in that buffer. > > That sounds much better. I know that `C-g' is what to press when Emacs > is stuck. A single `C-g' wouldn't be quite the right thing, because the user may hit `C-g' by accident while font-lock happens to run (and it's not hanging), which is why I though a special key sequence like `C-g C-g C-g' might make sense. >> There's also `max-redisplay-ticks' -- but I'm not sure that would have >> helped here? > > If I add `(setf max-redisplay-ticks 100)' right after entering > `buggy-mode', it seems to have some effect, but not exactly what I'd > hope on. I suggest you try and see for yourself, hard to describe > them. Doesn't seem to have any effect here... From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:30:54 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:30:54 +0000 Received: from localhost ([127.0.0.1]:55989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWDu-0000YV-8K for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:30:54 -0400 Received: from mail-ej1-f53.google.com ([209.85.218.53]:42879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWDs-0000YH-V5 for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:30:53 -0400 Received: by mail-ej1-f53.google.com with SMTP id sb3so6781985ejb.9 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 10:30:52 -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=xG14ceh78msz3fGc2zpAXQADLbmyXAFm9blddHXU9v0=; b=cuF3Xsg66AXzxsqDDgWuPInb9T2scbT26GTQzOUUaxqEy9owhZk+dUYUM/KFn3+DqN RBwUos5Vscg693s/oAzYK+lTOVeqR2GoN0w8SZJOOVrqti+1RFfUVRg3CAlpvgFoY6SY LAjxiKwYIHcra6ltGAFie+rPTR4iQ2zn6NXfWwnT0f/dT7pAzE/Mir1EpXlQy62aEdqO GyrE4PMM3mv17HMdSLk7klv6HE86cDxPwg0ncH/4KxmXd2W/5y69n95BIjvlNB5OKgCt BU7I8mxwBi963uMAvfH5Fbuug04Ex6LPiBKQe3PSY7ttrJwL0sZ6QnekGrPmIzXo3WOG KZ9w== 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=xG14ceh78msz3fGc2zpAXQADLbmyXAFm9blddHXU9v0=; b=h+iOVQ4zd+mZH1yPS1BcN4A/0U6221jJikuVJq1OagqTi1ZO7YqAwcm0qZlgRzTZwY VDznQQWIAueNAppfGILk1BBWwpVtfjAZ+gq8btDNWPV043Vv0Mr6kgkPfTjkDQf+TdSl /kgEQ3a+EPluR0ZlSm+7ShP+JZHJ+Zez2J1cPpO0M1pMJPOXQnVRRsO2jhEFn0ZyVuaV 2415/Sw8kObxwnzglCZGSnKu5sY/bi+lbdaGdp+YcgJK8bW9H+n91ENwwczK5dR/+2Q3 NyFfnhtzeVaSIUWAV2Y1OtVeLQmNguXFdvIvMJFd8rFxkZN+/yE4vmlY1BruR6YmfbbH aXBg== X-Gm-Message-State: ACgBeo17f+fLRbcgU7oVK+bKXA2kwXbhBSeikh3JoS20QHbjj7V6zsaw d+BMVQc1ftTRO00qkPxU9hAhYBQ5piPAHBebBA== X-Google-Smtp-Source: AA6agR57VSQcW4Lkw39gVyAXSRZmxVLHW8yt/E284gmIXZcjrRQpxVtJ4gM731LdNuM3HMtVYuWNrGAec9M6caWvHTs= X-Received: by 2002:a17:907:7b95:b0:731:113a:d7a2 with SMTP id ne21-20020a1709077b9500b00731113ad7a2mr25411404ejc.377.1663176647117; Wed, 14 Sep 2022 10:30:47 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <8735ct6f6q.fsf@gnus.org> In-Reply-To: <8735ct6f6q.fsf@gnus.org> From: Paul Pogonyshev Date: Wed, 14 Sep 2022 19:30:35 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Lars Ingebrigtsen Content-Type: multipart/alternative; boundary="00000000000040113705e8a67d0d" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000040113705e8a67d0d Content-Type: text/plain; charset="UTF-8" > > > A single `C-g' wouldn't be quite the right thing, because the user may > > hit `C-g' by accident while font-lock happens to run (and it's not > > hanging), which is why I though a special key sequence like `C-g C-g > > C-g' might make sense. > > That one is too fragile I agree. If "special" means `C-g C-g C-g' then > that is fine in my book. If something gets stuck and doesn't respond > to one "abort this" command, I usually tend to try several times > anyway, and suspect this is the same for a lot of people. > > > Doesn't seem to have any effect here... > > It seems to have some effect with `C-g' after some time. But still > doesn't abort it, only shows some warning, yet doesn't make Emacs > responsive. > > Paul > --00000000000040113705e8a67d0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> A single `C-g' wouldn't be quite the right = thing, because the user may
> hit `C-g' by accident while font-lo= ck happens to run (and it's not
> hanging), which is why I though= a special key sequence like `C-g C-g
> C-g' might make sense.
That one is too fragile I agree. If "special" means `C-g C-g= C-g' then
that is fine in my book. If something gets stuck and does= n't respond
to one "abort this" command, I usually tend to= try several times
anyway, and suspect this is the same for a lot of peo= ple.

> Doesn't seem to have any effect here...

It seem= s to have some effect with `C-g' after some time.=C2=A0 But still
do= esn't abort it, only shows some warning, yet doesn't make Emacs
= responsive.

Paul
--00000000000040113705e8a67d0d-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:32:35 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:32:36 +0000 Received: from localhost ([127.0.0.1]:55995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWFX-0000bT-MB for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:32:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWFW-0000bE-2V for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:32:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59708) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYWFQ-0001Dx-S7; Wed, 14 Sep 2022 13:32:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vLZYjUbby77WM4QAkBl4g5/c9P+Prmqa6FBAtCeM14k=; b=Pkxw0AyO3GcY i9ZUSZDNE7chrRSBZ75AAEF5dQhUCJ7jx5QBR7VVff2owedpveiTyQy7L10CkDTxRiw2Cg15Ah+vI 71DmUkVLzQZNsSHx+FvOam2I0aMqwxMmo56G8kRZ6II0EREHyijJ3ozG8NJIGp7VjRrVDJmIvIKEf nJGmRBRb96kvMUG6flvBORAkwnZzM4O7gvUafoTyTAV8LSDhs4x1DfN0ksv7MV5NtgNQwCji6m3S2 jdVKg0kWnIe0sWrjr+TLOskCMEBq6MBlZ8/F4D6nzMS/0EHDpo0wB1wQcdqT+xpzk2sMDK5hd8Fzu KRFgFf+DczPZcRddFnwaTw==; Received: from [87.69.77.57] (port=4408 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 1oYWFQ-0005ST-6E; Wed, 14 Sep 2022 13:32:28 -0400 Date: Wed, 14 Sep 2022 20:32:18 +0300 Message-Id: <83wna5276l.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Wed, 14 Sep 2022 19:25:09 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <834jx93n4p.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Pogonyshev > Date: Wed, 14 Sep 2022 19:25:09 +0200 > Cc: 57804@debbugs.gnu.org > > > > (while t > > > "whoopsie") > > It is no wonder that Emacs is in such a poor state with 2 out 3 > responding developers failing to make _one_ mental step from "while t" > to "this could be a 100-line loop that accidentally falls into > infinite recursion". And even because of incompatible change in Emacs > itself. Emacs gives Lisp programmers enough rope to hang themselves, and expects them to be wise enough not to do so. Our own sources should not use so much rope, so if there are such loops in our code, please point them out, or show a recipe that uncovers them, and we will certainly fix them. But preventing programmers from writing infinite loops for the benefit of writing infinite loops, and in font-lock functions on top of that, is not my idea of good investment of our resources. It is much easier to fix such infinite loops so they aren't there in the first place. > Just wish I didn't get accustomed to this pile of crap 20 years ago > and just used a normal IDE like every smart person. You are welcome. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:34:15 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:34:15 +0000 Received: from localhost ([127.0.0.1]:55999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWH9-0000e4-3q for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:34:15 -0400 Received: from heytings.org ([95.142.160.155]:41206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWH6-0000du-Mq for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:34:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663176851; bh=kh5Ofn81Awc+y0hpnPw7KkmFIZhVbVtPSutCVw0dkas=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=3XFboDvvPTxIV5CHrShIqquL78dbJbDBukaoMYG07O9RWOnmj4iXSl3xSZvbhSKwP y2xqctNkfiC0dXTQD4lhKI3Llskb5Ms3uZa/w91XZ8RYV/vGeqI12aW60sofjYIYb9 2foY3RGAaFh8fzRFr4E3bd/cYDmX4oZYjvrJVasZ+4B8Wwmx7FAhlURps5JCCLHt6c 6r5pLhjaZ5gFn4BnCq/0Yq6HrJFAiUv3FpAEmHY0V3Dnl7+HEouebMdFcwdeQUp8Oh oPBEF3pHgYje9lvHL20F2NP5jUzp8Iels9EQV61Ax0cxtD7O1+19yonLjk4HXwMzDT AMuTNWWCCDgfg== Date: Wed, 14 Sep 2022 17:34:10 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: <2b58b8f5429a6e3aecda@heytings.org> References: <87pmfx6h7y.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > E.g. in my case this happened in Logview mode, because it expected > `widen' to, well, widen, but Emacs `master' introduced half-cooked > narrowed locking that broke that expectation > Yes, master contains work in progress. If you want stable code, you should use the release branch. Note that 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. What you should most probably do in your case is to increase the value of long-line-threshold (or disable whatever causes Logview to infloop when locked narrowing is in effect, if that's feasible). From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:38:22 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:38:23 +0000 Received: from localhost ([127.0.0.1]:56004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWL8-0000k9-M4 for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:38:22 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWL7-0000jv-O1 for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:38:22 -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:Date:References: In-Reply-To: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=lkwDqG0Zy7kd+sXquqaeclPaoOkWisLuzv3g6wcKCao=; b=Z8+hCcjCmwfqTeR5okNOd4sOI7 KtjuBs7tKe3llBDxjvA81rdM4t+/OePgEG9+Fp+IUDUxFpXriNN7bDD2YW0fO39sUZ968QkierasL DW27QIFBzyvUvsPsu44+0wu2BRGu+B5j1ahGLR8tct3YYXYj7iJozYoB7gBaxu9Yh9Ms=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYWKy-0000RH-RI; Wed, 14 Sep 2022 19:38:14 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: <834jx93n4p.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 14 Sep 2022 20:02:30 +0300") References: <834jx93n4p.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXu7u3Y0NfGoK/P NkTdV2e3rsuZeYdLOkUTBw9kV14nEhlLJio2IiosGiP////Zf5E1AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YJDhEYCHAinlEAAAGOSURBVDjLrdK9TsJQFAfwYuJOE0kMkcHi4iq+AKUvwEA0xBV4Az4S WeV4oaNCBRcXLhe7Yk2ZhVSZ+xH6LrYF1J7WxMH/eH+959xzeznuKzz330nyPJ8Mr2Rzu5xtlxKC kD+RxKzkJ3cuSTvYE0VRkIRsTioUQju2OZB2yf/xPIlU9ZjfJAz7NbgpBSkiOJ0+xUPfaFXiIKUs G9/wY/pU8aESX6o0qsSXKtUqA9tbr96F4aLfrw5pS2nDbRjKzKR2GwAIgittDJN5DJTpmKrUA1zq EkyHAIlC2V3QWDj6WPt1SBRc1weg0R0r73tCZQwZdwlkOKXgIDhULZnN3y2QEaQpdHVdN2J6LLtz XVcdhnuoBmGMMAtDmvjDgRPZkWZTzYOXXhTWj8DgTXUjwEYe2E0jCg2v1HNzjU/F4BpkCosOBkJW /t3OiMmF3lWGBceFWdPGpZh35xQmA9wcZOIPYtcioAalVKWDwSLBr62bGOgGXhuoOQSPCmCi/ALd ezygBsw3gqGnseBhkTrHfQIpVOojvKi+iAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOS0xNFQx NzoyNDowOCswMDowMC0MBZkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDktMTRUMTc6MjQ6MDgr MDA6MDBcUb0lAAAAAElFTkSuQmCC X-Now-Playing: Anne Clark's _Hopeless Cases_: "Now" Date: Wed, 14 Sep 2022 19:38:12 +0200 Message-ID: <87y1ul501n.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > This case is exactly one of those which I think we shouldn't try to > fix, because it's the case of "buggy Lisp program", a.k.a. "don't do > that". There's no reason for any useful Lisp program to h [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > This case is exactly one of those which I think we shouldn't try to > fix, because it's the case of "buggy Lisp program", a.k.a. "don't do > that". There's no reason for any useful Lisp program to have an > infloop like this: > >> (while t >> "whoopsie") You've never accidentally put an infloop into a font locking function? Then you've been very lucky. We should definitely fix this is we can. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:43:37 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:43:37 +0000 Received: from localhost ([127.0.0.1]:56015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWQD-0000sC-7U for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:43:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWQB-0000rz-4N for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:43:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53172) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYWQ5-0003Lf-Tb; Wed, 14 Sep 2022 13:43:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jgRdU9lJ1nCxF3U+nS9LzzrAAvUsVs1R1xpsXx9xU+4=; b=XlsLvAY23tIc OAPM77WjwGIt2xPDO3BSHnNnmLtdGTT/En2XaZ2g23ddyKaZMMBsN39JImocu/9Y0srS89y3jYc6s klBHw2QB7jnODi7wxfzu7x0+85Dixx+ZSbrbs+19jC8PN/RKlZTbmLhEHsfUIoLCTzWev0rJUv1ei cuXgZQIVM4S+crJ8ofcXQl2RVgx/+JVXmf9/a8ZgbCAC+dse1Jf7Uv+hfLAabZXIBMxqdPZNGBFv9 eT21ciyAFjW9SMA7cyCPPyA98PkZddLdVvg7F8+m5J8KQCY3YTeIJsTr2+wbQjvkyu3huEuaqbxaq N/sn0RT4Th8A5wY3BnIUMg==; Received: from [87.69.77.57] (port=1110 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 1oYWQ4-0007Jv-Sp; Wed, 14 Sep 2022 13:43:29 -0400 Date: Wed, 14 Sep 2022 20:43:19 +0300 Message-Id: <83r10d26o8.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <8735ct6f6q.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 14 Sep 2022 19:25:49 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <8735ct6f6q.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 57804@debbugs.gnu.org > From: Lars Ingebrigtsen > Date: Wed, 14 Sep 2022 19:25:49 +0200 > > Paul Pogonyshev writes: > > >> For instance, if the user hits `C-g' three times (and Emacs doesn't idle > >> in between), then we disable font-lock in that buffer. > > > > That sounds much better. I know that `C-g' is what to press when Emacs > > is stuck. > > A single `C-g' wouldn't be quite the right thing, because the user may > hit `C-g' by accident while font-lock happens to run (and it's not > hanging), which is why I though a special key sequence like `C-g C-g > C-g' might make sense. I frequently find myself hitting C-g several times for reasons unrelated to any infloop. > > If I add `(setf max-redisplay-ticks 100)' right after entering > > `buggy-mode', it seems to have some effect, but not exactly what I'd > > hope on. I suggest you try and see for yourself, hard to describe > > them. > > Doesn't seem to have any effect here... It shouldn't, because an infloop doesn't consume any "redisplay ticks". From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:44:40 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:44:40 +0000 Received: from localhost ([127.0.0.1]:56026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWRE-0000uD-2A for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:44:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWRD-0000u1-4L for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:44:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37714) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYWR7-0003Ut-Ro; Wed, 14 Sep 2022 13:44:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=W2/Cz2rEKXq1DXWu7j1ttMf1KVlqOl3U4QlE88PoTOo=; b=lLOFc4BQlMmm BW6YR1fNenY+gTO0A5hHuQEmofQPWOt/nxWSzL0ePUH/cVmGegAkb8WDJ8kzcOM12cWFLVi3SXddA GCQrThsLpCZrR4vLzoFRBaDvmVp19R4aqkF1TAwBVqa0zjeSTeqdv/8dZkWLRY+KKSsI4yMGzAzvU 1nMmXQSXaM+MAWv705aJmNQc0oaAkTdCSvFbRNo5xvQCbcjogcvo0L2R/9bPhcV03VXRcbn3gbHQ/ QvTRh1h0cACGOfkgPb17WHb8eVZQqt+Z5TJa7MMjMk29ClnJ8h/cycoGEhVPXvTCNaZfxVqNfEZj5 fZqLLyT21hUX+fiQH62/HA==; Received: from [87.69.77.57] (port=1175 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 1oYWR6-0007Rh-Qk; Wed, 14 Sep 2022 13:44:33 -0400 Date: Wed, 14 Sep 2022 20:44:24 +0300 Message-Id: <83pmfx26mf.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87y1ul501n.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 14 Sep 2022 19:38:12 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <834jx93n4p.fsf@gnu.org> <87y1ul501n.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Paul Pogonyshev , 57804@debbugs.gnu.org > Date: Wed, 14 Sep 2022 19:38:12 +0200 > > Eli Zaretskii writes: > > > This case is exactly one of those which I think we shouldn't try to > > fix, because it's the case of "buggy Lisp program", a.k.a. "don't do > > that". There's no reason for any useful Lisp program to have an > > infloop like this: > > > >> (while t > >> "whoopsie") > > You've never accidentally put an infloop into a font locking function? While testing my code? sure. But after testing, no, the loops are generally gone. > We should definitely fix this is we can. I disagree. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:45:31 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:45:31 +0000 Received: from localhost ([127.0.0.1]:56030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWS3-0000w7-EX for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:45:31 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWS1-0000vs-Q6 for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:45:30 -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:Date:References: In-Reply-To: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=R78dOr2RheZUSYYzZrRw+B8kTaTV/YNwcEyOxbGN6No=; b=cPruDGdpGxGx+0Jyd5mfuBcz5g aHDobDutw5XdsD9kkyZInZUVn6QtnGrPHsJV/b4ekxlC1R5syQL2urBmyZvUkhLkoElVS1/8XnRrC esDqFDk/+EgXTwstOQroHcLHXcZgayhAsGYnoiQImmDOG3LhHJWRYR2ZY2YbFlBrQ1cM=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYWRs-0000Ty-Mj; Wed, 14 Sep 2022 19:45:22 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: <83r10d26o8.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 14 Sep 2022 20:43:19 +0300") References: <87pmfx6h7y.fsf@gnus.org> <8735ct6f6q.fsf@gnus.org> <83r10d26o8.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXu7u3Y0NfGoK/P NkTdV2e3rsuZeYdLOkUTBw9kV14nEhlLJio2IiosGiP////Zf5E1AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YJDhEYCHAinlEAAAGOSURBVDjLrdK9TsJQFAfwYuJOE0kMkcHi4iq+AKUvwEA0xBV4Az4S WeV4oaNCBRcXLhe7Yk2ZhVSZ+xH6LrYF1J7WxMH/eH+959xzeznuKzz330nyPJ8Mr2Rzu5xtlxKC kD+RxKzkJ3cuSTvYE0VRkIRsTioUQju2OZB2yf/xPIlU9ZjfJAz7NbgpBSkiOJ0+xUPfaFXiIKUs G9/wY/pU8aESX6o0qsSXKtUqA9tbr96F4aLfrw5pS2nDbRjKzKR2GwAIgittDJN5DJTpmKrUA1zq EkyHAIlC2V3QWDj6WPt1SBRc1weg0R0r73tCZQwZdwlkOKXgIDhULZnN3y2QEaQpdHVdN2J6LLtz XVcdhnuoBmGMMAtDmvjDgRPZkWZTzYOXXhTWj8DgTXUjwEYe2E0jCg2v1HNzjU/F4BpkCosOBkJW /t3OiMmF3lWGBceFWdPGpZh35xQmA9wcZOIPYtcioAalVKWDwSLBr62bGOgGXhuoOQSPCmCi/ALd ezygBsw3gqGnseBhkTrHfQIpVOojvKi+iAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOS0xNFQx NzoyNDowOCswMDowMC0MBZkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDktMTRUMTc6MjQ6MDgr MDA6MDBcUb0lAAAAAElFTkSuQmCC X-Now-Playing: Anne Clark's _Hopeless Cases_: "Armchair Theatre" Date: Wed, 14 Sep 2022 19:45:18 +0200 Message-ID: <87tu594zpt.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> A single `C-g' wouldn't be quite the right thing, because the user may >> hit `C-g' by accident while font-lock happens to run (and it's not >> hanging), which is why I though a special key sequenc [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> A single `C-g' wouldn't be quite the right thing, because the user may >> hit `C-g' by accident while font-lock happens to run (and it's not >> hanging), which is why I though a special key sequence like `C-g C-g >> C-g' might make sense. > > I frequently find myself hitting C-g several times for reasons > unrelated to any infloop. But like I said, three `C-g's without any idle time in between would be the magical command to switch off font locking. I think that's hard to do accidentally in normal circumstances. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:46:26 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:46:26 +0000 Received: from localhost ([127.0.0.1]:56034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWSv-0000xv-QE for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:46:25 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWSt-0000xi-UZ for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:46:24 -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:Date:References: In-Reply-To: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=EScRFq0a7X8Uv8j7PpylYzDsyfZZq0LBMXXFA3c7G0E=; b=Kz/N934YGWzYJgdL/AEEppFMMW K6jBigLZSHh5dl1jv+GAX/g+/HNKaE3REZkAu//c6apib4mLT6lmTzUddb0KuT2lwfnQhMIh90bAN mGrE0G3kMZWdXxE8bKK7SkzN/PyQdExA71/6MTkf7VKnusqpCUlfwZbwqZHq5FhWttlA=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYWSl-0000UR-K1; Wed, 14 Sep 2022 19:46:17 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: <83pmfx26mf.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 14 Sep 2022 20:44:24 +0300") References: <834jx93n4p.fsf@gnu.org> <87y1ul501n.fsf@gnus.org> <83pmfx26mf.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXu7u3Y0NfGoK/P NkTdV2e3rsuZeYdLOkUTBw9kV14nEhlLJio2IiosGiP////Zf5E1AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YJDhEYCHAinlEAAAGOSURBVDjLrdK9TsJQFAfwYuJOE0kMkcHi4iq+AKUvwEA0xBV4Az4S WeV4oaNCBRcXLhe7Yk2ZhVSZ+xH6LrYF1J7WxMH/eH+959xzeznuKzz330nyPJ8Mr2Rzu5xtlxKC kD+RxKzkJ3cuSTvYE0VRkIRsTioUQju2OZB2yf/xPIlU9ZjfJAz7NbgpBSkiOJ0+xUPfaFXiIKUs G9/wY/pU8aESX6o0qsSXKtUqA9tbr96F4aLfrw5pS2nDbRjKzKR2GwAIgittDJN5DJTpmKrUA1zq EkyHAIlC2V3QWDj6WPt1SBRc1weg0R0r73tCZQwZdwlkOKXgIDhULZnN3y2QEaQpdHVdN2J6LLtz XVcdhnuoBmGMMAtDmvjDgRPZkWZTzYOXXhTWj8DgTXUjwEYe2E0jCg2v1HNzjU/F4BpkCosOBkJW /t3OiMmF3lWGBceFWdPGpZh35xQmA9wcZOIPYtcioAalVKWDwSLBr62bGOgGXhuoOQSPCmCi/ALd ezygBsw3gqGnseBhkTrHfQIpVOojvKi+iAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOS0xNFQx NzoyNDowOCswMDowMC0MBZkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDktMTRUMTc6MjQ6MDgr MDA6MDBcUb0lAAAAAElFTkSuQmCC X-Now-Playing: Anne Clark's _Hopeless Cases_: "Leaving" Date: Wed, 14 Sep 2022 19:46:15 +0200 Message-ID: <87pmfx4zo8.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > While testing my code? sure. But after testing, no, the loops are > generally gone. Of course. This is a real problem while developing font locking methods (and usually not afterwards). Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > While testing my code? sure. But after testing, no, the loops are > generally gone. Of course. This is a real problem while developing font locking methods (and usually not afterwards). From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:49:41 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:49:41 +0000 Received: from localhost ([127.0.0.1]:56041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWW5-00014P-9M for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:49:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWW2-00014B-Nt for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:49:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYWVx-0004Ns-E0; Wed, 14 Sep 2022 13:49:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KETEDO87lAxgxALah80gLomeMEtRqUK9VqE3BpjkQws=; b=ayi6tgFGRMxC THjxVY1i4/gZqXjO6P5602Hnww+OsIMtRZ1WJVBqRo8CsjS5E1htIwmni+xQAQyNCexHeGaYQWvOE UHXK73nyXZknRxBlkevUPXMCY5RkqMavL8cEOsZMs2y422G44h/HGy3tAa/jN2C9cgE3FV2w7o9gE RFgs+N3sGPyPeyfuYCmICDRisIxx1KNPb0+ToDXUIaPt3tRzctFDhDe9sRFDu5yBSxP2dl+Hj+fnb OI0rpvSRsgU8Ob6tz199n0BE+ywBkWqmbOoYJoZxEDHGNYD/OSo/SVL51IHlAb5XEXUvHr9l7/krw IOpnhp9sM2VefqHQZyJZkA==; Received: from [87.69.77.57] (port=1481 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 1oYWVw-00085R-SJ; Wed, 14 Sep 2022 13:49:33 -0400 Date: Wed, 14 Sep 2022 20:49:22 +0300 Message-Id: <83o7vh26e5.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87tu594zpt.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 14 Sep 2022 19:45:18 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <8735ct6f6q.fsf@gnus.org> <83r10d26o8.fsf@gnu.org> <87tu594zpt.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: pogonyshev@gmail.com, 57804@debbugs.gnu.org > Date: Wed, 14 Sep 2022 19:45:18 +0200 > > Eli Zaretskii writes: > > >> A single `C-g' wouldn't be quite the right thing, because the user may > >> hit `C-g' by accident while font-lock happens to run (and it's not > >> hanging), which is why I though a special key sequence like `C-g C-g > >> C-g' might make sense. > > > > I frequently find myself hitting C-g several times for reasons > > unrelated to any infloop. > > But like I said, three `C-g's without any idle time in between would be > the magical command to switch off font locking. I think that's hard to > do accidentally in normal circumstances. There's nothing accidental about my typing several C-g in a row. It just isn't related to any font-lock. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:52:10 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:52:10 +0000 Received: from localhost ([127.0.0.1]:56046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWYT-00018W-Of for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:52:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWYR-00018H-7q for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:52:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58804) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYWYM-0004xc-0P; Wed, 14 Sep 2022 13:52:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=C9fNR1YRMl1uZlNo6TqAXY6ao0hhqmzHeoPd7zh3KtM=; b=PHWUhrIVzMLx mbKGNMsizSDnQUXTDfspyFZTUyCgfy9CEEiD3TJoFKSysgTUXU0vr15X/Y7UqAJzNnDG/iX3oSI94 rjsxT0IH4fxQMzNyiDeYXSi7KbQfPXtEvVUPNTnt+96ASBt3uz+KIVA0cwMQSIYR7wO3eCEZECn9Q 4OatpHraRZZDHAv+SvUECuSXxWYhJKmoX6ehgSnEopKCixjlXKiSJo/ZD2+khT1KtKO2mjdXFBX/q FwILM9AQeWg0mwsBp4VA5Pilk/tS3nZbgvKuMp5mp2MIP2kj9uU1rKRNGw88l9gVFZww+EDNB+RIA sgjXh/eDu7ZDMkEeDTBI4Q==; Received: from [87.69.77.57] (port=1628 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 1oYWYE-0008TG-CI; Wed, 14 Sep 2022 13:52:01 -0400 Date: Wed, 14 Sep 2022 20:51:43 +0300 Message-Id: <83mtb126a8.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87pmfx4zo8.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 14 Sep 2022 19:46:15 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <834jx93n4p.fsf@gnu.org> <87y1ul501n.fsf@gnus.org> <83pmfx26mf.fsf@gnu.org> <87pmfx4zo8.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: pogonyshev@gmail.com, 57804@debbugs.gnu.org > Date: Wed, 14 Sep 2022 19:46:15 +0200 > > Eli Zaretskii writes: > > > While testing my code? sure. But after testing, no, the loops are > > generally gone. > > Of course. This is a real problem while developing font locking methods > (and usually not afterwards). While testing, I usually run Emacs under a debugger, where I always can interrupt any loop, including in font-lock. I think it is also possible without a debugger -- if you bind 'sigusr2' to some useful function. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 13:52:56 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 17:52:56 +0000 Received: from localhost ([127.0.0.1]:56049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWZE-00019c-5F for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:52:56 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWZC-00019N-MD for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 13:52:55 -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:Date:References: In-Reply-To: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=CLvot890fhcIn92aUhRCMQpra3D7wcWuloEYyl9zxTQ=; b=sfKzg9uwu/HwynTSPDRX0HbqtL ZIMw5BNyYDiZjzs4IWNQjmrKBK23fx6RMoB1Z0Ial8mN0OkYnt56JMeCIIC+awgv9LR+cVTVcAgQ2 CrJfSa+FNyC3uQYBirddermnc0ERMLlmxfi9oQWSwL4ozr2Iu573Ou2rM/+kdgijfUG8=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYWZ3-0000YD-V2; Wed, 14 Sep 2022 19:52:48 +0200 From: Lars Ingebrigtsen To: dick Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: <87a672j5li.fsf@dick> (dick's message of "Wed, 14 Sep 2022 12:14:33 -0400") References: <87a672j5li.fsf@dick> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXu7u3Y0NfGoK/P NkTdV2e3rsuZeYdLOkUTBw9kV14nEhlLJio2IiosGiP////Zf5E1AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YJDhEYCHAinlEAAAGOSURBVDjLrdK9TsJQFAfwYuJOE0kMkcHi4iq+AKUvwEA0xBV4Az4S WeV4oaNCBRcXLhe7Yk2ZhVSZ+xH6LrYF1J7WxMH/eH+959xzeznuKzz330nyPJ8Mr2Rzu5xtlxKC kD+RxKzkJ3cuSTvYE0VRkIRsTioUQju2OZB2yf/xPIlU9ZjfJAz7NbgpBSkiOJ0+xUPfaFXiIKUs G9/wY/pU8aESX6o0qsSXKtUqA9tbr96F4aLfrw5pS2nDbRjKzKR2GwAIgittDJN5DJTpmKrUA1zq EkyHAIlC2V3QWDj6WPt1SBRc1weg0R0r73tCZQwZdwlkOKXgIDhULZnN3y2QEaQpdHVdN2J6LLtz XVcdhnuoBmGMMAtDmvjDgRPZkWZTzYOXXhTWj8DgTXUjwEYe2E0jCg2v1HNzjU/F4BpkCosOBkJW /t3OiMmF3lWGBceFWdPGpZh35xQmA9wcZOIPYtcioAalVKWDwSLBr62bGOgGXhuoOQSPCmCi/ALd ezygBsw3gqGnseBhkTrHfQIpVOojvKi+iAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOS0xNFQx NzoyNDowOCswMDowMC0MBZkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDktMTRUMTc6MjQ6MDgr MDA6MDBcUb0lAAAAAElFTkSuQmCC X-Now-Playing: Anne Clark's _Hopeless Cases_: "Leaving" Date: Wed, 14 Sep 2022 19:52:45 +0200 Message-ID: <87k0654zde.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: dick writes: > jit-lock callbacks enjoy special status in that they're invoked > out-of-band in redisplay C code. That's probably why they're not > interruptible from the interpreter loop. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain dick writes: > jit-lock callbacks enjoy special status in that they're invoked > out-of-band in redisplay C code. That's probably why they're not > interruptible from the interpreter loop. If I remember correctly, the problem isn't really that `C-g' isn't able to break, but that we then call the redisplay immediately again, which then calls the font-locking code. Let's see... yes, with this slightly modified version of Paul's code, after hitting `C-g' eight times, I get a redisplay finally and it says "Called 8 times". So I think there's scope for us to do something practical here with this annoying problem. It's hard enough to develop font locking code without Emacs suddenly (and unbreakably) hanging on you when you've typed in some buggy code. --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=font-lock-hangs.el Content-Transfer-Encoding: quoted-printable (define-derived-mode buggy-mode nil "buggy" (setf max-redisplay-ticks 100) (setf font-lock-defaults '(nil nil t nil (font-lock-fontify-region-functi= on . buggy-fontifier))) (font-lock-mode 1)) (defvar times 0) (defun buggy-fontifier (start end loudly) (message "Called %d times" (setq times (1+ times))) (add-face-text-property start (min (+ start 15) end) 'bold) (while t "whoopsie" (redisplay t)) nil) (switch-to-buffer "*scratch*") (dotimes (k 50) (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do = eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad mini= m veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea c= ommodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit= esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupid= atat non proident, sunt in culpa qui officia deserunt mollit anim id est la= borum.\n\n")) (goto-char 1) (buggy-mode) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 14:18:53 2022 Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 18:18:53 +0000 Received: from localhost ([127.0.0.1]:56163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWyL-0006Di-3a for submit@debbugs.gnu.org; Wed, 14 Sep 2022 14:18:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYWyG-0006DF-MJ for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 14:18:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39794) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYWyB-0002MV-Dm; Wed, 14 Sep 2022 14:18:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nHLVxUKQgq3TnEHl8c+QvHghs/16K6yx5lB2JsywJuo=; b=f1NpqclGd7b1 swRj6hmTVCzvzRaYP2rau8WqFpEz+02DzfS3geuB4SnyJgY3veoxlFMwkdNs5EA3Eoj5ll6cnvaTM r0ULpUoKxpatigzfJWMVXpf85DWRPFB4AipNA5u+zw1rpvDOig2+miy4ysFlog3zBDEKORZi0u2Zh 7f6w8IM3hnrmYRTUV7d1kfqm8rEpNeYxJUoPmlrrz2FG965nZxL0/vSSfG5aAH9dHdUT57dDX8C85 g4vd6XWFPOOOEeHCnZgaq4M7g+rMTHQqz980vi7pjN1dtx8ZItYdoqwbP0XJIqTc5v/lzwcDTW4NP j4RQFzPJARnvf79Ky35Jiw==; Received: from [87.69.77.57] (port=3258 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 1oYWyA-00015Y-Qh; Wed, 14 Sep 2022 14:18:43 -0400 Date: Wed, 14 Sep 2022 21:18:33 +0300 Message-Id: <83leql251i.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87k0654zde.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 14 Sep 2022 19:52:45 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87a672j5li.fsf@dick> <87k0654zde.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, dick.r.chiang@gmail.com, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 57804@debbugs.gnu.org, Paul Pogonyshev > From: Lars Ingebrigtsen > Date: Wed, 14 Sep 2022 19:52:45 +0200 > > So I think there's scope for us to do something practical here with this > annoying problem. It's hard enough to develop font locking code without > Emacs suddenly (and unbreakably) hanging on you when you've typed in > some buggy code. Just run your development version under a debugger, and you will always be able to interrupt any loop, anywhere. And I think you greatly underestimate the conceptual difficulty here. Your conclusions are specific to this toy program. But in real-life use cases, it is entirely unclear how to handle this: . the fact that redisplay is called several times in a row doesn't necessarily mean we have a bug, there are packages out there which cause that due to stuff they do in various hooks (like linum.el, which moves overlays etc.) . the buggy code could be in some function registered with jit-lock or run from some hook invoked by redisplay that have nothing to do with font-lock, in which case turning off font-lock will not solve anything IOW, the general solution to this is not apparent, and I'm not sure it exists, the only solution I'm aware of is to run unstable code under a debugger. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 22:16:37 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 02:16:37 +0000 Received: from localhost ([127.0.0.1]:56639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYeQf-0001yJ-2C for submit@debbugs.gnu.org; Wed, 14 Sep 2022 22:16:37 -0400 Received: from mail-pl1-f177.google.com ([209.85.214.177]:36641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYeQc-0001y1-1E for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 22:16:35 -0400 Received: by mail-pl1-f177.google.com with SMTP id c2so16948592plo.3 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 19:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date; bh=GFy6VuimYkee9VVrMmY11jo8OWKkMXL6K5xMQqubXcg=; b=UHbaf5ojAtjl7wyw7b2jkqxJ39Y8bCeE/bQgEI71Nwye97JceTKfMwyftpfkBW6JCj MRabJzL5GuqGHX7IKbxsJMB3fk26iHYglMolg8lWjmmH8o24/H9UtKqz7waHxDlUuGIZ AU+Y6nQTvUfQhUu78qOF+JSgcGWh/ae9O63eqp8F+RwysPnH6M41wI9nvuCmI0BchNOf 6GbhmIDm3FWPMYDJc3wMZYF5z7KBXhEeUjWvo+o+zJK0aP09M+AgPM7xJp+vrkD6SNHF bl+u7Rfu7ddDfoyIe1tmEHUGdpqcQIdpcJpi7URk6dmypg0lApsaqE/FWjoGcWh1q/pB xG5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=GFy6VuimYkee9VVrMmY11jo8OWKkMXL6K5xMQqubXcg=; b=GWQORAjMdBU3MzNsc3a7s5H6tk+SNp2FmRyKxWu65hPjw6khyLtwOV/lb9/B0DhQXW AB8VxzbqknleiBfensVzBfe9mRdrHv07vlTCEkxkwdCZIy+IS4sameUFGZawBibXtiu1 NYpwTdTe5EwQpcbtoSyKr6/xkgDSF4UXKGG8sK+Le4sBvWDmkzCB/0OZghUCekhJ64g+ SfXzjpvyaK6RVtGK4zYTCry522+uZbhgMprTBL8lJXYP5RQ+Ky5BAxllyrfvqHQZpeIK nLC9PEMlJ+B4OetIhSPo+lAHpsg1HavMoKD2snIl1KWzh2+SnfyVWPfgBWak9f7JEKzK ud4Q== X-Gm-Message-State: ACrzQf05BZt6DAw5z9rSgHCBiSVWNAoA9Xd22PJWOhWorly6a1hrE5RR /2sHIYFtQGWyLRCBWB+ViEc= X-Google-Smtp-Source: AMsMyM7w+qsypf+cD4n+8TcO3Hwqq5kCbyClGiBU7NQOoxth4TVopDOhbIB7Qh1fNlrjOlaQYiV+qw== X-Received: by 2002:a17:90b:3847:b0:203:1ef6:ce1 with SMTP id nl7-20020a17090b384700b002031ef60ce1mr5486977pjb.113.1663208188099; Wed, 14 Sep 2022 19:16:28 -0700 (PDT) Received: from localhost ([2409:8970:a81:48f7:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id gv6-20020a17090b11c600b002002f9eb8c4sm387706pjb.12.2022.09.14.19.16.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 19:16:27 -0700 (PDT) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: <83o7vh26e5.fsf@gnu.org> References: <87pmfx6h7y.fsf@gnus.org> <8735ct6f6q.fsf@gnus.org> <83r10d26o8.fsf@gnu.org> <87tu594zpt.fsf@gnus.org> <83o7vh26e5.fsf@gnu.org> Date: Thu, 15 Sep 2022 10:17:21 +0800 Message-ID: <87edwdwfda.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Eli Zaretskii writes: >> But like I said, three `C-g's without any idle time in between would be >> the magical command to switch off font locking. I think that's hard to >> do accidentally in normal circumstances. > > There's nothing accidental about my typing several C-g in a row. It > just isn't related to any font-lock. Org mode uses a similar method to catch rare edge cases and make users report them. We make the user aware about possible reaction to multiple C-g's using the following message: `org-element--parse-buffer': Suppressed `\\[keyboard-quit]'. Press `\\[keyboard-quit]' %d more times to force interruption. The code goes like (when (and inhibit-quit org-element--cache-interrupt-C-g quit-flag) (when quit-flag (cl-incf org-element--cache-interrupt-C-g-count) (setq quit-flag nil)) (when (>= org-element--cache-interrupt-C-g-count org-element--cache-interrupt-C-g-max-count) (setq quit-flag t) (setq org-element--cache-interrupt-C-g-count 0) (org-element-cache-reset) (error "org-element: Parsing aborted by user. Cache has been cleared. If you observe Emacs hangs frequently, please report this to Org mode mailing list (M-x org-submit-bug-report).")) (message (substitute-command-keys "`org-element--parse-buffer': Suppressed `\\[keyboard-quit]'. Press `\\[keyboard-quit]' %d more times to force interruption.") (- org-element--cache-interrupt-C-g-max-count org-element--cache-interrupt-C-g-count))) -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92 From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 01:21:12 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 05:21:12 +0000 Received: from localhost ([127.0.0.1]:56727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYhJI-0006un-52 for submit@debbugs.gnu.org; Thu, 15 Sep 2022 01:21:12 -0400 Received: from sonic302-20.consmr.mail.ne1.yahoo.com ([66.163.186.146]:43532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYhJG-0006ua-Bc for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 01:21:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663219263; bh=O03otGHQbCef33Nrk/dzQ7bcxDILDR710jIebn+kIOQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=WhEhoxiAlV8p9RrhxLpV8eYxFV0n+l49M+YxT0qjQIQ/0YnIhSOfCnOLipnv5DyfHf3ggTX3N7M5XX//oRSYah3QN2lsOY9MQ5A+c1R7gpOcyw6LrF0/8uDX+v93E+DT/xaUr+4ocskHi1g5Eutdxd7s+a8oAPnZNWwkjOTlVNxRtUTO3TH5RVL40gsj1lxJex/2a9EuE9tSQNLjgGyoqCmKXddcSuIRIVy2+kDxIxa8CCsRRxB90CyS+AK/HUoiHoPiBMdTyP4jc9wju8cNdDTwVnML1jZAeTakp+gUedgxG5OeHE2G56YIp39PSiTMGUe3aYU30d9U5yK+38LudA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663219263; bh=AH7UP5AN1yc0SvgcyFWn3HR3tDKRruPpbMQDI5qxRKD=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=C+gM6W8ptO6LZU5HsYOHfcNTkj/i/oHkACHG6WxrateSqHAPHU/94Nqr+FXUL1jesmcm2Ug29KCwbGZHw7Df3jW6FK52wR/yoh5K+dBs5TjRQZCq74XDaOE2BWz+xuyRaxlceP4iKnPZbazrvNqaZvfmSd07QS14x/ptgzETsOGfmsWsMZYGpsPHyFJe7Z8fZMcqyKOIJkLJfpTJCwb3MBuSCILAt//FDYHz+Wh48PxzwgyL/Nk2fWX6Yv/e2YG0eq+vvHdPV4K17DajgoG+UMQiXiFWZmDo14Pl2ya/acn9Xvi0L4+fB7Clw2qo/zKt33XU+mhtyEaOHnksBbRi/Q== X-YMail-OSG: k3TF4EwVM1keWhMdV1DBhdlBE9jM3sN.OPBEH1clrrrGEFGgCqby3GifqrESQ5l uMdZ2iOqQUSjKbE28AEt1sWtIoCYHIlA.ue7QoxyfOjMtcr_Zhy7W.FURhcG9fk3_i1mix24mnrt CVIDIbfWfvlRhKDquNDPipg4Gd0L1BSdq4olnnSWHPQgZTSD1_yYsUbMIUNmB.BU3rm.0R_OFwTD 6DorWGbhAWI3h998j8QZNdkJdMwgUxKCul_tzRwqEh.lwifkimQGU1aM_wvVlSV4CsHYx_vIKzUK 7xUNo3zmaOQLhkwf6nekjQ2w9h51GfAkNceHZb8SXTdZtrxnobPExRHuOeHOCJ6BMIPlpyfKgq1A WXknjdKikgbwrxYeHUQoFE_i2qNaXTxpSCxQq1K3ZKRpk9Xj0394XpJjKff4S0AzIOXp.a1qf9qP mEtaZ17JfqfN0j7Teop73FvEapMcYh2ZpgnHLxOvXfgCtS2blcJlHEEDWFu59D5JfAOUkBTkHLsa bJzfp5D0V.4Kr4hdqufmZyW_WF41_fQTQDy0q28tOUnbw79x4AGXdM306vm84B0dU1BFVwOorsMp Hku0SOmCOR9jU3mvhA4KVgkUs_nido4wnnjnN6CTs7Km7vDETLTpIhpaGiJMh_I9McRsDJJj.TSt UGD925n_zgoMI4ZUSoRYgyN464Zcf5rsllZ8zi1nZu1hAnLIE1kuy2850ArwAOp1u7TwFqItf4Lg bmiJ7iI7NRGUBoQoNGsQAfTkmLJyQYVD_xCwzcVZ2eDjbbJnk923JKlS9CFdlSAMu.uVq.l6OTpL PAPQyVISh2qEKkWjT3ZlG0LXCE0HHMJvte5eTnPdftDpdoCqj4Td6xQMgNPXE2hKOTCalZiwtPvn 3_fECs7eIC10NhcTMxQ1rbKJRWViukqFuli7.bFCJZKc7znqT90fszhfkp6dXDFQD2D4L4ou1._t P_oZVIIkRIFychaP8apUqiIp3xGYfvb.tns8uDm3nTd25Wi1FVN2HtIoVMZE3iiYF_qcYri6AHh_ bQ_5eQd.j_ahunNwLFbi4kYmym9I9N9Dn6aOYs6SbH8TtIuGYGaPHsh3IErrljYDk8gtXfSrwAEp O8JJcosrcgBuTdKTAhaZugekbIleW.NOp09S5YoJbyqDHYodTR90xeqGxGFPen8v1cqe.vORzN_7 .w5WTmVSfJ_ETv4ZSlPckQ7Q6KPGP8EQesnpzavz6VfRjDMdjIH6eB7UhCM0kqNMr9NFyVWNq1rP ciSB8g9239d5iSjB2b2CMD6W2AkDi_fuv0Cfuqju1pFIbDQ1VbkyOPSg9vgMOVFGPXruTZyKUdr8 lnTRXP0cOMzSlNo6vmDK0YNuDzCTj.41gGyNUGt.nnYEgPXjwdWBQEv86mfroXlV_QI6Rfr6qAen uxQKljZarTPwhFGqrozRWeR57a.RjieLWizT4FmSpqjPGmJdTMSO.T64QFvvCHl9gaO77K12.J.7 IhAg2AuXvgRWk2zf2P4.A_dKxj9ocNIprGMiiPb0_SvkdJ9oKWYKV24g4csPqQuJFVpRegixk3KT vvzLzh3hTxc7Ymqcs9nFWhyrV_oon6HJuLAa3IOwQCLwlbJWJIFRD_SGhXRU_TtTclNK7zb0SBuf QYll6DIFIzdqOOQbZCO.lT9OBC7SptQ.QNVpNGShAvaq6H7yfQGLToqKrWy7IogkvZCQZJesIJ0_ l5VZePviydL8_JXMgWnfvYI9HPUTJA9jRQQyyz_aT7.iECOOYSoFC544wy8JmZz1gDZuvd3m_IpD q2yQC5wZhNd4.ITxKVrI0ml8.RfuQ3yOYWlNvn1ZC.iy7HObEni7gcNWaZKsC2EHGx2jn28ngQF8 V0f.tPej37B1VdjY4FiAfud9adOZ3JSfFHsrsYWMh2lxFR_S3e8aUsZhLeh3fHeBY7b7ZpUSHNKj nskfDHUkYdCpkJx4ZpYflaqkQ9nXN24Iy0BgRXrxDjQChNAOakF67AVVWnHuX1Ca_5xkGR4kmawv HBkwGlj4iOkbQV_iaEUy9eA_1h0u4aW4ygQ.i2bmmOKcpIgAjF0wxnw2F3cHcI0dQFhgs9Bsm_AG mmVq97KxekYmAbtlgQ1KgnKpKkxpHb0kEaeF8IgFTtHzq.owpULNOFTIR87sWIY_Tqx_ioeXa6xw eP5ELJOVBPO0Dm2VrwbhGWcJPY0x.HqiqCio2BglFl4QV1ZQyJgsoDcoLaAb4TlUWzRWf8X1hg7H mT6vJmzoXgtmngm9ikgL5tNQtN47Z7KZND3F_P0arnvhyDrvPFfYQ68uIGKbjeUWLKbiEtljEJin 5hyg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Thu, 15 Sep 2022 05:21:03 +0000 Received: by hermes--canary-production-sg3-6bb8946c47-ts4tq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 74fdf9aefe6f0f28a4f64124202edc8f; Thu, 15 Sep 2022 05:20:57 +0000 (UTC) From: Po Lu To: Lars Ingebrigtsen Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <834jx93n4p.fsf@gnu.org> <87y1ul501n.fsf@gnus.org> Date: Thu, 15 Sep 2022 13:20:51 +0800 In-Reply-To: <87y1ul501n.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 14 Sep 2022 19:38:12 +0200") Message-ID: <87wna5xlfw.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 549 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > Eli Zaretskii writes: > >> This case is exactly one of those which I think we shouldn't try to >> fix, because it's the case of "buggy Lisp program", a.k.a. "don't do >> that". There's no reason for any useful Lisp program to have an >> infloop like this: >> >>> (while t >>> "whoopsie") > > You've never accidentally put an infloop into a font locking function? > Then you've been very lucky. > > We should definitely fix this is we can. Why isn't jit-lock-debug-mode an option? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 02:27:38 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 06:27:38 +0000 Received: from localhost ([127.0.0.1]:56783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYiLa-0000G5-0v for submit@debbugs.gnu.org; Thu, 15 Sep 2022 02:27:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYiLY-0000Fr-SI for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 02:27:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47954) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYiLS-00027m-ES; Thu, 15 Sep 2022 02:27:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZUzZYkqUgZbImsfVeTKE3O3HRR9P+ioyu/52L0maymc=; b=UieGRYHKv9PW 64NQvuaVxUKHDDHzXnaUipIWaysy4sk5eWCLzaLkuwveyuDJ31iJBfJu7SPAVOcXa7B0PTvzRPfnx BdejcsvswgI9AU85MqffI4ThT7S3B5KAgd+bpxWtQWhREjTnLV6VafI24QAXNPADsGNEMt1Wurhg6 KV8dmb+KVDWpa8ErCtD0eDJKk+4OGnKJTuR2QSSWGG33dM95/lExjlBLkb8ZJDGt0tcqEtdaoc9bF /+kqphEsZMo7Dv/IWaytKqSd2qdczjR4ZNfO7E77oye7DtlfC2MLz78A3+Dz0IRqvCICN99NeIeLA p0tDGZ8gysBcKCihEAS/WA==; Received: from [87.69.77.57] (port=3993 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 1oYiLM-0002qC-Th; Thu, 15 Sep 2022 02:27:30 -0400 Date: Thu, 15 Sep 2022 09:27:14 +0300 Message-Id: <831qsd17b1.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87wna5xlfw.fsf@yahoo.com> (message from Po Lu on Thu, 15 Sep 2022 13:20:51 +0800) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <834jx93n4p.fsf@gnu.org> <87y1ul501n.fsf@gnus.org> <87wna5xlfw.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: larsi@gnus.org, 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Paul Pogonyshev > > Date: Thu, 15 Sep 2022 13:20:51 +0800 > > Lars Ingebrigtsen writes: > > > Eli Zaretskii writes: > > > >> This case is exactly one of those which I think we shouldn't try to > >> fix, because it's the case of "buggy Lisp program", a.k.a. "don't do > >> that". There's no reason for any useful Lisp program to have an > >> infloop like this: > >> > >>> (while t > >>> "whoopsie") > > > > You've never accidentally put an infloop into a font locking function? > > Then you've been very lucky. > > > > We should definitely fix this is we can. > > Why isn't jit-lock-debug-mode an option? It definitely is, for the particular use case of debugging font-lock. So is running font-lock-fontify-buffer by hand. So is attaching a debugger when such an infloop is bumped into accidentally without expecting it. There's also the recently-added backtrace-on-redisplay-error feature, which could help with diagnosing such problems, perhaps combined with debug-on-entry or somesuch. IOW, I think we have already several useful tools available for the particular problem of debugging loops in font-lock, if we want to interpret this bug report in that narrow interpretation. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 10:47:52 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 14:47:52 +0000 Received: from localhost ([127.0.0.1]:58857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYq9f-0003oH-HF for submit@debbugs.gnu.org; Thu, 15 Sep 2022 10:47:52 -0400 Received: from mail-ej1-f52.google.com ([209.85.218.52]:39708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYq9c-0003me-6T for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 10:47:50 -0400 Received: by mail-ej1-f52.google.com with SMTP id y17so37669502ejo.6 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 07:47:48 -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=Q1k5U7DqID+LEOJxlZ0+s/0AIIo82DgdYhs8gER2XRk=; b=Z5EShc2d1TDvuu90YoMvYo8fno7fPQBXSmccJeuEfnz+9e49/hntwZnPAsqttyEK7y WKenLTZpPrcOLlZPkzZoqf/Uw3cqlhAMA7ZxWotg8jKeLi/H9VirouFzJLMpsYXG+EpB 4Q8agMZZuuiJcbp7kinP0bzDhWoQrTwRu6JF7yWOO4kbb4R7SOSdoKPb5cJYZ+ZlJyFD pOkopYo0yOn2WYGRTvcco/udQoXZJWEjGOuLixqoHJEd0WGWtR3YGB8fsXRFce8cL7Be W1UQc/CDptu4HvNH/SIa+AKneULS6n+ln4dKc5j9HNh8kcINY0UdTr9aGW2FXQXZY2GA 4Ilw== 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=Q1k5U7DqID+LEOJxlZ0+s/0AIIo82DgdYhs8gER2XRk=; b=dfk2rq9i04Y1R5ZJW9bfN0skhWUg3KiwxoCzzOVlW4956q5NQ+Gde4mxuMS0lk5GZ0 Lna5xmptj9Ec/6MhFt9tko1kukBZJQYkz1Ie9V5LtvHJ/6IcbpMW3+D1UE39VERaHKc2 MOAk69nsj4qFugUbPdfQk3r3/TpYiHy0mOoXYvytRz40znUrXWhbN8XEDA48FOA4YM8E K2sW5u/QYe4EVx1elLW23maYnLFeOWr7fg+pNaG+QlkoNCu+haxw8XxJ0XyLdG7Lrpt+ VD5SpJ09WKfSLfN3dphZQTHskzFTHecynQNq2BxJ7FK54r9UVCfbZlLZ1f0BlflQic66 fXPQ== X-Gm-Message-State: ACrzQf0V10NV7vTNi4TFosu192bNyBkXpiCZyIlT85dEnVPwj6mXgYug kI7rtMHQq/sIH592o0m/pJlF2TzhbaYsOB3U/g== X-Google-Smtp-Source: AMsMyM7NCUTW87P7/evNx4FjTviMn7dUjdKirY8DT9QA+R+bVF0+MzvVEfUPrpEDbnfJRdETs9yCab1TBwGCaWVimH0= X-Received: by 2002:a17:907:b09:b0:76f:99cc:81cd with SMTP id h9-20020a1709070b0900b0076f99cc81cdmr235647ejl.530.1663253261258; Thu, 15 Sep 2022 07:47:41 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> In-Reply-To: <2b58b8f5429a6e3aecda@heytings.org> From: Paul Pogonyshev Date: Thu, 15 Sep 2022 16:47:29 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="000000000000cf133705e8b853ea" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000cf133705e8b853ea Content-Type: text/plain; charset="UTF-8" > Logview will have to be adapted to deal with the > possibility of a locked narrowing. Is it technically impossible to lift narrowing restrictions in Emacs 29 (as in, something would break), or is it "you have to rewrite, because we have decided so"? Paul On Wed, 14 Sept 2022 at 19:34, Gregory Heytings wrote: > > > > > E.g. in my case this happened in Logview mode, because it expected > > `widen' to, well, widen, but Emacs `master' introduced half-cooked > > narrowed locking that broke that expectation > > > > Yes, master contains work in progress. If you want stable code, you > should use the release branch. > > Note that 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. What you should most probably do in > your case is to increase the value of long-line-threshold (or disable > whatever causes Logview to infloop when locked narrowing is in effect, if > that's feasible). > --000000000000cf133705e8b853ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Logview will have to be adapted to deal with the
&= gt; possibility of a locked narrowing.

Is it technic= ally impossible to lift narrowing restrictions
in Emacs 29 (as in= , something would break), or is it "you
have to rewrite, bec= ause we have decided so"?

Paul
On Wed, 1= 4 Sept 2022 at 19:34, Gregory Heytings <gregory@heytings.org> wrote:

>
> E.g. in my case this happened in Logview mode, because it expected > `widen' to, well, widen, but Emacs `master' introduced half-co= oked
> narrowed locking that broke that expectation
>

Yes, master contains work in progress.=C2=A0 If you want stable code, you <= br> should use the release branch.

Note that the "fully cooked" narrowing will not magically solve t= hat
problem, though.=C2=A0 Logview will have to be adapted to deal with the possibility of a locked narrowing.=C2=A0 What you should most probably do i= n
your case is to increase the value of long-line-threshold (or disable
whatever causes Logview to infloop when locked narrowing is in effect, if <= br> that's feasible).
--000000000000cf133705e8b853ea-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 11:10:10 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 15:10:10 +0000 Received: from localhost ([127.0.0.1]:58875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYqVG-0004me-56 for submit@debbugs.gnu.org; Thu, 15 Sep 2022 11:10:10 -0400 Received: from heytings.org ([95.142.160.155]:42640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYqVA-0004mR-7Y for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 11:10:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663254602; bh=sUwiofaCTOCLTvgNlhoOTQH6N2MDpJJv4ZU2kO9PA6s=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=xpsXG8D0u0Sz5LhoBxNacJZKWm85aFXl1BqnIg3ztCeQGV3rkLupxpMLiuR7zmc6W chXhefOlA3Im8SeTxN4flXqK+XerdKKfbM9LJBDK3ql397iLB0ZAtcOhbve1HAbhMw EIPtv/o7Na5bUvIncj6kD0YGwg+FUI9exCGBO3riGN0ZIVvqWXgstLXFmRMdiVTVLH TunhvdNUAik7Pf//xCD2HeJ6t0xKhc5Oh6DyOSIeS29xjEdcxXWyF3q1+hwQodHy+m RNPlv3ZXsZjQafopMSnzE2IZ6qjOlgnZ6qOz1qyrEtovYHoOmc+XjU4cLGvDO9p8eP zb1FoGTGw3pPA== Date: Thu, 15 Sep 2022 15:10:02 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > Is it technically impossible to lift narrowing restrictions in Emacs 29 > It is not, you can choose a radical approach and long-line-threshold to nil. Or you can choose a less radical approach and set long-line-threshold to a larger value (as I already told you twice IIRC). > > (as in, something would break), > Locked narrowing is one part of the solution to the long lines bug in Emacs, so something could indeed break if you turn that solution off. > > or is it "you have to rewrite, because we have decided so"? > That's not how I would present things, no. Why does Logview infloop when locked narrowing is in effect? This might be a bug in Logview: fontification-functions / jit-lock-function is not supposed to access and modify a large portion of the buffer. I don't use Logview, and you did not give a detailed recipe to reproduce the issue, so it's difficult to give more precise advice. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 11:38:20 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 15:38:20 +0000 Received: from localhost ([127.0.0.1]:58962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYqwV-0005Xa-Ve for submit@debbugs.gnu.org; Thu, 15 Sep 2022 11:38:20 -0400 Received: from mail-ed1-f48.google.com ([209.85.208.48]:46766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYqwS-0005XL-Tn for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 11:38:19 -0400 Received: by mail-ed1-f48.google.com with SMTP id z13so13548129edb.13 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 08:38:16 -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=v3H4w5/vU2Yf1viCim1zGTJ7CWUN/8g0c33mB6OBkdo=; b=hjwG+gXk/rm4sVuf/a2pfK6f7dnFSFP68cLHsaWJl1A9jI6uN8kl8UAe0/2fOwfudX NOdxa8jEuPihM7BwhPTrSG5NYcrVTHZINYuCTbigmsa0ODA2kS5W47HeObt1vBbQKa2B PANCiTc6kCVlMMQ4FwCvmzGM4fSoLiP6hjThh0U91C2xpnoaFDo0ymHuy9+YE95rXNX6 x0nGCV0UNJPQL3ZduwhIrnFBVEWV/4lNoAWuD9ZTcvbaQXtD2utPaAfb5yT80BN2zDhG v3/3J2SwMbaIbpbZ64B0xaSvOeIUbc+r8EGgONMaeH/zbmcOr7MUu0AKXkYQef3I6Jm1 f9Ig== 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=v3H4w5/vU2Yf1viCim1zGTJ7CWUN/8g0c33mB6OBkdo=; b=P3CZyOv7AKuUeNHuX5YLQscLnu60uXYZZv5yfZ7GGMxbFQNjnj23pOFifbU9EEo64I eSKkFMt+fxm7USh7cSNBzX9YQ3sOlmlcKYAry9c1qip2ZoypyxBc/0Drx3roUgxKDTrC a7H0tQtHRKgMRBVRWss66OMrcuDE/04Gpg6R1yepfQ5bmgQ7KZaDK1LUQfnIWhwvN9IU s9cfbX06prZmty+EIoIsZsARODy8IoggCM68RHW61M5U7mUm0G83AM3Tee1ylBLrOs6r Pwe65nQb79+pG6JGuUKfpG6ix8Rn0qW4pLLVO+PBSuoQtSKrJj0HdZLbmLAJ9sTVFCrD BaEw== X-Gm-Message-State: ACrzQf1cmXHuCtziO/WpAM3SSezmU/b6wJrJis4Wjvg80aF3MBjjVXxq u74JI90qFfkbV6ar0bk/mgVmuVOWAUpK3wN17g== X-Google-Smtp-Source: AMsMyM4hAHC67V2Z8VfD0Z3nUWUgRiYnjTx1mBVMQWaH1ohpifxBQ/OcvHqYYOj0WOCl3XtlBAxvNQh6yj/K9SPfnJo= X-Received: by 2002:a05:6402:43cf:b0:450:eae1:c9d3 with SMTP id p15-20020a05640243cf00b00450eae1c9d3mr365750edc.231.1663256291089; Thu, 15 Sep 2022 08:38:11 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> In-Reply-To: From: Paul Pogonyshev Date: Thu, 15 Sep 2022 17:37:59 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="00000000000066a22105e8b90837" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000066a22105e8b90837 Content-Type: text/plain; charset="UTF-8" > > or is it "you have to rewrite, because we have decided so"? > > That's not how I would present things, no. It doesn't matter how you would present it, it's the result that matters. > Why does Logview infloop when > locked narrowing is in effect? This might be a bug in Logview Because it assumes that after `widen' all restrictions are gone. If I do x = 10 + 20 if (x == 25) throw new Error (); and this results in an error, then the bug is not _in my code_. If I need to treat every function as "pretty please, do this, but if you don't, it's fine, I'll do something else", my code will inflate tenfolds and will still not achieve its goals. > fontification-functions / jit-lock-function is not supposed to access and > modify a large portion of the buffer. "Is not supposed" is not the same as "must not do, else everything crashes". > I don't use Logview, and you did > not give a detailed recipe to reproduce the issue Recipe is obvious: (widen) (if (/= (point-min) 1) (error "WTF is going on?")) Why Logview needs to access the full buffer at any time? Because it operates lazily. It expects that log files are several megabytes and therefore doesn't parse them fully. There are at least two passes: first splits the file into entries, second fontifies. The first can be used for other reasons too. In other words, when fontification comes around, the relevant buffer part may not be even split into entries yet, so fontification code calls the splitting code first. Logview also almost never moves the point internally (because that might be slow in huge buffers), instead it needs to be able to query text properties anywhere. And with narrowing this is impossible. Frankly, I don't see why I need to tell you _why_ I need this. Even if I write five pages explaining every single detail, all things I have considered in the years this mode had been written (with one major refactoring for performance reason), I know the answer: "Yeah, but you could do X or Y instead". Of course, I have never thought about that, yeah. Of course I have just chosen this approach randomly. You either accept that there _might_ be something you haven't thought about, you have never discovered or simply never needed. Or you don't. Then you just say: "Do it this way! For me it's enough, therefore it _must_ be enough for everyone. Or if it's not it's their problem and I don't care.". Paul On Thu, 15 Sept 2022 at 17:10, Gregory Heytings wrote: > > > > > Is it technically impossible to lift narrowing restrictions in Emacs 29 > > > > It is not, you can choose a radical approach and long-line-threshold to > nil. Or you can choose a less radical approach and set > long-line-threshold to a larger value (as I already told you twice IIRC). > > > > > (as in, something would break), > > > > Locked narrowing is one part of the solution to the long lines bug in > Emacs, so something could indeed break if you turn that solution off. > > > > > or is it "you have to rewrite, because we have decided so"? > > > > That's not how I would present things, no. Why does Logview infloop when > locked narrowing is in effect? This might be a bug in Logview: > fontification-functions / jit-lock-function is not supposed to access and > modify a large portion of the buffer. I don't use Logview, and you did > not give a detailed recipe to reproduce the issue, so it's difficult to > give more precise advice. > --00000000000066a22105e8b90837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > or is it "you have to rewrite, because we h= ave decided so"?
>
> That's not how I would present t= hings, no.

It doesn't matter how you would present it, it's = the result that
matters.

> Why does Logview infloop when
&g= t; locked narrowing is in effect?=C2=A0 This might be a bug in Logview
<= br>Because it assumes that after `widen' all restrictions are gone.=C2= =A0 If I
do

=C2=A0 =C2=A0 x =3D 10 + 20
=C2=A0 =C2=A0 if (x = =3D=3D 25)
=C2=A0 =C2=A0 =C2=A0 throw new Error ();

and this resu= lts in an error, then the bug is not _in my code_.

If I need to trea= t every function as "pretty please, do this, but if
you don't, = it's fine, I'll do something else", my code will inflate
te= nfolds and will still not achieve its goals.

> fontification-func= tions / jit-lock-function is not supposed to access and
> modify a la= rge portion of the buffer.

"Is not supposed" is not the sa= me as "must not do, else everything
crashes".

> I do= n't use Logview, and you did
> not give a detailed recipe to repr= oduce the issue

Recipe is obvious:

=C2=A0 =C2=A0 (widen)
= =C2=A0 =C2=A0 (if (/=3D (point-min) 1) (error "WTF is going on?")= )

Why Logview needs to access the full buffer at any time? Because i= t
operates lazily. It expects that log files are several megabytes andtherefore doesn't parse them fully. There are at least two passes:first splits the file into entries, second fontifies. The first can be
= used for other reasons too. In other words, when fontification comes
aro= und, the relevant buffer part may not be even split into entries
yet, so= fontification code calls the splitting code first. Logview
also almost = never moves the point internally (because that might be
slow in huge buf= fers), instead it needs to be able to query text
properties anywhere. An= d with narrowing this is impossible.

Frankly, I don't see why I = need to tell you _why_ I need this. Even if
I write five pages explainin= g every single detail, all things I have
considered in the years this mo= de had been written (with one major
refactoring for performance reason),= I know the answer: "Yeah, but you
could do X or Y instead". O= f course, I have never thought about that,
yeah. Of course I have just c= hosen this approach randomly.

You either accept that there _might_ b= e something you haven't thought
about, you have never discovered or = simply never needed. Or you
don't. Then you just say: "Do it th= is way! For me it's enough,
therefore it _must_ be enough for everyo= ne. Or if it's not it's their
problem and I don't care."= ;.

Paul

On Thu, 15 Sept 2022 at 17:10, Gregory Heytings <gregory@heytings.org> wrote:
<= /div>

>
> Is it technically impossible to lift narrowing restrictions in Emacs 2= 9
>

It is not, you can choose a radical approach and long-line-threshold to nil.=C2=A0 Or you can choose a less radical approach and set
long-line-threshold to a larger value (as I already told you twice IIRC).
>
> (as in, something would break),
>

Locked narrowing is one part of the solution to the long lines bug in
Emacs, so something could indeed break if you turn that solution off.

>
> or is it "you have to rewrite, because we have decided so"?<= br> >

That's not how I would present things, no.=C2=A0 Why does Logview inflo= op when
locked narrowing is in effect?=C2=A0 This might be a bug in Logview:
fontification-functions / jit-lock-function is not supposed to access and <= br> modify a large portion of the buffer.=C2=A0 I don't use Logview, and yo= u did
not give a detailed recipe to reproduce the issue, so it's difficult to=
give more precise advice.
--00000000000066a22105e8b90837-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 12:08:30 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 16:08:30 +0000 Received: from localhost ([127.0.0.1]:58981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYrPh-0006MF-Ab for submit@debbugs.gnu.org; Thu, 15 Sep 2022 12:08:30 -0400 Received: from heytings.org ([95.142.160.155]:42722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYrPY-0006Ly-V1 for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 12:08:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663258099; bh=cPbQFF7KTZSl97qSg+mM7zCODlVBI8mkMj1yZZ4qoMI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=r2DhtVRC8tfDgE+435mEhKG1ncMW0EnzD6/Gd1E0Zlh+H+PimqCezwUMYWwn51ZpD 9GEjEsfZiFrrO7fU2l7DWnKYi42vi3nGrGDNxn81gTZmSpr0LdtsuY5ZaFRm6tLRQT JgbnY5M6/4Fa7SDlL4Shd6mbfAyt+7/MgSCoZflQfNS+22qOxnUJGl2EYbTOCMF9oZ uWb47CS6IhM8Wq+xeN7E1R+iTxlI6zbIysKkD1TOUdVxL3ZOiFcV6Ofr5Y78yOooWc 913PlIaIn3EUM1zHbmVd+5EgoozCrzV4fx0mBClB+fccnRbm3DVyFewHBV8dgn39MF vOlqjarv7n0YA== Date: Thu, 15 Sep 2022 16:08:19 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-ID: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > You either accept that there _might_ be something you haven't thought > about, you have never discovered or simply never needed. Or you don't. > Then you just say: "Do it this way! For me it's enough, therefore it > _must_ be enough for everyone. Or if it's not it's their problem and I > don't care.". > May I perhaps tell you that your attitude isn't exactly encouraging anyone to help you? I tried to give you some advice in reply to your previous paragraphs, and deleted everything after reading that one. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 12:19:41 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 16:19:41 +0000 Received: from localhost ([127.0.0.1]:59002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYraW-0006db-H4 for submit@debbugs.gnu.org; Thu, 15 Sep 2022 12:19:40 -0400 Received: from mail-oo1-f46.google.com ([209.85.161.46]:41850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYraT-0006dO-Oc for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 12:19:40 -0400 Received: by mail-oo1-f46.google.com with SMTP id t15-20020a4a96cf000000b0044e0142ec24so3065485ooi.8 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 09:19:37 -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=IKdwsj8Jc8uSjePawcjuvjZt0/zlJyFk6VfHhWRdC7w=; b=MiM845K8G+/Wtay3DU/hCJfG3wMfHY3Jv09MbOn22lr84MF6hqoUGU0WfYF7CarGuk 0YiWUg/S7N0eXiHRcEg6nhALDfcXHLNBW7aoFSrzeyjng/frpEYi48LFCj4JK8No6y2O 2QUMth8nd010aQKB2PHHmjiPDe9XNF7UZvixsOXl/cL99GHO2ozyqFkr9VUtA8IjcvlE H2hp8l2B+UnEd9tevz9mbQ4jcUDWW68cmg2+sWtCih5HoNFJY0+XnaVC3Fj9kds17Pby eAfvedkYdsSni9InGajRm4bpmGlLn9JhYWJLj4IRFD6QvgITnmzOvtn3oVU1vdN+G1uX Up5w== 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=IKdwsj8Jc8uSjePawcjuvjZt0/zlJyFk6VfHhWRdC7w=; b=YFgLCmZPwF5UVCTC3zWQtMiMwwooZseZ9kacMNenYiBgu6+UXOk7WYF1Y5SG39KUGt cwabwNDi/r9RAK3KDvz69Sb/JmcFL7aUQoKC2ny9YM73JYoXmD9vqq0JUlPcP6J/Ot2l rCKRob70mXDcg07JCiw4qkjSospLuZ+6eCPv7rS1uZaANMIlqat5LakCd0H2/QexMMTR 4nEC7LwKq8ViF/hKExAwKHtstGExofLzm28t5z0Fkti9IWTwV7ahMDnSPvIPZenIcKGW frl7pD1/atVJycgrnsF9YgbhbcauGxQ6+BPs6cDBKH3mETvzKKSybzlWyZCC8xMg8HI2 qbZQ== X-Gm-Message-State: ACrzQf0bETYzyARLy0fxlgbVauwu+Y89xmjaFk0fUhsPsdU4kQQX5OQP PRGJOFgxufl0Y5P/Ew+fCh82NTN8NjDr49AUPQ== X-Google-Smtp-Source: AMsMyM4lDJiFr8l31NSTPkMmBt4tKCbGPlRJ0s0woFlzHm60AR+viDg4C/waJebcet07mW6VDX+OYuslYNGTMC4hdhM= X-Received: by 2002:a05:6820:306:b0:475:8fcc:35d0 with SMTP id l6-20020a056820030600b004758fcc35d0mr351342ooe.46.1663258771908; Thu, 15 Sep 2022 09:19:31 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> In-Reply-To: From: Paul Pogonyshev Date: Thu, 15 Sep 2022 18:19:18 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="00000000000044f2d105e8b99c2b" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000044f2d105e8b99c2b Content-Type: text/plain; charset="UTF-8" My attitude is explained by my general experience with Emacs itself and reporting any problems I have had with it. Sometimes everything went out fine, but far less often than I would have hoped. You may see me as a jerk, I see most Emacs developers as unhelpful and not willing to take into account real problems when those don't affect them personally. Doesn't matter "who started first", that's just how it is. I suspect your "help" was to the tune of "instead, you should just...". That I won't miss, I have had a lot of "help" of this kind on StackOverflow. So there. Paul On Thu, 15 Sept 2022 at 18:08, Gregory Heytings wrote: > > > > > You either accept that there _might_ be something you haven't thought > > about, you have never discovered or simply never needed. Or you don't. > > Then you just say: "Do it this way! For me it's enough, therefore it > > _must_ be enough for everyone. Or if it's not it's their problem and I > > don't care.". > > > > May I perhaps tell you that your attitude isn't exactly encouraging anyone > to help you? I tried to give you some advice in reply to your previous > paragraphs, and deleted everything after reading that one. > --00000000000044f2d105e8b99c2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My attitude is explained by my general experience with Ema= cs itself and reporting any problems I have had with it. Sometimes everythi= ng went out fine, but far less often than I would have hoped. You may see m= e as a jerk, I see most Emacs developers as unhelpful and not willing to ta= ke into account real problems when those don't affect them personally. = Doesn't matter "who started first", that's just how it is= .

I suspect your "help" was to the tune of &qu= ot;instead, you should just...". That I won't miss, I have had a l= ot of "help" of this kind on StackOverflow.

<= div>So there.

Paul

On Thu, 15 Sept 2022 at 18= :08, Gregory Heytings <gregory@h= eytings.org> wrote:

>
> You either accept that there _might_ be something you haven't thou= ght
> about, you have never discovered or simply never needed. Or you don= 9;t.
> Then you just say: "Do it this way! For me it's enough, there= fore it
> _must_ be enough for everyone. Or if it's not it's their probl= em and I
> don't care.".
>

May I perhaps tell you that your attitude isn't exactly encouraging any= one
to help you?=C2=A0 I tried to give you some advice in reply to your previou= s
paragraphs, and deleted everything after reading that one.
--00000000000044f2d105e8b99c2b-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 12:44:41 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 16:44:41 +0000 Received: from localhost ([127.0.0.1]:59051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYryj-0007ID-Hj for submit@debbugs.gnu.org; Thu, 15 Sep 2022 12:44:41 -0400 Received: from heytings.org ([95.142.160.155]:42800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYryg-0007I2-N9 for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 12:44:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663260277; bh=629t19GFR04+as+AtH3BziyU+2lqrjNRjxpDkX2Bzb4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=FkGHkON1juV/0PujEF9i8faJ3qeNI/KlO8m+zdG/fE7jGv/l7Ga/vyIR6SBRmBhVV Fz6eegiLf9kKoblNRJjBuilza9oaoKr8YyMEHq3ug/OftJ+79XWn6iBrtU0iWK5rFk 3ZkiH5qpV9FHh2cJuyk3Jggg0BiJC1jDj7S1VlAmKbZ3G/xBYL3aHaW7Y8VzcqzjuN mC8GmlSQs7C+S+PI2g1u5POUgYC9T1dzE5FHdJKASrtKispgTTABoy+iG5AneJ6N6U zsgrGI6P5BQjNK/JhcyOn4Xj9l5m0KbPpATxt0cPf2xnGhHb5CTm4UGTzJG+cJ1hZM /PEkFTQAZR26g== Date: Thu, 15 Sep 2022 16:44:36 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > My attitude is explained by my general experience with Emacs itself and > reporting any problems I have had with it. Sometimes everything went out > fine, but far less often than I would have hoped. > We're all doing our best to improve Emacs in our free time. It is unreasonable to expect that everything would go fine (with your own definition of "fine") in all cases. It would not be reasonable to expect that from a private company, either. > > You may see me as a jerk, > I do not. > > I suspect your "help" was to the tune of "instead, you should just...". > That's a rather strange conclusion. I 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). From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 14:49:43 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 18:49:43 +0000 Received: from localhost ([127.0.0.1]:59165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYtvj-00025s-Bh for submit@debbugs.gnu.org; Thu, 15 Sep 2022 14:49:43 -0400 Received: from mail-ej1-f47.google.com ([209.85.218.47]:33359) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYtvd-00025V-2U for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 14:49:41 -0400 Received: by mail-ej1-f47.google.com with SMTP id lc7so44255270ejb.0 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 11:49:37 -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=sxh3etBmieR8zQf/Ds790H6AYj4LZoCXs8Dfv5a3R9U=; b=m2bAes6vUqgFy6/wUo1fSwOggTElaCNw/8VdAyyFGfSXxzOHjuii2hBeYCUTtVsxI2 lrk+afjaeObHAVqIysXItMOybjdG1EYsJg52ZfehIsYc8caoGj5QkrtPiq0OD/fQz7uo kg7wOsvulKOuIm+D/gN/HZhcaueHSbLXn1ViVzm51ITK0RISER2hI8SDPqaTFcBPVNjR OxL4wFB29p8t6zyHxbSakE39n0emlzL+k9GZkf5c/IO0YQ/0dUzhA8HlpHNBDy+ojRx7 3JcLIL+fpv6/NoY0acor74dKQkriPi8B1FhnRk+dmL6TCYy9oxWCqhX+etQrBTHo5XP9 FxQQ== 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=sxh3etBmieR8zQf/Ds790H6AYj4LZoCXs8Dfv5a3R9U=; b=w2ke2h3PaarVYHgjHknlIGcO/bMZ4Z4WsDd3UV+GY6UUgNgNrl6DmyV71H2UhKZL6j Onm50/MQ4+MaT2RsLO7TMmjWjEI4f6WRFDFEW382SXqVG+2/6KMbFOVgFdhHTF4X5jd+ ZGyj5vcQ04kRfmbNpAaQgaJBX7tCgI97Hx7g8KoTZaqIlQmMq12zv2UaTHeaqWZnr0F8 DrYYy3BQFQJFAHs/jV8fky2lTdRiBcc58uEd5tcanUIOmlZ8hlLjBBTSzoViHxPOiUwn +GkaY0/YWjIuPSMbZmYi1fm54yTSSaRMvAnOnXV7iAIZDn1aLaAHWISZymvIonaGGaJE 3xTw== X-Gm-Message-State: ACrzQf3ISWtuv+Ix5AbzVa/fQLE4laU0nTQtlfqtPgwocIVlMlE0V4Rx eQlc5CfvI9DZYue5T5xr1fxYO7vjqVnEjgSKbg== X-Google-Smtp-Source: AMsMyM6kxr1zdU5gkTnhYP+KfTWrPsNsRagcAvJblKsRFMscQWOf8HBExLnIWhVchGEFN0CU8bPn4sZ9TEc8ryIkEcc= X-Received: by 2002:a17:907:7f9e:b0:77f:c4c7:915e with SMTP id qk30-20020a1709077f9e00b0077fc4c7915emr900627ejc.485.1663267769301; Thu, 15 Sep 2022 11:49:29 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> In-Reply-To: From: Paul Pogonyshev Date: Thu, 15 Sep 2022 20:49:17 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="0000000000008e448f05e8bbb4a6" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000008e448f05e8bbb4a6 Content-Type: text/plain; charset="UTF-8" > 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. The variable is not buffer-local, so I cannot change it in the mode, only as my personal setting. Paul On Thu, 15 Sept 2022 at 18:44, Gregory Heytings wrote: > > > > > My attitude is explained by my general experience with Emacs itself and > > reporting any problems I have had with it. Sometimes everything went out > > fine, but far less often than I would have hoped. > > > > We're all doing our best to improve Emacs in our free time. It is > unreasonable to expect that everything would go fine (with your own > definition of "fine") in all cases. It would not be reasonable to expect > that from a private company, either. > > > > > You may see me as a jerk, > > > > I do not. > > > > > I suspect your "help" was to the tune of "instead, you should just...". > > > > That's a rather strange conclusion. I 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). > --0000000000008e448f05e8bbb4a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> already told you thrice that a
> simple way to = fix your problem is to set long-line-threshold to a larger
> value (o= r to nil).

Thanks, I added=C2=A0 `(setf long-line-th= reshold 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. The variable is not buffer-local, so I cannot chan= ge it
in the mode, only as my personal setting.

Paul


On Thu, 15 Sept 2022 at 18:44, Gregory Hey= tings <gregory@heytings.org&= gt; wrote:

>
> My attitude is explained by my general experience with Emacs itself an= d
> reporting any problems I have had with it. Sometimes everything went o= ut
> fine, but far less often than I would have hoped.
>

We're all doing our best to improve Emacs in our free time.=C2=A0 It is=
unreasonable to expect that everything would go fine (with your own
definition of "fine") in all cases.=C2=A0 It would not be reasona= ble to expect
that from a private company, either.

>
> You may see me as a jerk,
>

I do not.

>
> I suspect your "help" was to the tune of "instead, you = should just...".
>

That's a rather strange conclusion.=C2=A0 I already told you thrice tha= t a
simple way to fix your problem is to set long-line-threshold to a larger value (or to nil).
--0000000000008e448f05e8bbb4a6-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 15:16:42 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 19:16:42 +0000 Received: from localhost ([127.0.0.1]:59187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYuLq-0002lJ-GH for submit@debbugs.gnu.org; Thu, 15 Sep 2022 15:16:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYuLn-0002l5-Bp for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 15:16:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55056) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYuLg-0004xr-Rh; Thu, 15 Sep 2022 15:16:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IKwjUFcdycY0rZgHLDkamiytFQE2e0pLEmGSqYKNDT8=; b=iVsEprt3w5mr HcTD71WRtff8AgKIxb0tL6b+03cIYYIf6OyAuvgzhdkXH5TkLBt/6ez3VepTlCFbr/xkdDvE4k8lv 8JbQU1cCFODwB2xBZprdSop6x8l4Bkdz9SBTWSYG3SXbiU8zuLDwcvOe4OxzrfeZ3xAyb1Ww51Pa+ jlz3bi5AY36d8qJnNDLGMme2wKyUtBWW8oMPfq8Hj7+8QTRaTER+Fy/8x+UErg75Nrdi1lsY44Au1 siuZWj7khXta/Pp58/XmxV7ewVuuW3+lJBPygvPgIkiRKufB3sHg81SmHdgEA9Vfn3YAIRZ8D/28D HfuNZq+jafYHHnx73FpemA==; Received: from [87.69.77.57] (port=3062 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 1oYuLg-0002me-8u; Thu, 15 Sep 2022 15:16:32 -0400 Date: Thu, 15 Sep 2022 22:16:24 +0300 Message-Id: <834jx85tyv.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Thu, 15 Sep 2022 20:49:17 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: gregory@heytings.org, 57804@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org > From: Paul Pogonyshev > Date: Thu, 15 Sep 2022 20:49:17 +0200 > > > 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. What do you mean by ":workaround"? Doing that disables the feature which you don't want, so it fits the definition of "solution" in my book. > The variable is not buffer-local, so I cannot change it > in the mode, only as my personal setting. Every variable can be given a local value by using setq-local. Did you try that? If you did, and it didn't work, please show a recipe to reproduce this problem. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 15:36:47 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 19:36:48 +0000 Received: from localhost ([127.0.0.1]:59204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYufH-0003HL-Ai for submit@debbugs.gnu.org; Thu, 15 Sep 2022 15:36:47 -0400 Received: from mail-ed1-f52.google.com ([209.85.208.52]:36615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYufF-0003H5-9X for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 15:36:46 -0400 Received: by mail-ed1-f52.google.com with SMTP id e18so28483405edj.3 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 12:36:45 -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=+HaWSjb4ZUTLp3vG9qqtYK9gllbn9L2ZBnzj5TIVurA=; b=T1D7uDk3vjEmmKkiGo4vBSMAII9dBvpU1gOPn16xiHZb+DJBI6O3hr8AiWExh1Cl3n bfwmgu1hE9Wsenym7ZDYu4Ra7xJYpwRubNOE7iXOKhInkc/aygTbYLIdVhxmT2j4xE+u WPtawVGl4htZU7wxIw2DGyadloouFZe4u+FEZ0HGljdU7XteB2RSQf8XWmrDL1zQf3mx LylkiJp7uF+PjQ0sXDc/ADxxF2bBk3aUqQK8xwDWdayDyqfvH4F+4DZ/o70RPMgN9cw0 YeOraPP7tI+U40+yldZ7duqhe9ZYO/HJVqmD6rBrZfnaLt+6npqNM4nEPSJGf3/eKgJe ox3Q== 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=+HaWSjb4ZUTLp3vG9qqtYK9gllbn9L2ZBnzj5TIVurA=; b=SdYc35gl5QUQxDyIPi3Xw46UfIPonisfu0wW+y+ZkXfETrNRNsSLGdpgzW32uFYCas k+4L6Cjk7JYZa9tp3jthLP1T5azYur50qn2yyrFCGgM+dThT9fPj7vOJEI5AAdHroSex Q8N/q5dRRq9k7Mz2nvrPi3J82bFc68dA9jXrn7Ssy1LxESXXyxds0JnQK6YGUtrbKJnZ xsjdbusH2gwdRcKsPrl4KzJ6Z6pPrSVnFWuTxxuvMtkpP5wNDdSbXIU+PK3irDxDDPD1 DfRLR1U+arfIP8b7zr171CbkffcO1gYy5VLYbbwK1llCx6D529Qb5CN9JZCKtwZY6Olu knag== X-Gm-Message-State: ACrzQf0Z97/JbRzsSwUyrDPh67OqHzYA7kwF1kV2UyWTY5MUR3EErcXc evSe1R5uJg7dKd0ylZfF4Tawfszr5XoZe5rs6w== X-Google-Smtp-Source: AMsMyM4OSGWYobQ/PfqjupnCdoqFQigbVbCi0xZ17eQNBanzXg9AfoX9HmZ+ItHN0fHcW7J4qdXloTkUDuxyKEqdFJg= X-Received: by 2002:a05:6402:516f:b0:44e:9151:d54b with SMTP id d15-20020a056402516f00b0044e9151d54bmr1159640ede.241.1663270599364; Thu, 15 Sep 2022 12:36:39 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> In-Reply-To: <834jx85tyv.fsf@gnu.org> From: Paul Pogonyshev Date: Thu, 15 Sep 2022 21:36:27 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000003d936205e8bc5d9b" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Gregory Heytings , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000003d936205e8bc5d9b Content-Type: text/plain; charset="UTF-8" > What do you mean by ":workaround"? In this case something that can be done for me personally, but not in the mode itself. > Every variable can be given a local value by using setq-local. Did > you try that? No. Tried now, it works. Several questions though. * I see that manually evaluating `(setq-local long-line-threshold nil)' in a buffer where the optimization is already in effect (i.e. where `(long-line-optimizations-p)' evaluates to t) doesn't disable the optimization. Do you have a solution for that? Depending on the mode being activated before Emacs decides to enable the optimization (e.g. because on of the first lines is very long, I don't know how exactly this is determined) seems very shaky. Also, what if someone opens file `my-log-with-funny-extension.records' and then manually activates Logview mode? * I briefly looked at the branch `feature/improved-narrowed-locking' and saw that locking grew "tags". This probably implies that this is going to be used more in the future, maybe already in Emacs 29.1. Is there going to be some way to disable each and every new tag? Should I monitor Emacs sources for new cases of narrowed locking with a tag previously not used? What if one day this becomes available to Elisp and a submode that decides to narrow-lock for whatever reason? How could I prevent that? * Wouldn't something like (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t)) (widen) ... ) not be much more robust? Paul On Thu, 15 Sept 2022 at 21:16, Eli Zaretskii wrote: > > Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org > > From: Paul Pogonyshev > > Date: Thu, 15 Sep 2022 20:49:17 +0200 > > > > > 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. > > What do you mean by ":workaround"? Doing that disables the feature > which you don't want, so it fits the definition of "solution" in my > book. > > > The variable is not buffer-local, so I cannot change it > > in the mode, only as my personal setting. > > Every variable can be given a local value by using setq-local. Did > you try that? If you did, and it didn't work, please show a recipe to > reproduce this problem. > --0000000000003d936205e8bc5d9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> What do you mean by ":workaround"?=C2=A0

In this case something that can be done for me persona= lly, but
not in the mode itself.

> Ev= ery variable can be given a local value by using setq-local.=C2=A0 Did
&= gt; you try that?

No. Tried now, it works.

Several questions though.

* I see that manuall= y evaluating `(setq-local long-line-threshold
nil)' in a buffer wher= e the optimization is already in effect (i.e.
where `(long-line-optimiza= tions-p)' evaluates to t) doesn't disable
the optimization. Do y= ou have a solution for that? Depending on the
mode being activated befor= e Emacs decides to enable the optimization
(e.g. because on of the first= lines is very long, I don't know how
exactly this is determined) se= ems very shaky. Also, what if someone
opens file `my-log-with-funny-exte= nsion.records' and then manually
activates Logview mode?

* I = briefly looked at the branch `feature/improved-narrowed-locking'
and= saw that locking grew "tags". This probably implies that this is=
going to be used more in the future, maybe already in Emacs 29.1. Isthere going to be some way to disable each and every new tag? Should I
= monitor Emacs sources for new cases of narrowed locking with a tag
previ= ously not used? What if one day this becomes available to Elisp
and a su= bmode that decides to narrow-lock for whatever reason?=C2=A0 How
could I= prevent that?

* Wouldn't something like

=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 )

not be much more robust?

Paul

On Thu, 15 Sept 2022 at 21:16, Eli Zaretskii <eliz@gnu.org> wrote:
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 57804@debbugs.gnu.org
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Date: Thu, 15 Sep 2022 20:49:17 +0200
>
> > 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=C2=A0 `(setf long-line-threshold nil)' to Emacs st= artup configuration
> file a couple of days before. But unless I'm missing something, th= is is not a
> fix, only a workaround.

What do you mean by ":workaround"?=C2=A0 Doing that disables the = feature
which you don't want, so it fits the definition of "solution"= in my
book.

> The variable is not buffer-local, so I cannot change it
> in the mode, only as my personal setting.

Every variable can be given a local value by using setq-local.=C2=A0 Did you try that?=C2=A0 If you did, and it didn't work, please show a recip= e to
reproduce this problem.
--0000000000003d936205e8bc5d9b-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 15:44:33 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 19:44:33 +0000 Received: from localhost ([127.0.0.1]:59208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYumn-0003SX-IR for submit@debbugs.gnu.org; Thu, 15 Sep 2022 15:44:33 -0400 Received: from heytings.org ([95.142.160.155]:43042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYuml-0003SP-No for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 15:44:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663271070; bh=vhM6QvcL1f0RBH/3dTc5b12Qh2WmYzf7aRaOzk8IbLU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=nE2ukHa1CPGmCMms2+nWqF0/2a1SWK+FnYm73q//+vEIpQArAjnsUdSaHEARnifPY K/IjHRz/ex0W7xlTbatyk/i4CE3h/R2f/BAs/UkmlmthvXw1pUKBazWECkM5jNRAPA y7Pp7dFRsTqJEfcTOX0o3NY08cI6MdBHtqYS8mViyRPD/0RywoXRE9vCZLh2BLuW8X 0bsrZdldwSXQUjqX9AZg57DoWjaaJjsyKMz/a8/09KJ+O+nE5ejZBSZwRr1eO4w15B zXiFvWueS/gfg0x0GRV59iC0eHK/n+blC/8AMxJbqxdAkbD6HAEHFFdo+4mHixWL37 gj0QWnyTGBQNw== Date: Thu, 15 Sep 2022 19:44:30 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="TbsrZafvZT" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --TbsrZafvZT Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >> already told you thrice that a simple way to fix your problem is to set= =20 >> long-line-threshold to a larger value (or to nil). >=20 > Thanks, I added=C2=A0 `(setf long-line-threshold nil)' to Emacs startup= =20 > configuration file a couple of days before. But unless I'm missing=20 > something, this is not a fix, only a workaround. > Why did you immediately set it to nil instead of trying to making it=20 sufficiently large? You said that some lines in the Logview buffer are=20 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=20 narrowing, by explicitly unlocking the locked narrowing when it needs to=20 access a larger portion of the buffer. You were somewhat reluctant at=20 that idea. --TbsrZafvZT-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 15:46:08 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 19:46:08 +0000 Received: from localhost ([127.0.0.1]:59219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYuoK-0003W9-FW for submit@debbugs.gnu.org; Thu, 15 Sep 2022 15:46:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYuoH-0003V7-2B for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 15:46:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44816) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYuo9-0001dL-Uw; Thu, 15 Sep 2022 15:45:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KicvFYCbYn97/vnhJ2QrtOI5Xzg54D2B8EE4xYzrX6I=; b=M1TvNo9S8zHr A7YMZNoRN663ohJsQWWsFOPj8byGmYQ4OsryVjZq7Xs6tIhhEWCvjeKBMW3R7l1Jcdrs+lcO8/DHU Lk2t15/Wc4d+fC/QGytlevGDyRZgtwb5L5Pz/JwQpvov0nwvCDawGW3m65is9IQtL8EcoZUrt+96m XI04Jq3o7g3AzSgiNTwq1wgAOLopvK8JwYWUSlbOjlL19Z2mLzyOoxWYeTDLIpQpYGwusSxrXG18p KtEnNiBQgvL82y+hx1gLCnj+RyMAzmgN62+zp+NyIxbqHaqCzTpZPhvhZb5UU8xEotCyoF4yanoSW tJNlzPbVGIrYpOGMmDVcFQ==; Received: from [87.69.77.57] (port=4982 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 1oYuo3-0005sC-IR; Thu, 15 Sep 2022 15:45:52 -0400 Date: Thu, 15 Sep 2022 22:45:44 +0300 Message-Id: <8335cs5slz.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Thu, 15 Sep 2022 21:36:27 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: gregory@heytings.org, 57804@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Pogonyshev > Date: Thu, 15 Sep 2022 21:36:27 +0200 > Cc: Gregory Heytings , Lars Ingebrigtsen , 57804@debbugs.gnu.org > > * I see that manually evaluating `(setq-local long-line-threshold > nil)' in a buffer where the optimization is already in effect (i.e. > where `(long-line-optimizations-p)' evaluates to t) doesn't disable > the optimization. Do you have a solution for that? Not at present, I believe (but Gregory may know better). I don't think we saw a need for that, yet. > Depending on the > mode being activated before Emacs decides to enable the optimization > (e.g. because on of the first lines is very long, I don't know how > exactly this is determined) seems very shaky. I think you can rely on this: the decision is made the first time the buffer is displayed, which is after the mode is turned on in it. Of course, the danger is that if the file really has very long lines, Emacs might become unusable. That's what this feature is about: making Emacs usable when editing files with very long lines. > Also, what if someone > opens file `my-log-with-funny-extension.records' and then manually > activates Logview mode? No solution for now. > * I briefly looked at the branch `feature/improved-narrowed-locking' > and saw that locking grew "tags". This probably implies that this is > going to be used more in the future, maybe already in Emacs 29.1. Is > there going to be some way to disable each and every new tag? Should I > monitor Emacs sources for new cases of narrowed locking with a tag > previously not used? What if one day this becomes available to Elisp > and a submode that decides to narrow-lock for whatever reason? How > could I prevent that? I'll leave it for Gregory to answer, since I don't yet know his plans for that branch. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 16:07:45 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:07:45 +0000 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 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 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) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> In-Reply-To: From: Paul Pogonyshev Date: Thu, 15 Sep 2022 22:07:24 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="000000000000f8ea7605e8bccb24" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --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-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 16:18:34 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:18:34 +0000 Received: from localhost ([127.0.0.1]:59288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvJh-0004O8-N1 for submit@debbugs.gnu.org; Thu, 15 Sep 2022 16:18:34 -0400 Received: from heytings.org ([95.142.160.155]:43096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvJd-0004Nw-Fr for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 16:18:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663273108; bh=b8zfLN7lNp+i17eS2AcEZgywrBN6xltUeqqkmJFhxMw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=uTiuK/aqxJLlMvlNTr1aNhTA6iNmo765WPCA8oyEULBJ1V5iLCBN77HmYza/r9oBV XpM3mjiBrj/Juq8W8TgiTqTDO+giSTfBcUFkyDGY2Yb51qLh8WuKIUTpjy5IxLyB4k 1PD3w+QuHdAd3fG+ec96JoYBbR7rQWSq31gyzkXr4PIylSJheNBOUy1C6YLxfTfDd4 F+61t40Zs1KQ3G24Rlb7m3l1gAAEUKNwvfKU4WA0MGwECs5U8cKcKGMarLEN2Yfdvk fz08Chdbfl5crKXItcxbfVt5+ERqaMKE9FIJxYcFZZgPP4BBY1GkCA4J6zL82+t6Oq Fz6Qy8QJf5RHg== Date: Thu, 15 Sep 2022 20:18:27 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="k4TTPbanAd" Content-ID: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --k4TTPbanAd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: > > I see that manually evaluating `(setq-local long-line-threshold nil)' in= =20 > a buffer where the optimization is already in effect (i.e. where=20 > `(long-line-optimizations-p)' evaluates to t) doesn't disable the=20 > optimization. Do you have a solution for that? > No, and that will not be supported. > > Depending on the mode being activated before Emacs decides to enable the= =20 > optimization (e.g. because one of the first lines is very long, I don't= =20 > know how exactly this is determined) seems very shaky. > Indeed. As I told you the proper fix is not to disable these=20 optimizations, but to adapt the code to handle locked narrowing, by=20 explicitly unlocking the locked narrowing when, and only when, it needs to= =20 access a larger portion of the buffer. > > I briefly looked at the branch `feature/improved-narrowed-locking' and=20 > saw that locking grew "tags". This probably implies that this is going=20 > to be used more in the future, maybe already in Emacs 29.1. Is there=20 > going to be some way to disable each and every new tag? Should I monitor= =20 > Emacs sources for new cases of narrowed locking with a tag previously=20 > not used? > No, if your function is called inside fontification-functions, you will=20 not have to monitor Emacs sources, your code will use a single tag, namely= =20 'fontification-functions. > > What if one day this becomes available to Elisp and a submode that=20 > decides to narrow-lock for whatever reason? > Don't worry, that won't happen. > > Wouldn't something like >=20 > (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t)) > =C2=A0 (widen) > =C2=A0 ... > ) > > not be much more robust? > Definitely not. It is more important to take measures to ensure that=20 Emacs remains responsive for its users than to minimize the effort of=20 Elisp programmers. --k4TTPbanAd-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 16:22:38 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:22:38 +0000 Received: from localhost ([127.0.0.1]:59301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvNe-0004Us-CP for submit@debbugs.gnu.org; Thu, 15 Sep 2022 16:22:38 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvNc-0004Ud-OE for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 16:22:37 -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:Date:References: In-Reply-To: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=jpNV3/3eXgzgX4Lw5p9U6jkuwTIptyUvINi3ZQSHn14=; b=YjgnvkEYPLUKh0Qc3QeguEP1sa 0nFjWMTqDAfvVZj350i2ppI1lTrtH1m8UpC7a6LiPC/Uo1NdolhZtgJbSj1Wed0LVCM/Otc7Ojuc/ Jwl+lGGI4U8R/ttYxCK/ztMRteKUUNkRRBvanY5kHx5auWNyfAl9cRH0b+99rSEbzKhA=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYvNT-0005GX-Dx; Thu, 15 Sep 2022 22:22:29 +0200 From: Lars Ingebrigtsen To: Gregory Heytings Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: (Gregory Heytings's message of "Thu, 15 Sep 2022 20:18:27 +0000") References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEXMpLGXVWtAKzX/ //8EVnt4AAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YJDxQVLEf4oUMAAAFwSURBVCjPRdHBauMwEAbg sakN8SmFeKE59VTafQq3LIbNKQ2RwDqHQvQUPXR7dsoqlJxSiEz0P+XOjLNUJ33MSBrNEFFheKWA gyEBGeODRxBkDYcs0oaRZY8M9x9LBhCPAlrXHEBcMug61MYz5DaqTb0CoxfMNnwXEDRtNh4JjSCz YYFkzFpQ2MjwRt4hsgOndS4qXjiCrvZ6wSBpptB3HmLqfLILJ/h57iTyWyPzrWE8j3B28Y2qFayN ovxTM2qryN+lth/BamSwCTjsWz1z7BJ/Dk9a6Kbb8j49azm3/OuEuNJCp9IoRD1DJP1AKi8YGKe5 7ou4Z/y94PCBL7zdjLAr7PA2obGLLXbutVCUrkU/v6RNtk/o3eu94g49Ty4lxbZtqjjHWdtryi7j PiqKEinzHietusI5dxdMy+GU81B3giWnlTz6TNBUOE0cPhU0Qz/xOGQ6+mscK57joyLfC8KvEWVi pDU1lNPVjRFs/gHpyKpg4dR1GQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOS0xNVQyMDoyMTo0 NCswMDowMCe1GEEAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDktMTVUMjA6MjE6NDQrMDA6MDBW 6KD9AAAAAElFTkSuQmCC X-Now-Playing: Pan Amsterdam's _Eat_: "Blue Agave" Date: Thu, 15 Sep 2022 22:22:26 +0200 Message-ID: <87mtb0z8u5.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Gregory Heytings writes: >> I see that manually evaluating `(setq-local long-line-threshold >> nil)' in a buffer where the optimization is already in effect >> (i.e. where `(long-line-optimizations-p)' evaluates to t) doesn't [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Gregory Heytings writes: >> I see that manually evaluating `(setq-local long-line-threshold >> nil)' in a buffer where the optimization is already in effect >> (i.e. where `(long-line-optimizations-p)' evaluates to t) doesn't >> disable the optimization. Do you have a solution for that? > > No, and that will not be supported. Well, that's when you need it -- you've discovered that the current buffer is all wonky because of this, so you want to switch it off in that particular buffer. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 16:26:57 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:26:57 +0000 Received: from localhost ([127.0.0.1]:59311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvRp-0004bI-5X for submit@debbugs.gnu.org; Thu, 15 Sep 2022 16:26:57 -0400 Received: from heytings.org ([95.142.160.155]:43114) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvRn-0004bA-NO for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 16:26:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663273614; bh=z28ZgjUWuMvdgMzvM6T8tAn0Iztu6MU3Eh+R4uGEiO8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=v3g0w3pwK+a61NQ78LyI763r9jg6ytoripgcDtxW1kqINrYfwamqdDCQVctJCj+XZ PCALioOqBGvDH1CUP0NBXc7+pm6Uf6DF/c+L53f/ALSxFBVZdd57ROUedRCLZrfWma Q2a2XTd/YAhkLd7DCjjdXnqhVOoAwUsqjBsz2VfnxB9tbJJBhYKhD8s/iycdgxpKuM LN8yqZ3xM1UojsZrj3/yxoiqOQLnT9uI+EBvaoA9mzN7Hk174Ix6qbu6B2uLCpuAVX 9r7/+oXxmayGd7ko8bb5qVJ1/ZW3kB2lsWRA5aV7q+/Nvv0Up1az1GOjAQJrObVhtd QMeQJXOe3o+qA== Date: Thu, 15 Sep 2022 20:26:54 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > 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. > You just described what would happen without this optimization with a sufficiently long line. > > With long lines I can suffer slow and not-quite-responsive (but still > not hung to death) Emacs, which is much more bearable. > Obviously you did not have to deal with long enough lines. > > 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. > It isn't for me personally, no. It is important for Emacs users. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 16:40:45 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:40:45 +0000 Received: from localhost ([127.0.0.1]:59351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvfA-0004yY-Dq for submit@debbugs.gnu.org; Thu, 15 Sep 2022 16:40:45 -0400 Received: from mail-ed1-f50.google.com ([209.85.208.50]:44601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvf8-0004yK-JL for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 16:40:43 -0400 Received: by mail-ed1-f50.google.com with SMTP id x94so11406279ede.11 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 13:40:42 -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=ZCVdpD6E3VSOevOCEVsWLRz1FaaRTUuhFu4ZQOAMnlo=; b=oemct0n6VBFHrhLxcwJaenBzXpJex1PLb5YoJ4t3xiyUgV76mJpPBJPXeyKyqsTVVQ tQNVz1RhG+4hLNJNi/BTSPapRYqlfi0QkAnQHYAg4M5MYwxFsZAnZUuBVPDR2VQkK00q sSVegF2HxLD8XRnYRuPTDKtCCVkqZW5hkpBRPCzJcoPdaZg76l16bUKg2HMcvpEdG2oQ EnBI7IHpUXpG2dc4BUyVYbu9S9yyydf5xF2gF7kCaSAx0quWx3qrpH3HXVp7ckJb2gV5 OSTNqtnFshXmg9FP2/+WTjztIO2JbzirKg2O0mPGwaX/Pkltp/Kfvp+UqZA+m8Q1xckn 92IQ== 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=ZCVdpD6E3VSOevOCEVsWLRz1FaaRTUuhFu4ZQOAMnlo=; b=55JGs/Ejz84M02DfZDID4rrikCf33UdeYhqS0s5FUidsBtCHh7ZPaxbnKD+McqKuIW 7mrKIuFPP6uXVRRRZHB34QLHzlM11VujMQEaK1SZ1lsJ4PFiDwqHnEaBPcrguxuQKjjv XznwnoYSaO6JAxi6WAyWUtxJ0iq04zCKnEKwis/QKWiNXUqBrcgv/mrTHz1/mYHfmZb3 qINItzrg5mUqMByy7YfVHZKzt+d+4+Ykc9hnJh3NkTkPhHZyw1BR8qFZi5QJeUEU+kY4 MR+IHoErdYTIhHmXsjFSx3PvXgcQGIocGp4Ypx9/IX8weOnSAiDSRw9yAdqxt4bkVMuA Qiew== X-Gm-Message-State: ACrzQf3Z7rfhzOrNGkJyKkEBs23gHPlc0XsOQ4NOJal3LvSu6ipcRzR3 iEkBIPa8/o2P9enD+GwfOVseXIHSoOiIHMCLgg== X-Google-Smtp-Source: AMsMyM50UxZtURmx5D9TX5EKOQMZcxY5i8qLMlfGgotFUARf79fmF5pnxHMI101L4vxIXgxrlGBygMxUONYU51oa1TI= X-Received: by 2002:a05:6402:3904:b0:451:f01c:9217 with SMTP id fe4-20020a056402390400b00451f01c9217mr1365765edb.78.1663274436736; Thu, 15 Sep 2022 13:40:36 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> In-Reply-To: From: Paul Pogonyshev Date: Thu, 15 Sep 2022 22:40:24 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="000000000000f73b2705e8bd4180" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000f73b2705e8bd4180 Content-Type: text/plain; charset="UTF-8" > No, if your function is called inside fontification-functions, you will > not have to monitor Emacs sources, your code will use a single tag, namely > 'fontification-functions. So, I will be able to unlock? > > Wouldn't something like [...] not be much more robust? > > Definitely not. Or not? I don't understand how these two answers from you combine. It is impossible to correctly fontify log buffers if you are restricted to semi-arbitrary parts of it: you need to at least see where the current entry starts, even if it for whatever reason includes a line with 100 K characters. > It isn't for me personally, no. It is important for Emacs users. How about letting Emacs users decide for themselves? Let Logview behave against your recommendations. And then, when the users discover how crappy and unresponsive it is, as a result, compared to everything else, they will just uninstall the package and use something better. Paul On Thu, 15 Sept 2022 at 22:18, Gregory Heytings wrote: > > > > > I see that manually evaluating `(setq-local long-line-threshold nil)' in > > a buffer where the optimization is already in effect (i.e. where > > `(long-line-optimizations-p)' evaluates to t) doesn't disable the > > optimization. Do you have a solution for that? > > > > No, and that will not be supported. > > > > > Depending on the mode being activated before Emacs decides to enable the > > optimization (e.g. because one of the first lines is very long, I don't > > know how exactly this is determined) seems very shaky. > > > > Indeed. As I told you the proper fix is not to disable these > optimizations, but to adapt the code to handle locked narrowing, by > explicitly unlocking the locked narrowing when, and only when, it needs to > access a larger portion of the buffer. > > > > > I briefly looked at the branch `feature/improved-narrowed-locking' and > > saw that locking grew "tags". This probably implies that this is going > > to be used more in the future, maybe already in Emacs 29.1. Is there > > going to be some way to disable each and every new tag? Should I monitor > > Emacs sources for new cases of narrowed locking with a tag previously > > not used? > > > > No, if your function is called inside fontification-functions, you will > not have to monitor Emacs sources, your code will use a single tag, namely > 'fontification-functions. > > > > > What if one day this becomes available to Elisp and a submode that > > decides to narrow-lock for whatever reason? > > > > Don't worry, that won't happen. > > > > > Wouldn't something like > > > > (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t)) > > (widen) > > ... > > ) > > > > not be much more robust? > > > > Definitely not. It is more important to take measures to ensure that > Emacs remains responsive for its users than to minimize the effort of > Elisp programmers. --000000000000f73b2705e8bd4180 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> No, if your function is called inside fontification-f= unctions, you will
> not have to monitor Emacs sources, your code wil= l use a single tag, namely
> 'fontification-functions.

So,= I will be able to unlock?

> > Wouldn't something like [..= .] not be much more robust?
>
> Definitely not.

Or not? = I don't understand how these two answers from you combine.

It is= impossible to correctly fontify log buffers if you are
restricted to se= mi-arbitrary parts of it: you need to at least see
where the current ent= ry starts, even if it for whatever reason
includes a line with 100 K cha= racters.

> It isn't for me personally, no.=C2=A0 It is import= ant for Emacs users.

How about letting Emacs users decide for themse= lves? Let Logview
behave against your recommendations. And then, when th= e users discover
how crappy and unresponsive it is, as a result, compare= d to everything
else, they will just uninstall the package and use somet= hing better.

Paul

On Thu, 15 Sept 2022 at 22:18, Gregory Heytin= gs <gregory@heytings.org>= wrote:

>
> I see that manually evaluating `(setq-local long-line-threshold nil)&#= 39; in
> a buffer where the optimization is already in effect (i.e. where
> `(long-line-optimizations-p)' evaluates to t) doesn't disable = the
> optimization. Do you have a solution for that?
>

No, and that will not be supported.

>
> Depending on the mode being activated before Emacs decides to enable t= he
> optimization (e.g. because one of the first lines is very long, I don&= #39;t
> know how exactly this is determined) seems very shaky.
>

Indeed.=C2=A0 As I told you the proper fix is not to disable these
optimizations, but to adapt the code to handle locked narrowing, by
explicitly unlocking the locked narrowing when, and only when, it needs to =
access a larger portion of the buffer.

>
> I briefly looked at the branch `feature/improved-narrowed-locking'= and
> saw that locking grew "tags". This probably implies that thi= s is going
> to be used more in the future, maybe already in Emacs 29.1. Is there <= br> > going to be some way to disable each and every new tag? Should I monit= or
> Emacs sources for new cases of narrowed locking with a tag previously =
> not used?
>

No, if your function is called inside fontification-functions, you will not have to monitor Emacs sources, your code will use a single tag, namely =
'fontification-functions.

>
> What if one day this becomes available to Elisp and a submode that > decides to narrow-lock for whatever reason?
>

Don't worry, that won't happen.

>
> Wouldn't something like
>
> (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t)) >=C2=A0 =C2=A0 (widen)
>=C2=A0 =C2=A0 ...
> )
>
> not be much more robust?
>

Definitely not.=C2=A0 It is more important to take measures to ensure that =
Emacs remains responsive for its users than to minimize the effort of
Elisp programmers.
--000000000000f73b2705e8bd4180-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 16:44:47 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:44:48 +0000 Received: from localhost ([127.0.0.1]:59359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvj5-00054i-MN for submit@debbugs.gnu.org; Thu, 15 Sep 2022 16:44:47 -0400 Received: from heytings.org ([95.142.160.155]:43142) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvj4-00054Y-4I for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 16:44:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663274684; bh=ugypVm7vB+s/5V0HqzpI18aIE9bnUU0p5/Tl07p7aVU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=kCyJmSuJSWIsBgIB9Lnxc/JJjqqrhl+NhBuMC9hl6YaJlt1hawpl/gwIdBcLll7bp 2+ZFcvfZwDpPvEJpoEcLp5e3pCzQ2ild79PduDqgokIG00sicd6RASfwNywt01vFcx mEzgLtKPfmH7lhYP7ksan0rKGMq52/29iYiNXhvtOWN+KAWQ9VyfvLGO5SFoAJMZDr 8NsH7dm+rDf8TzteRlSaN/pXoh0/EtDrFJdI6IJ8opW1/MCNSsscluUlNqEkZe0JFA cpXneeWdVkC7MGdruldwKBjwXy6jz+jHqHxcWq961DMRckp8cJVYQ9wWRM/Q0Szo8g 0A4fag/ChmgpQ== Date: Thu, 15 Sep 2022 20:44:43 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> No, if your function is called inside fontification-functions, you will >> not have to monitor Emacs sources, your code will use a single tag, >> namely 'fontification-functions. > > So, I will be able to unlock? > Yes. > > Let Logview behave against your recommendations. And then, when the > users discover how crappy and unresponsive it is, as a result, compared > to everything else, they will just uninstall the package and use > something better. > Given that you will be able to unlock, that will be possible. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 17:17:52 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 21:17:52 +0000 Received: from localhost ([127.0.0.1]:59375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYwF3-00080b-Ak for submit@debbugs.gnu.org; Thu, 15 Sep 2022 17:17:52 -0400 Received: from mail-ej1-f47.google.com ([209.85.218.47]:38691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYwEx-00080H-AS for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 17:17:47 -0400 Received: by mail-ej1-f47.google.com with SMTP id u9so45038704ejy.5 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 14:17: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=NXRqV0LglmB4u37m0OZX2azEp7WoJfkKPjU4xgeC65M=; b=Q7XmrZOHEyVGEieMDzmgLRYRpp/nP1Lq8RzXulNKh6xLh5rj6Q4QiTWkCZOeOk77gp EGfw2M7v+zVxNHtgfy5T5IQ32vFNlpUtCLCn1hr+0qq8Jiuk5sRNLnqvgxsoIvszBlhQ brmB3jQH1Co1d8C7wgdOkE4xeejB3hYjQxClNfEimGD4avN95KgYcIrgevc1FWJtWQCT uQw3gnQ4Ifhn2UWJwlNUXBA/rY7sgdBNEzkBjkVwPqzqJgvwRsEo1r4u44LbEYsyOn48 ef0L34hkFJtJe7NrL511otch6tKgxJwj65hyZRa10KI8Ix0N116052Ves5OJAfIPmPWd 6Ykw== 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=NXRqV0LglmB4u37m0OZX2azEp7WoJfkKPjU4xgeC65M=; b=JJYh6XZW47ne26eBo2fKFGRL73sKj1Ta5n1p+ucfe7kzhl3CUSfcY/ubijZiS7XuKo TqshIt/KT9Kq2CRV+5rFgDed2WGRMk4rVbdceuel97I/Cb/QKuFc5GUwxEYX8uvhiRBj t5DUV0NT9peAinKfncuiwVnxdoFu6pYa/PPHUGKu4Fi2FzNQ8qfg7OlkOcL1/CRLrA2/ lh2As/3KF+9COsrzGOJzJTjvTI9gIS2WZkqZTf/h1qSn9b0Q9D73Y/t12xIQQm94NIvN LddlqV+QPAQPF14+RbG+egydjd4tLQtZbd+y+dfKrnYE1yV5Z+rCk2OhGZuJc09T3R8r NlOQ== X-Gm-Message-State: ACrzQf0jGZj2ldNX3C6kG7xBBd0yF4sts8GCGl4WiftLZc294rjqv+87 N+IUf05acU+vKjViPnb75UTvg8apXrHIOhRRMg== X-Google-Smtp-Source: AMsMyM7isLQXacK7u/dq6kfVd/QdO0oRKlk0FiC06GWDIs1IqGR9PKrAqnep5pYJkJaCee9ewASj3H2FayAAgMEhJDg= X-Received: by 2002:a17:906:fe09:b0:77a:52b3:da5d with SMTP id wy9-20020a170906fe0900b0077a52b3da5dmr1239077ejb.57.1663276657375; Thu, 15 Sep 2022 14:17:37 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> In-Reply-To: From: Paul Pogonyshev Date: Thu, 15 Sep 2022 23:17:25 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="000000000000537e8205e8bdc6ae" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000537e8205e8bdc6ae Content-Type: text/plain; charset="UTF-8" >>> No, if your function is called inside fontification-functions, you will >>> not have to monitor Emacs sources, your code will use a single tag, >>> namely 'fontification-functions. >> >> So, I will be able to unlock? > > Yes. Good. > > Wouldn't something like [...] not be much more robust? > > Definitely not. But why? If you allow to lift restrictions, why not make it easy to do? Call the variable/function that achieves this with a 100-character name, brand the programmer an idiot in the name or documentation - whatever. Don't advertise it in the manual, maybe add two lines somewhere in a dark corner, repeating that only morons would use it. But please, add something generic and simple to use. Logview needs to temporarily cancel restrictions in _practically all_ its function. In the branch I see code like this: narrow_to_region_locked (make_fixnum (get_narrowed_begv (w, PT)), make_fixnum (get_narrowed_zv (w, PT)), hook); ^^^^ So, suppose something in that hook (maybe even not installed by Logview itself, e.g. by a minor mode or by the user: it is common to have `add-hook' in Emacs initialization code) calls a function from Logview. Now, that function from Logview does (please-widen-i-cant-work-with-locked-narrowing ...) It, presumably, cannot know the tag used to install locked narrowing. Will it be able to temporarily lift _any and all_ locked narrowing or not? It probably won't freeze Emacs even if falling into an infinite loop, likely there are not so many non-bugs like the one in this thread, where misbehaving code can make Emacs hang irrepairably. But still, if restrictions are not lifted, Logview function will likely produce some incorrect result, require C-g to abort, or die with an error. Will the knowledge of the tag be required, as a sort of a "password", to lift narrowing restrictions, or not? Paul On Thu, 15 Sept 2022 at 22:44, Gregory Heytings wrote: > > >> No, if your function is called inside fontification-functions, you will > >> not have to monitor Emacs sources, your code will use a single tag, > >> namely 'fontification-functions. > > > > So, I will be able to unlock? > > > > Yes. > > > > > Let Logview behave against your recommendations. And then, when the > > users discover how crappy and unresponsive it is, as a result, compared > > to everything else, they will just uninstall the package and use > > something better. > > > > Given that you will be able to unlock, that will be possible. > --000000000000537e8205e8bdc6ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>> No, if your function is call= ed inside fontification-functions, you will
>>> not have to mon= itor Emacs sources, your code will use a single tag,
>>> namely= 'fontification-functions.
>>
>> So, I will be able t= o unlock?
>
> Yes.

Good.

> > Wouldn't s= omething like [...] not be much more robust?
>
> Definitely not= .

But why? If you allow to lift restrictions, why not make it easy t= o
do? Call the variable/function that achieves this with a 100-character=
name, brand the programmer an idiot in the name or documentation -
w= hatever. Don't advertise it in the manual, maybe add two lines
somew= here in a dark corner, repeating that only morons would use
it. But plea= se, add something generic and simple to use.

Logview needs to tempor= arily cancel restrictions in _practically all_
its function. In the bran= ch I see code like this:

=C2=A0 =C2=A0 narrow_to_region_locked (make= _fixnum (get_narrowed_begv (w, PT)),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make_f= ixnum (get_narrowed_zv (w, PT)),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hook);=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^

So, suppo= se something in that hook (maybe even not installed by
Logview itself, e= .g. by a minor mode or by the user: it is common to
have `add-hook' = in Emacs initialization code) calls a function from
Logview. Now, that f= unction from Logview does

=C2=A0 =C2=A0 (please-widen-i-cant-work-wi= th-locked-narrowing ...)

It, presumably, cannot know the tag used to= install locked narrowing.
Will it be able to temporarily lift _any and = all_ locked narrowing or
not? It probably won't freeze Emacs even if= falling into an infinite
loop, likely there are not so many non-bugs li= ke the one in this
thread, where misbehaving code can make Emacs hang ir= repairably. But
still, if restrictions are not lifted, Logview function = will likely
produce some incorrect result, require C-g to abort, or die = with an
error.

Will the knowledge of the t= ag be required, as a sort of a "password",
to lift narrowing r= estrictions, or not?

Paul

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

>> No, if your function is called inside fontification-functions, you= will
>> not have to monitor Emacs sources, your code will use a single tag= ,
>> namely 'fontification-functions.
>
> So, I will be able to unlock?
>

Yes.

>
> Let Logview behave against your recommendations. And then, when the > users discover how crappy and unresponsive it is, as a result, compare= d
> to everything else, they will just uninstall the package and use
> something better.
>

Given that you will be able to unlock, that will be possible.
--000000000000537e8205e8bdc6ae-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 17:32:21 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 21:32:21 +0000 Received: from localhost ([127.0.0.1]:59411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYwT7-0008OI-DB for submit@debbugs.gnu.org; Thu, 15 Sep 2022 17:32:21 -0400 Received: from heytings.org ([95.142.160.155]:43200) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYwT5-0008OA-O0 for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 17:32:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663277538; bh=iZpzsDzCSYMgY62kygV9nJkAyWvvOPk3S0TWkcvRDMQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=Jhrzmt8CBk5iyrtP6uMMdB3e7v0LdYDiKsIyq6rQSZCrzZ/ophMeHc+XiMPN5NYvD G9pS1S4Qyq/NXZpGtW0dv6O++ixNrquFdzb4izN2DlFAmjIQqDfD1ewF3Htt4ESLv3 tdEbW5YGnDrC5f1xbCvAhZ61QzM3CrYkXeOl33xFJSORSzWqpPx5D12xaqD2tQ1TYs NUsJCOqTonUE8CM5UfyCZuciNy6/9VpKeABV2eUdGk65reJfibUTAgKreWMnrp9j5i lnig4LyjoKfHD5Fmta734X048RgGjeMKpwQuKne8N2cwHcOpVQto4+O+4OW81hZ2ek 3y3PFNUNcmroA== Date: Thu, 15 Sep 2022 21:32:18 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > Logview needs to temporarily cancel restrictions in _practically all_ > its function. > It can do so (or more precisely will be able to do so) by calling narrowing-unlock with the appropriate tag, which IIUC correctly is, in your case, 'fontification-functions. I don't see why you would need anything else, especially given that a general mechanism to disable locked narrowing everywhere is already available for users who, like you, don't care about long lines. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 17:49:33 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 21:49:33 +0000 Received: from localhost ([127.0.0.1]:59421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYwjk-0000NC-UX for submit@debbugs.gnu.org; Thu, 15 Sep 2022 17:49:33 -0400 Received: from mail-ed1-f44.google.com ([209.85.208.44]:37548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYwjh-0000My-DU for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 17:49:30 -0400 Received: by mail-ed1-f44.google.com with SMTP id a41so17083889edf.4 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 14:49:29 -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=6ALit5UQwF1/YC4qBRaPrPbNkDU0I6Ax38Mzt7SUCLw=; b=MyD85cBDEGJtSR139+Mwv09rdVs18ipc7BHXcs8vk/xPLIkOAF7P1F1mkqo84s2xTj 8R5sKsU5NUG8wcXg2pAuITHvO4Cb4KFLPGSxYij9YdaPHrmvAvdrvcrjumIS0BGAHxHZ sZpAd5dtSM/DKuHIeejkqC1xbKnrMhwTIdvUSlZmxnz7Cn739U0K8h7qRmV/JCglkEfp 59nKcFn+NI3qr6+dUoVh0eGIuWPwi1sIS7PuHFXFjX6SuvzSHjyB7VvlNbaCwlaFNuLJ 4ZAiYefx1segMsMWdu9l05HZjcwMkF7z+wgHm2vTF61q5RTZnylEqh5rZ23OGKRL6RJo XWCQ== 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=6ALit5UQwF1/YC4qBRaPrPbNkDU0I6Ax38Mzt7SUCLw=; b=bcOPDdtEnbkG986Kqk6sLyRDkMHp1DItsOFdtD2tQWM0A/SPu+Nk+rkcKQb+yU7H9y 5MAtCpkriOshwgJJLhrxrjQx/9GU+EqN5HwKGrV0s2XZHNxe+xtoLYJXEaYwTo+Pj0WD +Nmpmznvsv0Zg6AqO3ZMCx8oRQDuhk/+/oKUyoYVBHVUmeG80WmcpQtxXehW0N+bUp9H fqkaYWaVfeXxf/fjJOX/L0beBmonYKMoyMHv8G24LSIRpD/COqh7uQ33hsagfgv2z7L4 KKpBYTu48bK5W7F5dHFrP6G/vIr50asza1Fu7ZVS14f/5gz4FWt2uJkJMpgLiCPx09oC M0tQ== X-Gm-Message-State: ACrzQf0e7ibqbgrbXkzgYXVpGSIAElKz7xynlM4Obrikz8zXQ6tvHRX+ F4R5IbquTVDbNyneLMdolF9XTxH+Q5AHYrkTgA== X-Google-Smtp-Source: AMsMyM6pXPCRsERVv2JA9R1QQNp6q8NsILYi3KIROBsFuZNgtXgzbJ7oYe4Qz4EFK1KYNyFb0eaNiA1jg9vwH7Zj13U= X-Received: by 2002:a05:6402:43cf:b0:450:eae1:c9d3 with SMTP id p15-20020a05640243cf00b00450eae1c9d3mr1525091edc.231.1663278563393; Thu, 15 Sep 2022 14:49:23 -0700 (PDT) MIME-Version: 1.0 References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> In-Reply-To: From: Paul Pogonyshev Date: Thu, 15 Sep 2022 23:49:10 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="000000000000ef045705e8be3768" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000ef045705e8be3768 Content-Type: text/plain; charset="UTF-8" > It can do so (or more precisely will be able to do so) by calling > narrowing-unlock with the appropriate tag, which IIUC correctly is, in > your case, 'fontification-functions. OK, let me rewrite this in a bit more details. Here are some quotes from the C code in the branch: safe_run_hooks_maybe_narrowed (Qpre_command_hook, XWINDOW (selected_window)); ... safe_run_hooks_maybe_narrowed (Lisp_Object hook, struct window *w) { ... if (current_buffer->long_line_optimizations_p) narrow_to_region_locked (make_fixnum (get_narrowed_begv (w, PT)), make_fixnum (get_narrowed_zv (w, PT)), hook); Note how `hook' becomes `tag', i.e. narrowing is locked with tag `pre-command-hook' _in this case_. According to the code, it can also be locked with a few others, e.g. `post-command-hook'. Now, user writes in his `init.el' sth. like: (add-hook 'pre-command-hook (lambda () (when (eq major-mode 'logview-mode) (logview-do-bla-bla-bla)))) I don't know why, this is a hypothetical, but fairly realistic situation, right? Now, let's say function `logview-do-bla-bla-bla' cannot work with narrowed buffer (half of functions in Logview cannot). So, as a first step it does something like this: (save-restriction (widen) ... ) For this to keep working in Emacs 29, I will need to replace `(widen)' with I-don't-yet-know-what. But _I don't know the tag_. That's the problem. The function is called from somewhere I have no control, it can be bound to any hook that does install locked narrowing with some tag or maybe does not - I have no way to know that. Will I be able to lift locked narrowing restrictions without knowing the tag? Paul On Thu, 15 Sept 2022 at 23:32, Gregory Heytings wrote: > > > > > Logview needs to temporarily cancel restrictions in _practically all_ > > its function. > > > > It can do so (or more precisely will be able to do so) by calling > narrowing-unlock with the appropriate tag, which IIUC correctly is, in > your case, 'fontification-functions. I don't see why you would need > anything else, especially given that a general mechanism to disable locked > narrowing everywhere is already available for users who, like you, don't > care about long lines. > --000000000000ef045705e8be3768 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> It can do so (or more precisely will be able to do so= ) by calling
> narrowing-unlock with the appropriate tag, which IIUC = correctly is, in
> your case, 'fontification-functions.

OK= , let me rewrite this in a bit more details. Here are some quotes
from t= he C code in the branch:

=C2=A0 =C2=A0 safe_run_hooks_maybe_narrowed= (Qpre_command_hook,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0XWINDOW (selected_window));

=C2=A0 =C2=A0 ...

=C2=A0 =C2= =A0 safe_run_hooks_maybe_narrowed (Lisp_Object hook, struct window *w)
= =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 if (cur= rent_buffer->long_line_optimizations_p)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 n= arrow_to_region_locked (make_fixnum (get_narrowed_begv (w, PT)),
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make_fixnum (get_narrowed_zv (w, PT))= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hook);

Note how `hoo= k' becomes `tag', i.e. narrowing is locked with tag
`pre-command= -hook' _in this case_. According to the code, it can also
be locked = with a few others, e.g. `post-command-hook'.

Now, user writes in= his `init.el' sth. like:

=C2=A0 =C2=A0 (add-hook 'pre-comma= nd-hook (lambda ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (when (e= q major-mode 'logview-mode)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (logview-do-bla-bla-bla))))

I don't know why, this= is a hypothetical, but fairly realistic
situation, right?

Now, l= et's say function `logview-do-bla-bla-bla' cannot work with
narr= owed buffer (half of functions in Logview cannot).=C2=A0 So, as a first
= step it does something like this:

=C2=A0 =C2=A0 (save-restriction=C2=A0 =C2=A0 =C2=A0 (widen)
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 = =C2=A0 )

For this to keep working in Emacs 29, I will need to replac= e `(widen)'
with I-don't-yet-know-what.=C2=A0 But _I don't k= now the tag_.=C2=A0 That's the
problem.=C2=A0 The function is called= from somewhere I have no control, it
can be bound to any hook that does= install locked narrowing with some
tag or maybe does not - I have no wa= y to know that.

Will I be able to lift locked narrowing restrictions= without knowing
the tag?

Paul

On Thu, 15 Sept 2022 at 23:32, = Gregory Heytings <gregory@heytin= gs.org> wrote:

>
> Logview needs to temporarily cancel restrictions in _practically all_ =
> its function.
>

It can do so (or more precisely will be able to do so) by calling
narrowing-unlock with the appropriate tag, which IIUC correctly is, in
your case, 'fontification-functions.=C2=A0 I don't see why you woul= d need
anything else, especially given that a general mechanism to disable locked =
narrowing everywhere is already available for users who, like you, don'= t
care about long lines.
--000000000000ef045705e8be3768-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 18:16:41 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 22:16:41 +0000 Received: from localhost ([127.0.0.1]:59437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxA0-00012M-NJ for submit@debbugs.gnu.org; Thu, 15 Sep 2022 18:16:41 -0400 Received: from heytings.org ([95.142.160.155]:43280) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYx9y-00012D-N3 for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 18:16:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663280197; bh=ULBVQJUYdopx/sUgsjCfZ7pjQc+OibTEnCmPKhz//wE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=v6zOGxuKjVdto8pJIO7C9MQHCZq15BypOmFgJg+nh27KoxuvLyjNLotUuQZhNnkjm 6a25vou8aRMNKpjx29WpDxAD6NAcUANyR1WkcUHab+Ry9Ec8gYzLyd3cGvt8Yv+obx +dmGhYSeWt4+OrGz+jWnVkNpLP6uCZ8UXvnpbGzU7R4NG1Q6iLDV0ee/YcylxTZOYo siBr+JGmzpNH2ut68upNIid/VjhvXzSekvn333i6WSB2GTUElZfd6MMpcHHKUOOAxD lXJOridtzxRZx6ZDhKSM5SZGMXq1NcR3EJxDaASGgIbpQeWCN8TseUi5YFzfSTcSNl 3nopa5TkC9hZw== Date: Thu, 15 Sep 2022 22:16:36 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > I don't know why, this is a hypothetical, but fairly realistic > situation, right? > Discussing hypothetical issues leads nowhere, according to my experience. Let's focus on actual issues. > > Now, let's say function `logview-do-bla-bla-bla' cannot work with > narrowed buffer (half of functions in Logview cannot). > You said I'm not allowed to tell you that your code could do things differently, but that doesn't mean it isn't true. It is for example possible to parse the buffer outside of fontification-functions and to use the result of that parsing inside fontification-functions. Yet another method would be to use a simpler fontification method in buffers with too long lines. Yet another method would be to turn font locking off in buffers with too long lines. Yet another method would be to truncate too long lines. I also cannot understand why it is necessary, in log files in which all lines are independent, to move beyond the beginning and end of a line to decide how it must be fontified. > > Will I be able to lift locked narrowing restrictions without knowing the > tag? > This is akin to a security mechanism, there is no reason to make it possible to turn it off "too easily". From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 18:38:33 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 22:38:33 +0000 Received: from localhost ([127.0.0.1]:59476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxUy-0001a7-W1 for submit@debbugs.gnu.org; Thu, 15 Sep 2022 18:38:32 -0400 Received: from heytings.org ([95.142.160.155]:43324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxUx-0001Zy-2R for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 18:38:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663281497; bh=ecFf/tpNC3ymF/8s0MDxj0kU1UYFhJwuHLbFky03o+Q=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=05kDMkItJW3Rd1bbIJytzmEVDIx3ReeuLgTmSRJ1CJiN79swe5pjIZ/AoR2OXcfsZ i1LRlcrFTgXS2D/5wqVmZr776Sm+ohYrWgeUDfbjR9pezU5UWFB8XIlJLMgSHAybOT gBIMl2/x7ziRGyz3mukti3+ntA5EwbSCRQcv57woj9wL5tTJWwd8/Zmx1FCoVYNxdf T2KQzWQlKY/T7WcLw3fNbKc8K54icxJq3IjiyLVHF9bD4/JKhZgwbbafSNxaOHQLQI Zva1k3t2fv4Dv7WiFhpbYHWnyb/uCzB2fl9AE+ruUT8eYmeHXxwgXqC7WYajPQgKHQ OIgEFMRHybSgQ== Date: Thu, 15 Sep 2022 22:38:17 +0000 From: Gregory Heytings To: dick Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: <87y1uki8ji.fsf@dick> Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <87y1uki8ji.fsf@dick> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > who then when presented with a real-world failure suggests the aggrieved > module ought to accommodate his long lines fix > It was clear from the very beginning that the long line fixes would break some code in unusual circumstances, and that such code would have to be adapted. That is unavoidable, except of course with frozen programs such as the TeX engine. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 18:54:01 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 22:54:01 +0000 Received: from localhost ([127.0.0.1]:59504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxk8-0001zc-Mg for submit@debbugs.gnu.org; Thu, 15 Sep 2022 18:54:01 -0400 Received: from mail-ej1-f48.google.com ([209.85.218.48]:46631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxk3-0001zL-GD for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 18:53:58 -0400 Received: by mail-ej1-f48.google.com with SMTP id bj12so45343151ejb.13 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 15:53:55 -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=QQWwvPwWm8LfFrOXczxHdbboT8HEl685eTC1eAHdYLc=; b=Wn7QlI9wsR1uNA/aB5U7xYRuROi44R/eUgTGNRnodVVKZ9mKed6vVWicwMnrd+J94O JV6syk5yR7b5IBAiFno1a1h0Bz1/tzR6MZzMhZyThCErUC4fPtejG/bMpjo2dqIG/ITj kfrbuc8oJMzn3adGSoSLCaRQGlWig7WbjteWH0ertVfqjpsUvgVIpkaQtR+UQC5CgZZq iGybw8oB7hye6wP0im5Q9zTZHOO8faetAmgimEs3z4tyoFNJflq3UVnhKNG7s8xket9t dOEks8IgHM8Zs8DQga65Jsg2sIq9qiAYIERhTCYZmqsy6Dbjm7pv3MJIhIt4wukI0+CG hykQ== 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=QQWwvPwWm8LfFrOXczxHdbboT8HEl685eTC1eAHdYLc=; b=DMRoTadBifvCzmt/Z01ulEbCGQnquWXxLVuffnI50Di8JYx5jFwhqjW3nYJ63P2Twu UWnOeZ0rorTROZ4fgnJHSVUrkR/XX2fwBTEANX4+XtX/VGsNAWnauWv6LSaUb0U5YrLs ar2wo/o4X7UMCsX1eZvZpY+L62+W/cDqAixCi0VU50xTTsBZSPKT/Eb4fqwIeYCZ/Ugo JNl98HQ/TU5CvQ3cqi8Zggh2rT9cLuW4MQ3oGeP/PK6Lga9z0R3QSDpom8PhM0WOZM5f MQES8j5WiemJItkXL8tC8TunPBM2ODOPsvPwPasYBdtA6iKLQgDme6Buj7MpSSkfaucq 7Tgw== X-Gm-Message-State: ACrzQf33bKYc8WVH6u6ybtmdm9kuDAVnba/m64H9HH1lYRJxv41HhH1i xL5CN8X0GwuwukIG4RfQ5Q78JiO6tn9shbKEHA== X-Google-Smtp-Source: AMsMyM4LT7exmIP2udDrgxPK4TEh+F/ppYCBNQRrY8pSCbB+d1iCZDfWVXWJ8sJnGjInk8PI3M5SOXTgvhzUV5PokxA= X-Received: by 2002:a17:906:6a0e:b0:77c:a049:7cfc with SMTP id qw14-20020a1709066a0e00b0077ca0497cfcmr1402391ejc.732.1663282429583; Thu, 15 Sep 2022 15:53:49 -0700 (PDT) MIME-Version: 1.0 References: <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> In-Reply-To: From: Paul Pogonyshev Date: Fri, 16 Sep 2022 00:53:37 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Gregory Heytings Content-Type: multipart/alternative; boundary="00000000000060672d05e8bf1e89" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000060672d05e8bf1e89 Content-Type: text/plain; charset="UTF-8" > > I don't know why, this is a hypothetical, but fairly realistic > > situation, right? > > Discussing hypothetical issues leads nowhere, according to my experience. > Let's focus on actual issues. I have shown you a simple way how your supposed can break things. Yes, it's not an everyday occurence, but if I could think of one easily, this or something else to this effect will be used in reality. As a reminder, Emacs self-advertises itself as "advanced, extensible" editor. You are making some extensions illegal, because maybe something somewhere might become slow. You are sacrificing functionality in the name of performance. > It is for example possible to parse the buffer outside of > fontification-functions You are ignoring that this is not only about fontification. It can happen anywhere, because I may need full access to the buffer at any time. > and to use the result of that parsing inside > fontification-functions. Parsing is done lazily. You are saying I need to prepare parsing results everywhere in the whole buffer at once (which easily can be 10 MB - I have seen logs 250 MB in size, but not ones with lines longer than ~50 K characters), because I don't know in advance where fontification (or whatever else) might be needed. > Yet another method would be to use a simpler fontification method in > buffers with too long lines. Yet another method would be to turn > font locking off in buffers with too long lines. I don't want to lose fontification in a 10 MB buffer because one line somewhere there is over 10000 characters. > Yet another method would be to truncate too long lines. Eh? And corrupt the log? Otherwise, even if it is invisible it stays in the buffer. > I also cannot understand why it is necessary, in log files in > which all lines are independent No they are not. Typically Java exceptions are logged like this: 2022-09-15 23:11:00.014 ERROR [some.Class] (some-thread) bla-bla-bla exception.Class: bla-bla-bla at some.Class and so on. Exceptions are not the only multiline entries. I have already complained about this often-seen-here "I also cannot understand", which implies "therefore no-one will ever need", but you said it was bad attitude from me. > > Will I be able to lift locked narrowing restrictions without knowing the > > tag? > > This is akin to a security mechanism, there is no reason to make it > possible to turn it off "too easily". Security against what, for fuck's sake? By trying to prevent "making it too easily", you are preventing this at all in general case. And what are the gains? Paul On Fri, 16 Sept 2022 at 00:16, Gregory Heytings wrote: > > > > > I don't know why, this is a hypothetical, but fairly realistic > > situation, right? > > > > Discussing hypothetical issues leads nowhere, according to my experience. > Let's focus on actual issues. > > > > > Now, let's say function `logview-do-bla-bla-bla' cannot work with > > narrowed buffer (half of functions in Logview cannot). > > > > You said I'm not allowed to tell you that your code could do things > differently, but that doesn't mean it isn't true. It is for example > possible to parse the buffer outside of fontification-functions and to use > the result of that parsing inside fontification-functions. Yet another > method would be to use a simpler fontification method in buffers with too > long lines. Yet another method would be to turn font locking off in > buffers with too long lines. Yet another method would be to truncate too > long lines. I also cannot understand why it is necessary, in log files in > which all lines are independent, to move beyond the beginning and end of a > line to decide how it must be fontified. > > > > > Will I be able to lift locked narrowing restrictions without knowing the > > tag? > > > > This is akin to a security mechanism, there is no reason to make it > possible to turn it off "too easily". > --00000000000060672d05e8bf1e89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > I don't know why, this is a hypothetical, bu= t fairly realistic
> > situation, right?
>
> Discussi= ng hypothetical issues leads nowhere, according to my experience.
> L= et's focus on actual issues.

I have shown you a simple way how y= our supposed can break things. Yes,
it's not an everyday occurence, = but if I could think of one easily,
this or something else to this effec= t will be used in reality. As a
reminder, Emacs self-advertises itself a= s "advanced, extensible"
editor. You are making some extension= s illegal, because maybe
something somewhere might become slow. You are = sacrificing
functionality in the name of performance.

> It is = for example possible to parse the buffer outside of
> fontification-f= unctions

You are ignoring that this is not only about fontification.= It can
happen anywhere, because I may need full access to the buffer at= any
time.

> and to use the result of that parsing inside
&= gt; fontification-functions.

Parsing is done lazily. You are saying = I need to prepare parsing
results everywhere in the whole buffer at once= (which easily can be 10
MB - I have seen logs 250 MB in size, but not o= nes with lines longer
than ~50 K characters), because I don't know i= n advance where
fontification (or whatever else) might be needed.
> Yet another method would be to use a simpler fontification method in<= br>> buffers with too long lines.=C2=A0 Yet another method would be to t= urn
> font locking off in buffers with too long lines.

I don&#= 39;t want to lose fontification in a 10 MB buffer because one line
somew= here there is over 10000 characters.

> Yet another method would b= e to truncate too long lines.

Eh? And corrupt the log? Otherwise, ev= en if it is invisible it stays
in the buffer.

> I also cannot = understand why it is necessary, in log files in
> which all lines are= independent

No they are not. Typically Java exceptions are logged l= ike this:

=C2=A0 =C2=A0 2022-09-15 23:11:00.014 ERROR [some.Class] (= some-thread) bla-bla-bla
=C2=A0 =C2=A0 exception.Class: bla-bla-bla
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at some.Class

and so on. Exceptio= ns are not the only multiline entries.

I have already complained abo= ut this often-seen-here "I also cannot
understand", which impl= ies "therefore no-one will ever need", but you
said it was bad= attitude from me.

> > Will I be able to lift locked narr= owing restrictions without knowing the
> > tag?
>
> T= his is akin to a security mechanism, there is no reason to make it
> = possible to turn it off "too easily".

Security against wha= t, for fuck's sake? By trying to prevent "making
it too easily&= quot;, you are preventing this at all in general case. And
what are the = gains?

Paul

On Fri, 16 Sept 2022 at 00:16, Gregory Heytin= gs <gregory@heytings.org>= wrote:

>
> I don't know why, this is a hypothetical, but fairly realistic > situation, right?
>

Discussing hypothetical issues leads nowhere, according to my experience. <= br> Let's focus on actual issues.

>
> Now, let's say function `logview-do-bla-bla-bla' cannot work w= ith
> narrowed buffer (half of functions in Logview cannot).
>

You said I'm not allowed to tell you that your code could do things differently, but that doesn't mean it isn't true.=C2=A0 It is for e= xample
possible to parse the buffer outside of fontification-functions and to use =
the result of that parsing inside fontification-functions.=C2=A0 Yet anothe= r
method would be to use a simpler fontification method in buffers with too <= br> long lines.=C2=A0 Yet another method would be to turn font locking off in <= br> buffers with too long lines.=C2=A0 Yet another method would be to truncate = too
long lines.=C2=A0 I also cannot understand why it is necessary, in log file= s in
which all lines are independent, to move beyond the beginning and end of a =
line to decide how it must be fontified.

>
> Will I be able to lift locked narrowing restrictions without knowing t= he
> tag?
>

This is akin to a security mechanism, there is no reason to make it
possible to turn it off "too easily".
--00000000000060672d05e8bf1e89-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 19:13:38 2022 Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 23:13:38 +0000 Received: from localhost ([127.0.0.1]:59518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYy38-0002Tb-2L for submit@debbugs.gnu.org; Thu, 15 Sep 2022 19:13:38 -0400 Received: from heytings.org ([95.142.160.155]:43394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYy32-0002TP-Dr for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 19:13:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663283611; bh=fu5RvgNrS4WqN8gtpIa4/+2mbR0kfKkrFUAsgaApl2Q=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=WpeAej+ldkKr1Jku9J3q6Q/vczM+/i5jGWzkwjg7XlXLzRaBwdf644QnLO7AXVH+6 MjGATTW0xqW9NhHcyT6L5UqrRexcUlTrWkIBoKY82GYPf9uW0Oahs+mU4ChMIJxFjt anc8osE2j9Xjdp/TJtcfDXAmlo4y4NvvHsW+I3X9LR38u5ttYaP3fP901DnSzN4tsy wpBmKHFRGW8RYnW3mLt/J491QDZ8BQ1oAhk9K63NruWuT0eCLYK/HYHC0SktG394BM XFd9MMI5QZjLXw2mFIUHlV53APU32COvnlB/Ors1tzf/JksHAQx2q6DnfwUAQABsqF KI2vlOzKldA5A== Date: Thu, 15 Sep 2022 23:13:30 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: Message-ID: References: <834jx85tyv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="SdnpM173OW" Content-ID: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --SdnpM173OW Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: >> I also cannot understand why it is necessary, in log files in which all= =20 >> lines are independent >=20 > No they are not. Typically Java exceptions are logged like this: >=20 > =C2=A0 =C2=A0 2022-09-15 23:11:00.014 ERROR [some.Class] (some-thread) bl= a-bla-bla > =C2=A0 =C2=A0 exception.Class: bla-bla-bla > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at some.Class >=20 > and so on. Exceptions are not the only multiline entries. > Okay, but that still doesn't mean that you need to access the whole buffer= =20 at any time, does it? You do not need to go further than the beginning of= =20 the "2022-09-15 23:11:00.014 ERROR..." line, or am I missing something? > > I have already complained about this often-seen-here "I also cannot=20 > understand", which implies "therefore no-one will ever need" > No, that's not what it implies. It is a request for clarification. > > By trying to prevent "making it too easily", you are preventing this at= =20 > all in general case. > If it is possible to unlock a locked narrowing, and if it is possible to=20 disable locked narrowing completely, nothing is prevented. --SdnpM173OW-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 21:37:11 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 01:37:11 +0000 Received: from localhost ([127.0.0.1]:41051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ0I3-0000Y1-AN for submit@debbugs.gnu.org; Thu, 15 Sep 2022 21:37:11 -0400 Received: from mail-oi1-f180.google.com ([209.85.167.180]:39478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ0I0-0000Xn-HN for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 21:37:10 -0400 Received: by mail-oi1-f180.google.com with SMTP id m130so4446575oif.6 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 18:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date; bh=8Yj9etqNpFFW24jmMrQbtXllhDC29SY833kZsIOmOoU=; b=BMTdulb4e3tK1mK1PUThPV/ngSLQEKijPOLo68YfrSGDy3XU7xTRrZNWbidcpIR3QR QObIAOzTY21/g+arWuTWI4AT6KAg0Nj7uEYIAA5MSX9F6G15qihrl7V2QXtnv/iHIbck 7islhlyruEqGIA5QUiu1ZfBs1PofY7BlJpooVkPN02x71Se8J5QzAt+YAlOLNkv6+QQ+ H2tH/o68VXHuyfSU9FggpGBJ/hTz1LDDtABLM2bz2kKSsDA+l4Tx/gofiG3SjrV/coF0 byUvAO6+Zr2aMkOwzzODWXVpFp+gnBxCokXlDIK633n1fzDARvH38Od8zSrBXj4t/Be7 +R0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=8Yj9etqNpFFW24jmMrQbtXllhDC29SY833kZsIOmOoU=; b=W6l7NLBpLC4kf7fjIg6XtMThV8o/EjVsTf3KUk0eXaOlmmB11VeJ/0Hyqct/21E0W7 whz0kAYKjiGX0huVN+LcY65aJNnJOWDIdCnV+lJhBO78u1b4MrT0l0MFkWfAZr2Y8w9P dCNdt7vSOVSEy+TdLAlzcF8oWNfoJigqoO1y8ii7Nid2KkufcMLflY0SVOPEiQZImB+M wNwbSIyvpqCvgO/Y4g5sJ3XSeSBCht5Ti//VqK33FDAuZFjA8sOiCEW0PbS1FzwOA9NH Wp9aYR7h0/pq/FPS6kl57CEDekJoY4QHCmb/lDPAL4hwrM/b/j8AKug1hMaeYgzA3YSw BjJQ== X-Gm-Message-State: ACrzQf14YnLxvoIQrvSkYax0T3jlerOTRj1nW6R0fcxrwlsBV4/mpO7z UPq2CJOtUrOhiibmTPAp93GPgUYtv3c= X-Google-Smtp-Source: AMsMyM6xZGut+BBM8irU3G53jkBpNWz+BW9BkX2c2+lWE6ulmCqTYeXURTEu4lX+Kw3fxgZghiV3ZQ== X-Received: by 2002:a17:90b:164d:b0:202:69b3:1002 with SMTP id il13-20020a17090b164d00b0020269b31002mr2689072pjb.86.1663290965390; Thu, 15 Sep 2022 18:16:05 -0700 (PDT) Received: from localhost ([1.83.155.65]) by smtp.gmail.com with ESMTPSA id b6-20020a170903228600b0017693bb573bsm13614395plh.219.2022.09.15.18.16.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Sep 2022 18:16:04 -0700 (PDT) From: Ihor Radchenko To: Gregory Heytings Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> Date: Fri, 16 Sep 2022 09:17:00 +0800 Message-ID: <87bkrgunhv.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 57804 Cc: Lars Ingebrigtsen , Eli Zaretskii , 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Gregory Heytings writes: >> Depending on the mode being activated before Emacs decides to enable the >> optimization (e.g. because one of the first lines is very long, I don't >> know how exactly this is determined) seems very shaky. > > Indeed. As I told you the proper fix is not to disable these > optimizations, but to adapt the code to handle locked narrowing, by > explicitly unlocking the locked narrowing when, and only when, it needs to > access a larger portion of the buffer. I would like to point out that some fontification code may use functions not specifically designed for the fontification. Moreover, the functions used by fontification may depend on user-defined hooks that can potentially contain unsuspecting (widen) calls. While I understand why locked narrowing is needed in buffers with large files, I would find it helpful if Emacs could throw some kind of warning when widen is called from inside locked narrowing. It will, at least, help with adapting the existing fontification code in the new Emacs versions. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92 From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 00:28:01 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 04:28:01 +0000 Received: from localhost ([127.0.0.1]:41126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ2xK-0006sV-8C for submit@debbugs.gnu.org; Fri, 16 Sep 2022 00:28:00 -0400 Received: from mail-qv1-f48.google.com ([209.85.219.48]:41570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxE9-00018a-9P for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 18:20:57 -0400 Received: by mail-qv1-f48.google.com with SMTP id l14so6880669qvq.8 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 15:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date; bh=9SvL0s3G3DZQ6jIQxv8Kquie4XhzyN1c/E51Xtm2c5o=; b=MqXkUMhdwMaFegvBWcw7sI29wF8voykln0eMaWZzZHG+D0CU+uejrVW3MbdvPyYxxQ ANpkEEJmVxq3UWcNPizEzkm7H3HadONiJDAUOrpPi3qMc7zUR8llOu+R7QwaoRCqrn5I oI1QVgEKxe0rXSl3FpsT6wM9o9EA95nn9c4l8TsDs37EHjvdZcDOrSYMnaepKVckDMNn FgAQpdELT0YKxsnODdgWYThYvcjILb+wuQsh+ibknMl5yMs6X7MogSCrjlJIQL3FZiev 99zmzfk5szYQiqZPaM3+i33SmVUXLKU62iL7iIAzBPvpx3KXyu15qjattzSc0FZMkOTq aD3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date; bh=9SvL0s3G3DZQ6jIQxv8Kquie4XhzyN1c/E51Xtm2c5o=; b=FuLnjrFm/pJWfHg+hOlUjM/CV2BTSCl793Wl7eq1qtr08YWPelvNJP1OWzQdoXR8Sp 25OzZRiQ8b2WCF35SRtICP9Sl47V6RSuoasWMwWN7cV4IoLM93w5EUnBOAtiP+/7k6pK VK5q/MvHbbpquY7xtCHoBH0Btg5Ju1TY/NNH1826yebZlcyW164GrEbCg1cyTUqfzZ4S /zaNFbgwQ/xN0QmKylUKgDrwxc6vrwXWke34jsn6oz+aDTeTHQezlfCYkzPaTYn9QJGB zJ3z4VSfYQZhbMlzDB3gYfS5Y9cYfKgVQQy7oo5tPpLNs+5DIRTN7z1w2Ob9b/FY5Bw4 g6nw== X-Gm-Message-State: ACrzQf1e/fK5EgZAOr4CyqbgHoIN8/MJv1i7dXn8mcCPxgxyQl0hUHle m9rJdZBTQldumkfbYjLWQv0= X-Google-Smtp-Source: AMsMyM44AImv6pRJUlSdCbi4t57I6RPNCI0DOuM17j/XJC1PF1IdZLgifIPAYVZNCH7HJhQ+/pyhIA== X-Received: by 2002:a05:6214:1c07:b0:4a4:bf44:df79 with SMTP id u7-20020a0562141c0700b004a4bf44df79mr1629823qvc.1.1663280450582; Thu, 15 Sep 2022 15:20:50 -0700 (PDT) Received: from localhost (pool-173-56-234-28.nycmny.fios.verizon.net. [173.56.234.28]) by smtp.gmail.com with ESMTPSA id bp12-20020a05620a458c00b006bb619a6a85sm4778182qkb.48.2022.09.15.15.20.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Sep 2022 15:20:50 -0700 (PDT) From: dick To: Gregory Heytings Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: (Gregory Heytings's message of "Thu, 15 Sep 2022 19:44:30 +0000") References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> Date: Thu, 15 Sep 2022 18:20:49 -0400 Message-ID: <87y1uki8ji.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14) Commercial/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57804 X-Mailman-Approved-At: Fri, 16 Sep 2022 00:27:55 -0400 Cc: 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) GH> the general fix will be to adapt Logview to handle locked narrowing I wonder what kind of person is so idle, recalcitrant, and obnoxious that he has all day to work on a private fork of emacs, refuses to upstream his changes, all the while insulting the community. Ah, that would be I. I also wonder however, what kind of person becomes so triggered by a YouTube video about long lines, dedicates innumerable hours to implementing and shepherding a fix, amplifies the exceptions to a competing heuristic, but blithely dismisses exceptions to his own heuristic ("I bet we'll never get a bug report about that," "Don't worry, that won't happen"), who also dismisses hard performance metrics by claiming unrealistic usage patterns, who then when presented with a real-world failure suggests the aggrieved module ought to accommodate his long lines fix, and goes so far as to characterize that accommodation as "a general fix." Generally, I wonder what it is about emacs that brings out not just the worst developers, but also the worst people. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 01:35:27 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 05:35:27 +0000 Received: from localhost ([127.0.0.1]:41217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ40c-0000Pn-Ct for submit@debbugs.gnu.org; Fri, 16 Sep 2022 01:35:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ40Z-0000PY-8r for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 01:35:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ40T-0006aW-Q0; Fri, 16 Sep 2022 01:35:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fJrqRvqFUTOPAjUWSBayuFmTE2kUb+yeCKO+sCL7Oj8=; b=fLgkN1lQHTI0 Q5vzrCPvwwgzWk6mJIMSOfG5qW9eFJpuhVbZ4ZaiBOf6zQnUnv0PCZl5yh2QoDCKW7Msz+sFqeRWf P5AhkKsvD8Q6KWEMNkbRP3E7kxUxGXodrHmRRJVOX1ePH/X6owqFOetjiYLmYxAA1SHqjCjAQqcdc 9jA8bnmhgtSHEQATD3gmEzc+T8EZeVuF+N/aom8Q6OFKYul0IdAlboAP5GX/Rq6XENqO6LsDABq3t a2uxvB/nAhkSnuE6/4X51rDxZzTGNaDTbDdjO3RtKPnWzrDnxuK+4HuVYPYjhY2zGcn2aFx/sQVUD nTIgqyb1L6o9ywfcNL5+Jw==; Received: from [87.69.77.57] (port=1101 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 1oZ40S-0007kO-Uz; Fri, 16 Sep 2022 01:35:17 -0400 Date: Fri, 16 Sep 2022 08:35:10 +0300 Message-Id: <83zgez51bl.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (message from Gregory Heytings on Thu, 15 Sep 2022 20:18:27 +0000) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: larsi@gnus.org, 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 15 Sep 2022 20:18:27 +0000 > From: Gregory Heytings > cc: Eli Zaretskii , 57804@debbugs.gnu.org, > Lars Ingebrigtsen > > > I see that manually evaluating `(setq-local long-line-threshold nil)' in > > a buffer where the optimization is already in effect (i.e. where > > `(long-line-optimizations-p)' evaluates to t) doesn't disable the > > optimization. Do you have a solution for that? > > No, and that will not be supported. I don't necessarily agree. We didn't see the need for this yet, but if we do find significant use cases where that could be important, we will consider adding something, like perhaps re-evaluation of the optimization flag under some circumstances. For example, changing the value of long-line-threshold could be one such trigger. But for now we don't see a need for that, and prefer that Lisp programs that run via fontification-functions will be adapted to this new protocol. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 01:37:33 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 05:37:33 +0000 Received: from localhost ([127.0.0.1]:41222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ42e-0000Sr-8N for submit@debbugs.gnu.org; Fri, 16 Sep 2022 01:37:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ42b-0000Se-MD for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 01:37:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32816) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ42W-0007m4-FK; Fri, 16 Sep 2022 01:37:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6m2ZPwbs/FpuxjI/h3bBMhIlmEr4hnuBLV2JKniXUNk=; b=b4Chkdjnktgf d0OW3IFDKRR4t90tmYH7aKZ0/Mm2LCTvS0qCHYvTkODeQFYPrVRKv7O6UEfpCFFiMquEUYyGd5WZi HhMyqT/rBx/ZtH06ZFqdqqLZcHQoqm9qhoxYdLMq4ghIDWLMBLC1mlbLIaZuCQA1nMbtur2WJkJTi iOEDaNuWnK9VIVWhFavp18PY3Adfg8qh7C2A7GdrY7QYfPWdyRAD4EoOd9l/bAGW7Ggp3T9MVtvQ3 pTfE6VWPh8iSVlXmbDc8iAxkfEikOhWfh4OS+svu8m0CPT07p8s93MypfMsBeYbNST40uZektm8aN E/8ZVWtC8cY3F2T6cOW1Tg==; Received: from [87.69.77.57] (port=1229 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 1oZ42U-0005Vt-LJ; Fri, 16 Sep 2022 01:37:24 -0400 Date: Fri, 16 Sep 2022 08:37:16 +0300 Message-Id: <83y1uj5183.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (message from Gregory Heytings on Thu, 15 Sep 2022 20:26:54 +0000) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: larsi@gnus.org, 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org > Date: Thu, 15 Sep 2022 20:26:54 +0000 > From: Gregory Heytings > > > 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. > > It isn't for me personally, no. It is important for Emacs users. Indeed, the complaints about Emacs behavior with very long lines are abundantly seen on the Internet and in our bug database. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 02:20:07 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 06:20:07 +0000 Received: from localhost ([127.0.0.1]:41283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ4hr-0001YR-FV for submit@debbugs.gnu.org; Fri, 16 Sep 2022 02:20:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ4hp-0001Xq-3n for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 02:20:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59264) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ4hj-0003V2-LB; Fri, 16 Sep 2022 02:19:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3uaL+95JviAwGeuNWo8dST4LQfvylxV+aVf4bV70P8o=; b=V7nUYWpe+27s gPJ+nVWuUyWjQQ7Ew1U4lHTO9l0iVlEEx1fYrHFeU3ap1MMe2mB3aOz54o3imLME7IkaIv59Y6kQV 7sIHNMpErN9j7dofp24JHNY6YjNPNpSPJVW5oNTsZjZmwsLDUSIT/G1cJMailoVzJmOfgeQHHBamW VrRq5cBmyx70QY7CT403GzmATcOCk4wiLr/NL7uU5Pca0N2lVk+9Gr+GK/QqAZTTAK7+1+03eIin1 8VMcaVdj6C+SVOCLi4VT84YLWnZM6Rb33oQTPQKxf+cMjyCj3uZfdnxVy+4d6cynNb62UnQ7qpCrc ftk+v9+BB/LFKshChOkbzA==; Received: from [87.69.77.57] (port=3848 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 1oZ4hh-0007s9-Ui; Fri, 16 Sep 2022 02:19:59 -0400 Date: Fri, 16 Sep 2022 09:19:52 +0300 Message-Id: <83pmfv4z93.fsf@gnu.org> From: Eli Zaretskii To: dick In-Reply-To: <87y1uki8ji.fsf@dick> (message from dick on Thu, 15 Sep 2022 18:20:49 -0400) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <87y1uki8ji.fsf@dick> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: gregory@heytings.org, 57804@debbugs.gnu.org, pogonyshev@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 57804@debbugs.gnu.org, Paul Pogonyshev > From: dick > Date: Thu, 15 Sep 2022 18:20:49 -0400 > > Generally, I wonder what it is about emacs that brings out not just the > worst developers, but also the worst people. This message has exactly zero content related to this bug report, it is all about offending other people. You are dangerously close to being banned from this forum as well. Consider this your last warning. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 02:32:07 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 06:32:07 +0000 Received: from localhost ([127.0.0.1]:41290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ4tS-0001s2-Na for submit@debbugs.gnu.org; Fri, 16 Sep 2022 02:32:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ4tP-0001rX-5q for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 02:32:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41764) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ4tJ-0000Bc-2a; Fri, 16 Sep 2022 02:31:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4Bc0vXV4zzqNLFQdAHbrG/NWAlLuPEToQHRdMokrlVA=; b=E9z4+9cMhnEi d3H7DLwdyS6DL3+VxlTmIMD85ouQs+G09pbu8UibQza+QjS60K05oUvwYLZUkGIGCL1MBOodH16I2 fmwOY4YhDXVLMKv6V+lFd2p3fmzWbwxLSf1wnszvtnzOMYywrrEcLOl44hH6LwmrgsjYGkIkLwcao eQ+KgJIv7pz7//BPa27DZ6ICj0nQOZ42jYDVVCff7G7H5Q5BjXSvDA7oYoSfVvVdFAPi5VEd3XQ8c VhwplUUCHeecO2aXtXZzWDk/nH1zx6YQsYOsI8z9C8LQZReTt2gzlSbQAFxrtewkOoEQKivlhgVsK eAidepHfcJcyixAPFbxm/A==; Received: from [87.69.77.57] (port=4578 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 1oZ4tG-0000ne-MO; Fri, 16 Sep 2022 02:31:55 -0400 Date: Fri, 16 Sep 2022 09:31:47 +0300 Message-Id: <83o7vf4yp8.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Thu, 15 Sep 2022 22:40:24 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: gregory@heytings.org, 57804@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Pogonyshev > Date: Thu, 15 Sep 2022 22:40:24 +0200 > Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen > > It is impossible to correctly fontify log buffers if you are > restricted to semi-arbitrary parts of it: you need to at least see > where the current entry starts, even if it for whatever reason > includes a line with 100 K characters. In buffers with very long lines, fontifications are supposed and requested to simplify their act so as not to need access to arbitrary portions of the buffer outside the restriction. If such simplification is for some reason impossible or impractical, then the code called from fontification-functions should at least be amended not to produce infloops when its calls to 'widen' don't widen. This is all part of solving a long-standing problem in Emacs with becoming completely unresponsive when displaying buffers with very long lines. It is understood and accepted that in some cases this will come at a price of less accurate fontifications or minor glitches in other features. > > It isn't for me personally, no. It is important for Emacs users. > > How about letting Emacs users decide for themselves? The users already can decide for themselves: they can set the long-line-threshold variable to larger values or even to nil. > Let Logview > behave against your recommendations. And then, when the users discover > how crappy and unresponsive it is, as a result, compared to everything > else, they will just uninstall the package and use something better. We expect package developers to cooperate with our effort of making Emacs responsive and reasonably functional in buffers with very long lines. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 02:41:07 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 06:41:07 +0000 Received: from localhost ([127.0.0.1]:41309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ52A-000262-Mh for submit@debbugs.gnu.org; Fri, 16 Sep 2022 02:41:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ527-00025P-2o for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 02:41:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50594) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ521-0002DB-Nz; Fri, 16 Sep 2022 02:40:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2F/MpNvnPj55ygUKsGIAIbXCz16mYtIRfJOyQvsAi74=; b=jR1bdXLmoiKf k0EaC/Q1UMEGz6E5qjKPQcvpl63zUjmaePXMTl/XZh5kLMatOQYjA/kzgpvMdDbg8WWk9S9yFDsZK Bn7W5PeIxZfkRrkr7RlM48ktJXmNObWr9QJ0WVDzvJPi9kv713YBmWYlRNJvp85L/YVY1Wp68UuiW TfARR4FXiky6XJOWNqY8PTbq9Viva332BrDH25CsYme5oGrY/2acq9fokUHf6up8Bg3lfQ7mMFmY1 kqXuQZ0ea1gPYbsQZGi/+PVUc6TP/NKjsR8HHqBArIvAF0FjJqVwCyxxXphuzn7LATU31l5FK7UJg gmwQxocrDbTSYMR3BqyIGg==; Received: from [87.69.77.57] (port=1157 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 1oZ521-00011Y-6R; Fri, 16 Sep 2022 02:40:57 -0400 Date: Fri, 16 Sep 2022 09:40:50 +0300 Message-Id: <83mtaz4ya5.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Fri, 16 Sep 2022 00:53:37 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: gregory@heytings.org, 57804@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Pogonyshev > Date: Fri, 16 Sep 2022 00:53:37 +0200 > Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen > > > It is for example possible to parse the buffer outside of > > fontification-functions > > You are ignoring that this is not only about fontification. It can > happen anywhere, because I may need full access to the buffer at any > time. Your mode is requested to be able to run in some kind of "simplified mode" when long-line-threshold is exceeded, in a way that doesn't require such full access. > > Yet another method would be to use a simpler fontification method in > > buffers with too long lines. Yet another method would be to turn > > font locking off in buffers with too long lines. > > I don't want to lose fontification in a 10 MB buffer because one line > somewhere there is over 10000 characters. The locked restriction leaves accessible a region of the buffer that is quite large. So if you are fontifying a line that is not very long in such a buffer, you should still be able to access enough text before and after the window to be able to fontify. It is expected that modes which need to access more than that will be amended to perform, perhaps sub-optimally, in such cases. In extreme cases, you can simply not fontify if there's no reasonable way of fontifying even approximately. (I don't believe such extreme measures should be necessary, but they are a possibility.) IOW, we fully expect that in some cases and with some features, there will be partial loss of functionality in these cases. We consider that still much better than a locked-up Emacs that can only be killed. > Security against what, for fuck's sake? Language! From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 03:44:25 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 07:44:25 +0000 Received: from localhost ([127.0.0.1]:41526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ61R-0003qH-GT for submit@debbugs.gnu.org; Fri, 16 Sep 2022 03:44:25 -0400 Received: from mail-ej1-f42.google.com ([209.85.218.42]:37576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ61L-0003q0-JW for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 03:44:24 -0400 Received: by mail-ej1-f42.google.com with SMTP id a26so18814326ejc.4 for <57804@debbugs.gnu.org>; Fri, 16 Sep 2022 00:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date; bh=HI8I+tKNx8u2zh83RpO3FnjHScNGnoNzxYaNBebi7bs=; b=PdLY/YNBb5N5snXIf/GAn9HpFtTOLPEZVOFsNdvnm3sEp82SMnSLpAJfW1HXWkbAum k1q1gowu1pow2PklMLr06htlMxJvNoVSgxmzWbSCMgdLxvRIdGizouZ9NmgaT4Qj6ZtX ZCXwbHHqEIwP4zGSa74Z2aG9IEi+jqQliKgYEAyD8L7ZAyRO0NMuODZ5ChDp6x+R7HZe wPeZlstXGHDT2y8WDdazFslY2LOKQEth15E/S/Vd2K+tOJARrHbC84wkclaYUzS/Q7CL 0+MnNKuwcYoNga0JYAk/VHEu/IyT4WO1HViLyLSgKYKgc9mOlarv4oyANqhrOLjYAxGP dxLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date; bh=HI8I+tKNx8u2zh83RpO3FnjHScNGnoNzxYaNBebi7bs=; b=rxbt+BStY/Zg8DfsCLh70W9jGwiqfq6PYZuE5cYoKFrHGuV6sWRXt7m7Sw/4k9d4Au SzVxrHVBpLG8SQ7N/hIkq14WIsKQzaibDJ91+gYhWE/HAH3u9BLaUr0OlNe9llM91rit z4VdcAbHOoqPZfSthnw7HOF416ua1CkgGJkRhBIy+pIeJz0tRvPFPuvrqcTDLBB98K4Q QtqorQ2eTS+89KPcmKjzHA5PTNQTTqQfAt49bvrJu5A6C3UdKWkDgyUWQ8GOaU+VpyAW sWVuezitIuDIFhDAqybVQVs7quGeALU7Ng2LnUAyA5e0h5s1sW132ZUTP5ZRH4vuw817 7NbQ== X-Gm-Message-State: ACrzQf2ZmRvQr+pMS2QkwUbH7pJoOlhDV4JvTUGXSrZciaj2lieE7OXy MWir+Eh97XwL8IMjObPebFw= X-Google-Smtp-Source: AMsMyM4vA+zjBj4fQJtf8uevSe/BmMLYbc73bOl84FWS4Tr9/pc83x/6gUElmda42UV/OoCk0G8XDQ== X-Received: by 2002:a17:906:cc58:b0:76f:c119:acb5 with SMTP id mm24-20020a170906cc5800b0076fc119acb5mr2548983ejb.651.1663314253636; Fri, 16 Sep 2022 00:44:13 -0700 (PDT) Received: from Mini.fritz.box (pd9e36af3.dip0.t-ipconnect.de. [217.227.106.243]) by smtp.gmail.com with ESMTPSA id i22-20020aa7c716000000b0043d1eff72b3sm13051347edq.74.2022.09.16.00.44.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Sep 2022 00:44:13 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: dick Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely In-Reply-To: <87y1uki8ji.fsf@dick> (dick's message of "Thu, 15 Sep 2022 18:20:49 -0400") References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <87y1uki8ji.fsf@dick> Date: Fri, 16 Sep 2022 09:44:11 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Gregory Heytings , 57804@debbugs.gnu.org, Paul Pogonyshev X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) dick writes: > Generally, I wonder what it is about emacs that brings out not just the > worst developers, but also the worst people. I can only talk about me, but for me it is that I'm a masochist. I really like to be vistimized, that makes things so much easier. But that's just me, of course :-). From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 06:09:20 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 10:09:20 +0000 Received: from localhost ([127.0.0.1]:41771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ8Hg-0003bR-FR for submit@debbugs.gnu.org; Fri, 16 Sep 2022 06:09:20 -0400 Received: from mail-ot1-f47.google.com ([209.85.210.47]:45973) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ8HT-0003aq-IY for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 06:09:19 -0400 Received: by mail-ot1-f47.google.com with SMTP id ck2-20020a056830648200b0065603aef276so9073399otb.12 for <57804@debbugs.gnu.org>; Fri, 16 Sep 2022 03:09:07 -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=QpoUcYvgHH2iwW2stExvD/Zi3tv8gP57v46U+Ymp4ic=; b=aUZ4gKOpId2LDcWR3oSKsSH8cDD3FsAoB1SUQOezFHrVmD7xvCw/fNP+l0wTDFeB5x 69/4u2lD0q52H1AWzgwaTGnOYVLrmOcaPPLk6guEEyDdXHkUwu+wmyi576g3/7fMTMpV XkLYLjjEJQQWBoT/cQOByhRRU7glrSQkEqPR1fewhkaSb/C5tIl20c8Y66esqKiW+oB+ pS0K0sc4NGI0iYrMDBArGgAHrh7Yif0FtBoaH93h+VMbAIKp5QrW7/We9T/1IVkjfAQF ixa3CnkGqq703pNBkeQJbyaYytKDdFNBCT/ec5k35O2caQmEv0O8aKpvKZSMNLt+d9dU boUQ== 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=QpoUcYvgHH2iwW2stExvD/Zi3tv8gP57v46U+Ymp4ic=; b=Bh0/8FNnQRr6c43Mu50+6DFt5OF57554jjB9AIiuB1xoWQQMRqYOzpnjZpwB/BrytC MgxEpqGhQVCLhnFvmn4ojAQpQ2EZKYt0WOx9zGrksl2twsz5qLIB8IqARJgKTcX3e6Ew QgBVywDnuFRgY6qIJIqCPvUjMPv6rcihe+58P4AnhJOH32ACsm8+4Cz/xIfO2O2Nd9Db bLQiWf1xkOtRDW7wM6cGvHuZZzQKXJpnj5BEMdXRwKM2lxIMtbxQgV2LABPQQD7B2wu5 IIGZz4ocuuhhqoxCsS3goayqDDc3S+acbvziKVoaDAcSt3jYuXRrvuEogGW/jQRGjV5p S1tQ== X-Gm-Message-State: ACrzQf1Emy7eo4SEL2CdhfbxkLhsF+YJLLt00La1zOttu8k1DGvpkSdU r7pn6h3YFaTwOWZ4n8tbRkUc5VQ+uhpJNINCGQ== X-Google-Smtp-Source: AMsMyM6qAiibOtRNCslq6z0o01yhkzEjzBi18p4DfTgn0qxTshQq0xc5oajid8gIdz/7WIe7S/sDjtuhAIEeXkLsRY8= X-Received: by 2002:a9d:2c3:0:b0:638:d57d:2250 with SMTP id 61-20020a9d02c3000000b00638d57d2250mr1881479otl.143.1663322942018; Fri, 16 Sep 2022 03:09:02 -0700 (PDT) MIME-Version: 1.0 References: <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> <83mtaz4ya5.fsf@gnu.org> In-Reply-To: <83mtaz4ya5.fsf@gnu.org> From: Paul Pogonyshev Date: Fri, 16 Sep 2022 12:08:49 +0200 Message-ID: Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000001b189305e8c88d35" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 57804 Cc: Gregory Heytings , 57804@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000001b189305e8c88d35 Content-Type: text/plain; charset="UTF-8" I give up. Do as you like. Paul On Fri, 16 Sept 2022 at 08:40, Eli Zaretskii wrote: > > From: Paul Pogonyshev > > Date: Fri, 16 Sep 2022 00:53:37 +0200 > > Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars > Ingebrigtsen > > > > > It is for example possible to parse the buffer outside of > > > fontification-functions > > > > You are ignoring that this is not only about fontification. It can > > happen anywhere, because I may need full access to the buffer at any > > time. > > Your mode is requested to be able to run in some kind of "simplified > mode" when long-line-threshold is exceeded, in a way that doesn't > require such full access. > > > > Yet another method would be to use a simpler fontification method in > > > buffers with too long lines. Yet another method would be to turn > > > font locking off in buffers with too long lines. > > > > I don't want to lose fontification in a 10 MB buffer because one line > > somewhere there is over 10000 characters. > > The locked restriction leaves accessible a region of the buffer that > is quite large. So if you are fontifying a line that is not very long > in such a buffer, you should still be able to access enough text > before and after the window to be able to fontify. It is expected > that modes which need to access more than that will be amended to > perform, perhaps sub-optimally, in such cases. In extreme cases, you > can simply not fontify if there's no reasonable way of fontifying even > approximately. (I don't believe such extreme measures should be > necessary, but they are a possibility.) > > IOW, we fully expect that in some cases and with some features, there > will be partial loss of functionality in these cases. We consider > that still much better than a locked-up Emacs that can only be killed. > > > Security against what, for fuck's sake? > > Language! > --0000000000001b189305e8c88d35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I give up. Do as you like.

Paul

On= Fri, 16 Sept 2022 at 08:40, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Date: Fri, 16 Sep 2022 00:53:37 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 57804@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
>
> > It is for example possible to parse the buffer outside of
> > fontification-functions
>
> You are ignoring that this is not only about fontification. It can
> happen anywhere, because I may need full access to the buffer at any > time.

Your mode is requested to be able to run in some kind of "simplified mode" when long-line-threshold is exceeded, in a way that doesn't<= br> require such full access.

> > Yet another method would be to use a simpler fontification method= in
> > buffers with too long lines.=C2=A0 Yet another method would be to= turn
> > font locking off in buffers with too long lines.
>
> I don't want to lose fontification in a 10 MB buffer because one l= ine
> somewhere there is over 10000 characters.

The locked restriction leaves accessible a region of the buffer that
is quite large.=C2=A0 So if you are fontifying a line that is not very long=
in such a buffer, you should still be able to access enough text
before and after the window to be able to fontify.=C2=A0 It is expected
that modes which need to access more than that will be amended to
perform, perhaps sub-optimally, in such cases.=C2=A0 In extreme cases, you<= br> can simply not fontify if there's no reasonable way of fontifying even<= br> approximately.=C2=A0 (I don't believe such extreme measures should be necessary, but they are a possibility.)

IOW, we fully expect that in some cases and with some features, there
will be partial loss of functionality in these cases.=C2=A0 We consider
that still much better than a locked-up Emacs that can only be killed.

> Security against what, for fuck's sake?

Language!
--0000000000001b189305e8c88d35-- From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 06:44:47 2022 Received: (at 57804) by debbugs.gnu.org; 16 Sep 2022 10:44:47 +0000 Received: from localhost ([127.0.0.1]:41863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ8py-0006sy-PL for submit@debbugs.gnu.org; Fri, 16 Sep 2022 06:44:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ8px-0006se-9c for 57804@debbugs.gnu.org; Fri, 16 Sep 2022 06:44:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34116) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ8ps-0004rx-2a; Fri, 16 Sep 2022 06:44:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tAoW2iVC8klMCptkPEvIzjSAljylX80Saho33XXOhXw=; b=Kj9ovqGhXY6c IVHjEY8yJQudh6DPCB+tJluL2DJwbJDvsM1Q3vFXpj6LlxCNY+H5qci5TdBSkQ5vdd2wSf+k+Sqfa epr3pvEi866eoZie7ZVVChc9x8AZwIKzBfT2o6cToG7sdq54CDKFgBtxRvi+o98YBwCc1awwe3Xv/ TXfwMv16UwLEcKXxxPYogkvBS+DDT+3QFGhtaUzWZ3RvxQlHxeg/B+Wd7cP7yTbyXAxVxxm1lUWg9 2DSKIzkfLaQviaPDH9My+5Nn9duS9CjRVjmEwBde8QS+9rQTzmcn7XbHFDYYAIijk9W5t0gW/g4zU zpF+M+DFyhmCH++o0f8JjA==; Received: from [87.69.77.57] (port=4098 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 1oZ8pr-0001RA-Hp; Fri, 16 Sep 2022 06:44:39 -0400 Date: Fri, 16 Sep 2022 13:44:33 +0300 Message-Id: <83czbv4mzy.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Fri, 16 Sep 2022 12:08:49 +0200) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> <83mtaz4ya5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: gregory@heytings.org, 57804@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Pogonyshev > Date: Fri, 16 Sep 2022 12:08:49 +0200 > Cc: Gregory Heytings , 57804@debbugs.gnu.org, > Lars Ingebrigtsen > > I give up. Do as you like. That's unfortunate, because we hope to see maintainers of 3rd-party modes sympathetic to this effort of making Emacs capable of coping with very long lines, and cooperate with us in adapting their modes to the core mechanisms that deal with these situations. From unknown Thu Aug 14 21:50:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 14 Oct 2022 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 12:37:27 2022 Received: (at control) by debbugs.gnu.org; 28 Nov 2022 17:37:27 +0000 Received: from localhost ([127.0.0.1]:49927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozi4N-0006bI-C0 for submit@debbugs.gnu.org; Mon, 28 Nov 2022 12:37:27 -0500 Received: from heytings.org ([95.142.160.155]:35106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozi4L-0006bC-Nw for control@debbugs.gnu.org; Mon, 28 Nov 2022 12:37:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1669657045; bh=tYgqwXaOcthsSxPNAKyHZlrFYJuEw15a/C8RTsWxhnw=; h=Date:From:To:Message-ID:From; b=pXxzMWg4yoxpv8ATATIQVc/JTrhA2VgsBfF6nKvwQeHLNvHmT5aIJite8m7lcJVzI Chs9NgUArqy4SCmqNQIF9sH5xc7tJ6hJ42+HGzCGHyL49c3Pp+L8TprZ6m1rD4rQj1 JBJt5RbiRk1LHt7b96BhCQezk7UOSgO8n1rJ1s1mMqiACX6SnJYadN6QdkLioy97Oc g1xCtz5rwxEKgTq9q7zXvODXrXQq/H+kz6UQ+3VWLo+yiFeCtX4NZGoLm+yKkf9NsM aQCiqxaL4Ut4BxtCL76sn2YFhjrB32K1Kt1yh46FzX1hajdWSRWShi+rtF1Wy8hTCR wqC1yBW3VBjzA== Date: Mon, 28 Nov 2022 17:37:24 +0000 From: Gregory Heytings To: control@debbugs.gnu.org Message-ID: <338f50d4217d7ba33f25@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: unarchive 57804 Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) unarchive 57804 From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 13:32:19 2022 Received: (at 57804) by debbugs.gnu.org; 28 Nov 2022 18:32:19 +0000 Received: from localhost ([127.0.0.1]:50214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozivS-0000yf-Vl for submit@debbugs.gnu.org; Mon, 28 Nov 2022 13:32:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozivR-0000yZ-3H for 57804@debbugs.gnu.org; Mon, 28 Nov 2022 13:32:17 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozivL-0008IU-3y; Mon, 28 Nov 2022 13:32:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZTB9W/s5yBjYjC78b9l1RNhgIWnD++TgEHZH/vo5a+E=; b=JSo0lCYC4ErQ KFR6NPXD1EIQhnbd6/rl5iS7EjaXuxHykOnxGgkue3ZpbrqrYoNXeJ6temgG06CFl9yIdU2vDZNw+ ChQWgOZyeKig7NoGOoOwBiOZ8hKUDrllb1xyY3KrMjWOO/AMLJrIn/0My2771WQIdV+ioCR7m3aqz QW2VXRw/uDO60lPv78FF/dsmR9v8Z5nQgy6/+GL9lqq8eTM9JopgCWVklpu0bZqGKuiBh1b3+D7DG FGjHdS6rj9iUAVLxyYJZFx8tlEAKqi4D/AX8vI5aptRNfs7Ekx2UJyiwFSaW2+r9+qaSJ4Ab7dInn uKOQSEz8jIbMdzOrEyIiVg==; Received: from [87.69.77.57] (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 1ozivI-0002vR-SN; Mon, 28 Nov 2022 13:32:10 -0500 Date: Mon, 28 Nov 2022 20:32:39 +0200 Message-Id: <83v8mzlyk8.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <338f50d421b672315145@heytings.org> (message from Gregory Heytings on Mon, 28 Nov 2022 17:35:35 +0000) Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely References: <834jx85tyv.fsf@gnu.org> <83o7vf4yp8.fsf@gnu.org> <1260fd38-d4b3-5ca1-5b15-78f59c0255b6@yandex.ru> <83o7t9k8fr.fsf@gnu.org> <34e17bf2a6bdd269fba7@heytings.org> <338f50d421074805735f@heytings.org> <831qpnngeg.fsf@gnu.org> <338f50d421b672315145@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57804 Cc: larsi@gnus.org, 57804@debbugs.gnu.org, pogonyshev@gmail.com, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 28 Nov 2022 17:35:35 +0000 > From: Gregory Heytings > cc: pogonyshev@gmail.com, dgutov@yandex.ru, 57804@debbugs.gnu.org, > larsi@gnus.org > > By the way, can you tell me what "in due time" means? It means "before > Emacs 29 is released", which will happen only in a couple of months, > right? If I need to do this, I planned on doing it in the next week or two. I don't think we should wait much longer, because these instructions need to be subject to the release-cycle testing together with Emacs itself. > The background of that question is that I'd like to explore a few > things in that area before writing the NEWS entry. If you have considerable doubt what to write, it is fine to wait a bit longer than a week or two. But please also consider writing soon what we know now and later augmenting it given the experience and the feedback. I would definitely like to see this out in the open as soon as we practically can. TIA From unknown Thu Aug 14 21:50:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 27 Dec 2022 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator