Redundant font-locking in comint buffers

Redundant font-locking in comint buffers

[Stefan Monnier]

Text in comint buffers (especially prompts and input text) tends to be
re-fontified excessively because comint adds/removes text-properties
on them frequently, which is always considered as a buffer-modification
and thus triggers font-lock.

This is generally a minor issue of performance, especially with jit-lock
which delays the font-locking until display, thus bundling most of the
redundant re-fontification into a single one.  But if you use
compilation-shell-minor-mode, then the redundant fontification becomes more
noticeable because jit-lock is turned off and because font-lock does
more work.

So I suggest the patch below which wraps all the text-property manipulation
inside `inhibit-modification-hooks' to make sure font-lock will not be
unnecessarily triggered.

Any objection?


        Stefan


--- orig/lisp/comint.el
+++ mod/lisp/comint.el
@@ -1482,7 +1482,8 @@
 				(concat input "\n")))
 
 	  (let ((beg (marker-position pmark))
-		(end (if no-newline (point) (1- (point)))))
+	      (end (if no-newline (point) (1- (point))))
+	      (inhibit-modification-hooks t))
 	    (when (> end beg)
 	      ;; Set text-properties for the input field
 	      (add-text-properties
@@ -1578,7 +1576,8 @@
 freeze its attributes in place, even when more input comes a long
 and moves the prompt overlay."
   (when comint-last-prompt-overlay
-    (let ((inhibit-read-only t))
+    (let ((inhibit-read-only t)
+	  (inhibit-modification-hooks t))
       (add-text-properties (overlay-start comint-last-prompt-overlay)
                            (overlay-end comint-last-prompt-overlay)
                            (overlay-properties comint-last-prompt-overlay)))))
@@ -1709,7 +1708,8 @@
 	    (goto-char (process-mark process)) ; in case a filter moved it
 
 	    (unless comint-use-prompt-regexp-instead-of-fields
-              (let ((inhibit-read-only t))
+              (let ((inhibit-read-only t)
+		    (inhibit-modification-hooks t))
                 (add-text-properties comint-last-output-start (point)
                                      '(rear-nonsticky t
 				       field output
@@ -1718,7 +1718,8 @@
 	    ;; Highlight the prompt, where we define `prompt' to mean
 	    ;; the most recent output that doesn't end with a newline.
 	    (let ((prompt-start (save-excursion (forward-line 0) (point)))
-		  (inhibit-read-only t))
+		  (inhibit-read-only t)
+		  (inhibit-modification-hooks t))
 	      (when comint-prompt-read-only
 		(or (= (point-min) prompt-start)
 		    (get-text-property (1- prompt-start) 'read-only)
@@ -2347,7 +2354,8 @@
 If the character after point does not have a front-sticky
 read-only property, any read-only property of `fence' on the
 preceding newline is removed."
-  (let* ((pt (point)) (lst (get-text-property pt 'front-sticky)))
+  (let* ((pt (point)) (lst (get-text-property pt 'front-sticky))
+	 (inhibit-modification-hooks t))
     (and (bolp)
 	 (not (bobp))
 	 (if (and (get-text-property pt 'read-only)

Re: Redundant font-locking in comint buffers

[Richard Stallman]

I see nothing wrong with this change, but it occurs to me that, later
on, we might want to do something so that text property changes alone
won't cause refontification.  If fontification does not depend on
text properties, then that is generally correct.

Re: Redundant font-locking in comint buffers

[Stefan Monnier]

> So I suggest the patch below which wraps all the text-property manipulation
> inside `inhibit-modification-hooks' to make sure font-lock will not be
> unnecessarily triggered.

Installed,


        Stefan