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:53:47 +0300 Message-ID: <83bksddag4.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> <83fshpdctx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36050"; 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:54:10 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 1oPkSw-0009H1-FW for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Aug 2022 14:54:10 +0200 Original-Received: from localhost ([::1]:40234 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oPkSv-0000Iq-6Q for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Aug 2022 08:54:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPkSo-0000Ig-KZ for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44277) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oPkSo-00045y-52 for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oPkSn-0007tP-RW for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:54:01 -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:54:01 +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.166108643530326 (code B ref 57207); Sun, 21 Aug 2022 12:54:01 +0000 Original-Received: (at 57207) by debbugs.gnu.org; 21 Aug 2022 12:53:55 +0000 Original-Received: from localhost ([127.0.0.1]:34026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPkSg-0007t3-QG for submit@debbugs.gnu.org; Sun, 21 Aug 2022 08:53:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPkSf-0007sq-7k for 57207@debbugs.gnu.org; Sun, 21 Aug 2022 08:53:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43378) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPkSZ-00045F-Sp; Sun, 21 Aug 2022 08:53:47 -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=QkSBejkeerG6DPOsi4odSR5A9lWZ5uwqCBiA+0+bZE0=; b=Grpm6qY4/oHJ AAdhuUCHX0u2zIOyDX3pmYRizRv4Sbmz8pRNgMjQVJLZgagMxLiLgzw/cyqARYb8b/TYJ85ALCyuC Oo0MB144qPjrpS3ColWONSWoEGoReWnn0yCRE5RG4rlURBptiKUrrKSazgmFk4Pg2Nx87AH4wpc2m ZRFzJt9Ydjpsyl1qRwC72n8PyeeuTZUmpcoK1hAAwMDQTLRNcTBTJYXhJEOQpH/5XY3AcVWzKb6HD z1rMXlEzixYsQ+GJ7VvkeJB4Z7YpebpmowvcNiGaYnjiW3Xejp5LLuAFRJrsP3F0HMIjd9raCm0gf p9QRd6Z76J2sr1EZlh2yYg==; Original-Received: from [87.69.77.57] (port=2820 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 1oPkSZ-0001b0-C1; Sun, 21 Aug 2022 08:53:47 -0400 In-Reply-To: (message from Gregory Heytings on Sun, 21 Aug 2022 12:42:05 +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:240308 Archived-At: > Date: Sun, 21 Aug 2022 12:42:05 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, 57207@debbugs.gnu.org, yantar92@gmail.com > > > 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? > > Stefan said (IIUC) that it could be useful for Lisp programs, so it is now > possible to use it anywhere (but the docstring says that it should be done > sparingly). Which means that the code you installed on the branch will "undo" such narrowing done from Lisp as well, doesn't it? That might not be what the Lisp program which did that wanted. > >> 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? > > In general I prefer to act on lower levels if possible. But yes, indeed, > it could be moved above decode_mode_spec and redisplay_mode_lines, in > echo_area_display or redisplay_internal. It is better to do that higher, because not only those places in decode_mode_spec may wish to access BEGV and ZV. Even in the mode-line display there are :eval and :when. > > 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 now exposed to > > Lisp, there should be no difficulty in doing that. > > I don't know. As far as I can see it doesn't seem to create many > problems I fear this is just the tip of the iceberg. > and it will happen only in "too large" buffers anyway. Yes, but these hooks run stuff that doesn't necessarily access buffer text or look far away of the viewport. > IMO we should just give it a try, it will always be possible to step > back if it transpires that the cost is higher than the benefit. That's we are doing. But we could also do it the other way around: fix the places we know are problematic in Lisp, and then wait for enough such problems to appear elsewhere.