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#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling) Date: Sun, 21 Aug 2022 12:42:05 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25796"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 57207@debbugs.gnu.org, yantar92@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 21 14:43: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 1oPkII-0006UH-KD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Aug 2022 14:43:10 +0200 Original-Received: from localhost ([::1]:46254 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oPkIG-0004Td-UF for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Aug 2022 08:43:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPkIA-0004Si-LJ for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:43:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44264) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oPkIA-0002N0-Bs for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oPkIA-0007ZQ-1z for bug-gnu-emacs@gnu.org; Sun, 21 Aug 2022 08:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Aug 2022 12:43: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.166108573329041 (code B ref 57207); Sun, 21 Aug 2022 12:43:02 +0000 Original-Received: (at 57207) by debbugs.gnu.org; 21 Aug 2022 12:42:13 +0000 Original-Received: from localhost ([127.0.0.1]:34013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPkHL-0007YK-FA for submit@debbugs.gnu.org; Sun, 21 Aug 2022 08:42:13 -0400 Original-Received: from heytings.org ([95.142.160.155]:34266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPkHG-0007Y9-Tq for 57207@debbugs.gnu.org; Sun, 21 Aug 2022 08:42:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1661085725; bh=qA9M7RYwEQDWsm2Jf4tU+L/xyrurXkp7MxUQ8y21irs=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=PWtx1wzvhqxQEFMoaDdM96jhWjtDXFlVda7xRSIngJQGrBD6rkBHbleQPbBax4s2F TAZ7V0/SNT/aDPiPfvX/JTKTl2Mgrjad/YhAywxGA4MBfveFSmXnWId+4tZG/DDDpY GodbZ4gBjCezp8CKk7hBRWaGCuzasGvSY7CIQwDvZFuQpMIqvhWHddtT+Pji6Jzygo rZA0oRUTW/Zkcx2pb0N8kKUIHY7CgjmWh5PlBeymFETw66QhVCColsJm6UatteUL+i 9kv2jY0xMIFxl/1XV+yvCutBr/nlCkeSbsYEgPg5ZYeV2R/2rBVdEdWFXK8rzliq3F 8odMsQR9zav7g== In-Reply-To: <83fshpdctx.fsf@gnu.org> 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:240305 Archived-At: > > 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). > > Also, do we know for sure that only the "outermost" narrowing is > supposed to be reflected on the mode line? > Given how the "outermost" narrowing is calculated (perhaps "outermost" is not the best name, I did not find a better one), yes, I think so. The outermost narrowing is the narrowing before locked narrowing is entered. >> 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. > > 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, and it will happen only in "too large" buffers anyway. 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.