From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely Date: Thu, 15 Sep 2022 20:18:27 +0000 Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k4TTPbanAd" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4621"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen To: Paul Pogonyshev Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 15 22:19:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYvKI-00010J-FG for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 22:19:10 +0200 Original-Received: from localhost ([::1]:53602 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYvKH-0004iJ-Cf for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 16:19:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39288) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYvKB-0004hl-Ft for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:19:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42357) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYvKB-0003yl-7g for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:19:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYvKB-0004Oz-1H for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:19:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Sep 2022 20:19:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57804 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 57804-submit@debbugs.gnu.org id=B57804.166327311416876 (code B ref 57804); Thu, 15 Sep 2022 20:19:03 +0000 Original-Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:18:34 +0000 Original-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 Original-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== In-Reply-To: Content-ID: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242645 Archived-At: --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--