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: Wed, 22 Jun 2022 05:33:24 +0300 Message-ID: <83mte5jukr.fsf@gnu.org> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <87h74wh9x7.fsf@gnus.org> <83bkv47evy.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21930"; 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 Wed Jun 22 04:34: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 1o3qC1-0005Tb-LV for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Jun 2022 04:34:09 +0200 Original-Received: from localhost ([::1]:49568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3qC0-0005ra-0J for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Jun 2022 22:34:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3qBu-0005rB-HW for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2022 22:34:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39725) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o3qBu-0006nL-9D for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2022 22:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o3qBu-0005k7-2o for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2022 22:34: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: Wed, 22 Jun 2022 02:34: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.165586522922051 (code B ref 45898); Wed, 22 Jun 2022 02:34:02 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 22 Jun 2022 02:33:49 +0000 Original-Received: from localhost ([127.0.0.1]:33622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o3qBc-0005jW-G7 for submit@debbugs.gnu.org; Tue, 21 Jun 2022 22:33:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o3qBa-0005jI-G4 for 45898@debbugs.gnu.org; Tue, 21 Jun 2022 22:33:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:32996) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3qBT-0006eZ-Vc; Tue, 21 Jun 2022 22:33:35 -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=QYkQ8cHBBxT7hwdA1W4ogYd1+LWajDweUscZIdvPv6Y=; b=NaUKDa4VM2qt dO6T1IsQInI8fg8AoKiopCh60mPIIenIe7pqsJKNeuoOLMNnB/Zx4/gaFDTRmYmLI4BrlIZfdT7Wm k7O7h00D0qvNUPHUh9afp/Wma1hp2SCSZVgw9GC4uW4f7uRkbnPe8TTmQm55s7vulKqu/xf9LAtt7 T48UTc2aa4bnxs/6Gjp4XDsheG0dI+fPwP0fEyBVxzzjqQ0N6Ftf8Caxbba6pgZkkf5/Cg9ynA/dB 32UN2G1zGelalUcUBJCH/EMoLK582KdKN3duQ2RkwmcUg2sxAiQk4qvp09aDOGXeL8T2LtwQzKa5E tHymk2VPxZt4iMpF+k/zgQ==; Original-Received: from [87.69.77.57] (port=1576 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 1o3qBT-00038T-F0; Tue, 21 Jun 2022 22:33:35 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 21 Jun 2022 16:38:59 -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:234993 Archived-At: > From: Stefan Monnier > Cc: Lars Ingebrigtsen , psainty@orcon.net.nz, > Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org > Date: Tue, 21 Jun 2022 16:38:59 -0400 > > > One surprising finding is that sometimes syntactic fontifications > > (triggered via jit-lock.el as part of rendering the buffer) seem to > > run amok: jit-lock asks the mode's fontification to fontify a > > 1500-character block, but that results in parse-partial-sexp being > > called to parse the entire humongous file, BOB to EOB. > > IIUC the file is a single long-line. Font-lock works line-by-line (in > theory major modes can override that by providing their own value for > `font-lock-extend-region-functions`, but regexp-based fontification is > hard to do with our regexp enging if not working line-by-line), so even > if jit-lock only requests fontification of a 1500-char block, font-lock > rounds it up to a whole number of lines (and then proceeds to call > `parse-partial-sexp), which would explain what you're seeing. 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? Are you saying that many regular expressions in font-lock-keywords are anchored at beginning or end of a line? 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?