From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling) Date: Sun, 21 Aug 2022 15:02:18 +0300 Message-ID: <83fshpdctx.fsf@gnu.org> References: <87bksmx1j1.fsf@localhost> <8335dxiu6m.fsf@gnu.org> <87y1vnjgmn.fsf@gnus.org> <83y1vncbq5.fsf@gnu.org> <87r11fgi7h.fsf@gnus.org> <83sflvc85y.fsf@gnu.org> <87h729902w.fsf@gnus.org> <83edxdbs96.fsf@gnu.org> <87wnb5wthm.fsf@gnus.org> <83pmgxfyc7.fsf@gnu.org> <87fshtwsys.fsf@gnus.org> <877d35wsdd.fsf@gnus.org> <83ilmpfwrf.fsf@gnu.org> <8735dtwrar.fsf@gnus.org> <83h729ft60.fsf@gnu.org> <87tu68v3uu.fsf@gnus.org> <83tu68e83u.fsf@gnu.org> <87fshsteqc.fsf@gnus.org> <87bksgte5e.fsf@gnus.org> <877d34tdwf.fsf@gnus.org> <83pmgwdxhh.fsf@gnu.org> <8735dstdhn.fsf@gnus.org> <37dd2827f52038e95791@heytings.org> <83wnb2ddxd.fsf@gnu.org> <37dd2827f57a3d664931@heytings.org> <37dd2827f52c6a150684@heytings.org> <83tu66cfnr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40600"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 57207@debbugs.gnu.org, yantar92@gmail.com To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 21 14:03:18 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 1oPjfh-000AMM-Cx for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Aug 2022 14:03:17 +0200 Original-Received: from localhost ([::1]:54740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oPjff-0004SN-VQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Aug 2022 08:03:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPjfS-0004Ps-ES for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:03:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44193) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oPjfS-0004Hi-63 for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oPjfS-0004NS-1t for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Aug 2022 12:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57207 X-GNU-PR-Package: emacs Original-Received: via spool by 57207-submit@debbugs.gnu.org id=B57207.166108334816779 (code B ref 57207); Sun, 21 Aug 2022 12:03:02 +0000 Original-Received: (at 57207) by debbugs.gnu.org; 21 Aug 2022 12:02:28 +0000 Original-Received: from localhost ([127.0.0.1]:33939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPjet-0004MV-Na for submit@debbugs.gnu.org; Sun, 21 Aug 2022 08:02:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPjeq-0004M0-Sb for 57207@debbugs.gnu.org; Sun, 21 Aug 2022 08:02:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51768) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPjel-00044l-J1; Sun, 21 Aug 2022 08:02:19 -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=8JTDZs4jSoxbsROfnrtMCXvWgcTWf+R1BSaU+Tgnc7M=; b=r6B5A3t+t3xd An+KwOgC84NiUowkRXAvwlDEmwda+/YIKuLrl2rS7nMTXmEDudIXqu8U8D0ggzxIrhIVFph+J9IiG bTD/blOubXvmd0lmbn3aFORc70f5jufc64UwkGgsRAdxFiJEI66+PTkhABqhvbnUpKWZt0Ah60qi4 1rv5I3qFVRmcQaSCoikhzcSCMRpWMk0l9xhjfghjahbWcdo8Xtnv0uXOC0dMlk2nxuaUqnNDuPv6Z xu3MZiqnUGbYsYiMlT/owYh5VbxIVj1rbojA4sIlNoF/cbgtNY4zdsLGrd1ARJdJ4UP93+i4zFjsS 9i1aObXLxmHHrYYCwKRCRg==; Original-Received: from [87.69.77.57] (port=3634 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 1oPjek-00030f-9v; Sun, 21 Aug 2022 08:02:19 -0400 In-Reply-To: (message from Gregory Heytings on Sun, 21 Aug 2022 11:43:41 +0000) 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:240299 Archived-At: > Date: Sun, 21 Aug 2022 11:43:41 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, 57207@debbugs.gnu.org, yantar92@gmail.com > > > Narrowing inside redisplay itself is okay, provided that it's undone > > before we call redisplay_mode_lines. > > I pushed a potential fix to the feature branch. Does that look correct to > you? It seems to me (but I could very well be wrong) that if we use the > actual narrowing bounds inside decode_mode_spec, the mode line will > contain the correct information. Is locked narrowing intended to be used only for pre- and post-command hooks and similar stuff? That is, is it not intended for use from any other Lisp program? Also, do we know for sure that only the "outermost" narrowing is supposed to be reflected on the mode line? > Another way to do it would be to unset and reset the locked > narrowing for each buffer in the loop inside redisplay_mode_lines, I > think. Why not in redisplay_internal? TBH, I'm extremely nervous about forced narrowing in pre- and post-command hooks. Those hooks can run arbitrary Lisp and assume they can access the buffer without any unexpected restrictions. I think applying narrowing here runs afoul of the principle of enforcing the narrowing in as few places as possible, which IMO is the only way this technique can avoid breaking too many things. If some package puts on these hooks stuff that could run awry when long lines are present, I'd rather we fixed those packages and/or applied narrowing "by hand" in their hook functions. Since long-line-optimizations-p is not exposed to Lisp, there should be no difficulty in doing that.