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#45898: 27.1; wedged in redisplay again Date: Thu, 23 Jun 2022 09:08:10 +0300 Message-ID: <837d57gbed.fsf@gnu.org> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <87k09rbcmn.fsf@gnus.org> <83a6an5jt3.fsf@gnu.org> <8335gf5er3.fsf@gnu.org> <87leu686z4.fsf@gnus.org> <83sfoe2k0j.fsf@gnu.org> <87zgim6qtt.fsf@gnus.org> <83mtem2dc9.fsf@gnu.org> <87y1y63qmq.fsf@gnus.org> <83h74t3k5u.fsf@gnu.org> <87tu8sx569.fsf@gnus.org> <83v8t6us8t.fsf@gnu.org> <87zgiinptk.fsf@gnus.org> <83mteiufih.fsf@gnu.org> <877d5kojbo.fsf@gnus.org> <83zgigu3e0.fsf@gnu.org> <500e4b9c69f2a90e7cf05b956178d71b@webmail.orcon.net.nz> <835yl3tnv3.fsf@gnu.org> <83iloyo0x7.fsf@gnu.org> <83mte5jukr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3418"; mail-complaints-to="usenet@ciao.gmane.io" Cc: psainty@orcon.net.nz, larsi@gnus.org, Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 23 08:09:15 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 1o4G1j-0000lf-7q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 08:09:15 +0200 Original-Received: from localhost ([::1]:33500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4G1i-0008Pf-2r for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 02:09:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38150) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4G1W-0008Ol-Ml for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 02:09:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43138) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4G1W-00085y-EF for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 02:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o4G1W-0003Sq-1o for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 02:09: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: Thu, 23 Jun 2022 06:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45898 X-GNU-PR-Package: emacs Original-Received: via spool by 45898-submit@debbugs.gnu.org id=B45898.165596451313279 (code B ref 45898); Thu, 23 Jun 2022 06:09:02 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 23 Jun 2022 06:08:33 +0000 Original-Received: from localhost ([127.0.0.1]:37035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4G0z-0003S3-Gw for submit@debbugs.gnu.org; Thu, 23 Jun 2022 02:08:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4G0w-0003Ro-QI for 45898@debbugs.gnu.org; Thu, 23 Jun 2022 02:08:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4G0r-0007vR-8R; Thu, 23 Jun 2022 02:08:21 -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=oIhKEoBpgeT9DWBb+9Sy24d0Dl9e1oGCXMFZstfYrY8=; b=C7duKHnsAm1w JLNuVwtL2XOl5BQ0zW2tKSKLDuWnLeDgG9gMcuD3rGkhj0HHKv5JrMNW5r5IkvQsvziDM4Wv1717f zJNIE8FHCl4HYFn5yyT+cxYWJuJZNmNH2XUqBdqR4LsoVNAV5IqdVYmlhtshCufz4EuJ+tj6Rww+Z nR8GER5B58LRiDDMUZXA4VBUfYMGnpUsy8WocMp7x7ZoycD7bWokL7chePAatKTDMICs+7jlwb3/+ elgphokzGasvx/fDEOWlLZIkF+vII0lQA37DA8bdM24kcgz2xAzjEV104+9wWHiEb7yJ+Hg7QYcel vpiTmUvvqJme5Y2uS+7jFQ==; Original-Received: from [87.69.77.57] (port=2046 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 1o4G0p-0004R5-1D; Thu, 23 Jun 2022 02:08:20 -0400 In-Reply-To: (message from Stefan Monnier on Wed, 22 Jun 2022 19:39:14 -0400) 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:235064 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, psainty@orcon.net.nz, Emacs-hacker2018@jovi.net, > 45898@debbugs.gnu.org > Date: Wed, 22 Jun 2022 19:39:14 -0400 > > > Isn't there a way to limit what font-lock considers a "line" such that > > it doesn't consider more than some number N of characters? What could > > potentially happen if we set N to, like, 10,000 characters? > > Misfontification around that boundary. > > > Are you saying that many regular expressions in font-lock-keywords are > > anchored at beginning or end of a line? > > No but for example if the 10000 char boundary falls in the middle of the > word "function", then all the highlighting rules which rely on matching > the keyword "function" will fail. So we value accurate fontification more than we value a usable Emacs session? That sounds strange to me, since fontification is basically a nicety, in the sense that it is not necessary for the text being readable by humans. To put this in perspective, I'm about to land a feature which, when activated, will sometimes produce semi-updated windows (like incorrect position of cursor) or even completely outdated windows (where what's on the glass doesn't necessarily reflect where we are in the text, like if you are at EOB, but the window still shows the last portion of buffer text). All that is done as a means to make Emacs usable even when you for some reason visited a file with such pathologically long lines. If the weird results of redisplay under that feature are acceptable in these extreme situations, I wonder why sacrificing accuracy of font-lock wouldn't be. > > And even if the regexp-based font-lock needs to do it line-by-line, > > does it really _have_ to invoke parse-partial-sexp for the entire > > line, when doing syntactical fontifications? why is that? > > AFAICT this is a call that does > > (parse-partial-sexp (point) end nil nil state 'syntax-table) > > where `end` happens to be point-max (because of font-lock's rounding up > to whole lines) which will not itself parse all the way to `end` but > will instead stop at the next string/comment boundary. This is used > (inside a loop which will indeed go all the way to `end`, > i.e. `point-max`) to highlight strings and comments (as you can see > from the stack trace, this is `font-lock-fontify-syntactically-region`). Yes, that's what I see. > For such huge files, it's arguably more important to be more-or-less > usable than it is to get the highlighting right, so there's a good case > for turning off font-lock or breaking it somewhat by using arbitrary > limits in the handling of `font-lock-extend-region-functions` in > `font-lock-default-fontify-region`. I'm talking about cases where the user visits such files without knowing in advance that he/she has better turned off font-lock there. I'm asking whether one of the things we could do when we discover that parse-partial-sexp is called for such a large chunk of text could be automatic introduction of such a limit only for that buffer, so that font-lock won't be such a significant part of the reason for redisplay slowness in these cases. Also, can you tell why visiting the same file in Text mode doesn't produce the same effect? I guess this is related to font-lock settings of js.el, but my question is: would any mode that uses syntactic fontification be similarly affected, or is there anything special with js.el specifically? IOW, is the above tendency to scan everything to the end of line inherent in syntactic fontifications? Thanks.