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#56682: Fix the long lines font locking related slowdowns Date: Sat, 30 Jul 2022 10:52:48 +0000 Message-ID: <65cb7c73fd4a999cca00@heytings.org> References: <837d46mjen.fsf@gnu.org> <8a3eaeef01be5bfaa5ef@heytings.org> <05388e8d8812bfa3695d@heytings.org> <83v8rf5894.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26185"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 12:53:45 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 1oHk6L-0006fW-4N for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 12:53:45 +0200 Original-Received: from localhost ([::1]:34766 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHk6D-0006gw-Cn for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 06:53:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46732) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHk5e-0006H6-Fz for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 06:53:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHk5e-0004EI-6u for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 06:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHk5d-0003Wa-Vi for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 06:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jul 2022 10:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.165917837213529 (code B ref 56682); Sat, 30 Jul 2022 10:53:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Jul 2022 10:52:52 +0000 Original-Received: from localhost ([127.0.0.1]:34097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHk5T-0003W8-Ve for submit@debbugs.gnu.org; Sat, 30 Jul 2022 06:52:52 -0400 Original-Received: from heytings.org ([95.142.160.155]:58946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHk5S-0003W0-Dm for 56682@debbugs.gnu.org; Sat, 30 Jul 2022 06:52:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1659178369; bh=iQ1JJ9Q6CosJYhmCpfJfmH4+K5DHVt5Ya2lGIBbCfgo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=N/pS+psBSQSa0zmTZkvEEyirzEZQiT7uZjUfEaY55XAI4++9PzwigV8X4K7dcCQb/ 5AuA53qDXdWJQzRfSYGYlhehGsSZBxTkrbKf030ZCrwSFzeQUXbNzWif4WkkIirC9v xzYSHV/ca9+24I0VkkvDCEZeTHqPeTZth08mmcfdH68knTUAMsM0WW+2ZxVyQSfyzL zWfsW5+4iUeewwGB7+1YmgY4pFBDMUfM+dOIRDTnifuJdVUEn9jZNeOeg66jmQxC4a 9Z/142vNpB/65G83XkUHUPZaK1+rHQg3OwvkVK04CZGV3+uY2Eng00fV+13ia2EJ0h +B5IebeJB3pGQ== In-Reply-To: <83v8rf5894.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:238249 Archived-At: >>> Feel free to suggest better ways of handling these issues, or even >>> ways to solve this entirely inside font-lock. If and when such >>> suggestions materialize, I'm sure we will be glad to use them instead >>> of less elegant/more direct solutions. >> >> I'd suggest to keep things mostly as they are but move the decision to >> ELisp: i.e. pass the beg..end limits to jit-lock and let jit-lock do >> the narrowing. This way it's easy to later refine the mechanism. > > That's already happening: code called via fontification-functions can > access the restriction via point-min and point-max. If you or someone > else can come up with efficient methods of using that information so as > not to go too far forward and back, we could consider removing the lock > from the narrowing. But we'd need to see the code first and assess the > resulting performance with long lines. > IIUC, what Stefan suggests is the following, which seems (almost) fine to me. The only problem I see is that jit-lock-function is not the only user of fontication-functions. It has at least two other users: in ELPA multi-mode.el sets fontification-functions to multi-fontify, and in MELPA poly-lock.el sets fontification-functions to poly-lock-function. diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el index be26ca55f0..aa26b990bc 100644 --- a/lisp/jit-lock.el +++ b/lisp/jit-lock.el @@ -370,27 +370,36 @@ jit-lock-refontify ;;; On demand fontification. +(defun jit-lock-function--internal (start) + "Internal function called by `jit-lock-function'." + (if (not (and jit-lock-defer-timer + (or (not (eq jit-lock-defer-time 0)) + (input-pending-p)))) + ;; No deferral. + (jit-lock-fontify-now start (+ start jit-lock-chunk-size)) + ;; Record the buffer for later fontification. + (unless (memq (current-buffer) jit-lock-defer-buffers) + (push (current-buffer) jit-lock-defer-buffers)) + ;; Mark the area as defer-fontified so that the redisplay engine + ;; is happy and so that the idle timer can find the places to fontify. + (with-buffer-prepared-for-jit-lock + (put-text-property start + (next-single-property-change + start 'fontified nil + (min (point-max) (+ start jit-lock-chunk-size))) + 'fontified 'defer)))) + (defun jit-lock-function (start) "Fontify current buffer starting at position START. This function is added to `fontification-functions' when `jit-lock-mode' is active." (when (and jit-lock-mode (not memory-full)) - (if (not (and jit-lock-defer-timer - (or (not (eq jit-lock-defer-time 0)) - (input-pending-p)))) - ;; No deferral. - (jit-lock-fontify-now start (+ start jit-lock-chunk-size)) - ;; Record the buffer for later fontification. - (unless (memq (current-buffer) jit-lock-defer-buffers) - (push (current-buffer) jit-lock-defer-buffers)) - ;; Mark the area as defer-fontified so that the redisplay engine - ;; is happy and so that the idle timer can find the places to fontify. - (with-buffer-prepared-for-jit-lock - (put-text-property start - (next-single-property-change - start 'fontified nil - (min (point-max) (+ start jit-lock-chunk-size))) - 'fontified 'defer))))) + (if (not fontification-functions-restriction) + (jit-lock-function--internal start) + (narrow-to-region (car fontification-functions-restriction) + (cdr fontification-functions-restriction) + t) + (jit-lock-function--internal start)))) (defun jit-lock--run-functions (beg end) (let ((tight-beg nil) (tight-end nil) diff --git a/src/xdisp.c b/src/xdisp.c index 0fdb1922e5..726e77b8eb 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -4412,9 +4412,9 @@ handle_fontified_prop (struct it *it) ptrdiff_t begv = it->narrowed_begv ? it->narrowed_begv : BEGV; ptrdiff_t zv = it->narrowed_zv; ptrdiff_t charpos = IT_CHARPOS (*it); if (begv <= charpos && charpos <= zv) - Fnarrow_to_region (make_fixnum (begv), make_fixnum (zv), Qt); + specbind (Qfontification_functions_restriction, + Fcons (make_fixnum (begv), make_fixnum (zv))); } /* Don't allow Lisp that runs from 'fontification-functions' @@ -36673,6 +36673,13 @@ syms_of_xdisp (void) Vfontification_functions = Qnil; Fmake_variable_buffer_local (Qfontification_functions); + DEFSYM (Qfontification_functions_restriction, + "fontification-functions-restriction"); + DEFVAR_LISP ("fontification-functions-restriction", + Vfontification_functions_restriction, + doc: /* TODO */); + Vfontification_functions_restriction = Qnil; + DEFVAR_BOOL ("unibyte-display-via-language-environment", unibyte_display_via_language_environment, doc: /* Non-nil means display unibyte text according to language environment. By the way, while trying the above, it became clear that I forgot to properly handle the new optional argument to narrow-to-region in byte-compiled code. But I don't know how to do that: diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index b4954eee9f..1ecd77f751 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -767,7 +767,7 @@ 121 (byte-defop 122 0 byte-char-syntax) (byte-defop 123 -1 byte-buffer-substring) (byte-defop 124 -1 byte-delete-region) -(byte-defop 125 -1 byte-narrow-to-region) +(byte-defop 125 -2 byte-narrow-to-region) (byte-defop 126 1 byte-widen) (byte-defop 127 0 byte-end-of-line) @@ -3833,7 +3833,7 @@ setcar (byte-defop-compiler setcdr 2) (byte-defop-compiler buffer-substring 2) (byte-defop-compiler delete-region 2) -(byte-defop-compiler narrow-to-region 2) +(byte-defop-compiler narrow-to-region 2-3) (byte-defop-compiler (% byte-rem) 2) (byte-defop-compiler aset 3) is apparently not enough, because "2-3" seems to install an integer-or-marker-p check on the third argument, which raises a (wrong-type-argument integer-or-marker-p nil) or (wrong-type-argument integer-or-marker-p t) error when narrow-to-region is called from byte-compiled code.