Fontification of long code blocks can be very slow. The patch, which should be in another other email, mitigates this by adding an option to delay the fontification after the user has become idle by using idle timers. This seems to be faster from my limited testing, but I'm not sure if something will go horribly wrong because of the timers. There is a trade-off in that there will be no syntax highlightinting when the user is typing. I don't know how to keep existing fontification so it would be great if somebody could share a solution to that. I have signed the copyright papers so that shouldn't be a problem. This is my first patch submission so any suggestions for improvement are welcome. Leo Okawa Ericson (1): org-src.el: Add option to delay fontification of source blocks lisp/org-src.el | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) -- 2.25.1
* lisp/org-src.el (org-src-font-lock-fontify-block): Add option to delay fontification of source blocks. If `org-src-font-lock-fontify-idle-delay' is non-nil fontification of code blocks is delayed until the user has become idle. Fontification of source blocks can be very slow. This will add an option for users to delay the fontification until they have become idle so that the typing delay is kept low. The trade-off is that there will be no syntax highlighting when the user is typing. --- lisp/org-src.el | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/lisp/org-src.el b/lisp/org-src.el index 20acee4e6..b1446e105 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -584,11 +584,40 @@ (defun org-src--edit-element \f ;;; Fontification of source blocks +(defvar org-src-font-lock-fontify-idle-timer nil + "Idle timer to use for when fontifying with a timer.") + + +(defvar org-src-font-lock-fontify-idle-delay nil + "Duration of the delay until fontification of source blocks. +If non-nil, source blocks are fontified when the user has been +idle for `org-src-font-lock-fontify-idle-delay' seconds. This +means that instead of applying syntax highlighting when you type +it is delayed until you become idle. Not that when typing there +will be no fontification. +") (defun org-src-font-lock-fontify-block (lang start end) "Fontify code block. This function is called by emacs automatic fontification, as long as `org-src-fontify-natively' is non-nil." + (if org-src-font-lock-fontify-idle-delay + (progn + (when org-src-font-lock-fontify-idle-timer + (cancel-timer org-src-font-lock-fontify-idle-timer)) + (setq org-src-font-lock-fontify-idle-timer + (let ((buf (current-buffer))) + (run-with-idle-timer + org-src-font-lock-fontify-idle-delay + nil + (lambda () + (with-current-buffer buf + (org-src-font-lock-fontify-block-1 lang start end) + (when org-src-font-lock-fontify-idle-timer + (cancel-timer org-src-font-lock-fontify-idle-timer)) )))))) + (org-src-font-lock-fontify-block-1 lang start end))) + +(defun org-src-font-lock-fontify-block-1 (lang start end) (let ((lang-mode (org-src-get-lang-mode lang))) (when (fboundp lang-mode) (let ((string (buffer-substring-no-properties start end)) -- 2.25.1
From: Leo Okawa Ericson <leo@relevant-information.com> I tried sending this patch once before, but I think it got caught as spam so I'm trying this again. Fontification of long code blocks can be very slow. The patch (in the reply to this email) mitigates this by adding an option to delay the fontification after the user has become idle by using idle timers. This seems to be faster from my limited testing, but I'm not sure if something will go horribly wrong because of the timers. There is a trade-off in that there will be no syntax highlightinting when the user is typing. I don't know how to keep existing fontification so it would be great if somebody could share a solution to that. I have signed the copyright papers so that shouldn't be a problem. This is my first patch submission so any suggestions for improvement are welcome. Leo Okawa Ericson (1): org-src.el: Add option to delay fontification of source blocks lisp/org-src.el | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) -- 2.25.1
From: Leo Okawa Ericson <leo@relevant-information.com> I tried sending this patch once before, but I think it got caught as spam so I'm trying this again. Fontification of long code blocks can be very slow. The patch (in the reply to this email) mitigates this by adding an option to delay the fontification after the user has become idle by using idle timers. This seems to be faster from my limited testing, but I'm not sure if something will go horribly wrong because of the timers. There is a trade-off in that there will be no syntax highlightinting when the user is typing. I don't know how to keep existing fontification so it would be great if somebody could share a solution to that. I have signed the copyright papers so that shouldn't be a problem. This is my first patch submission so any suggestions for improvement are welcome. Leo Okawa Ericson (1): org-src.el: Add option to delay fontification of source blocks lisp/org-src.el | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) -- 2.25.1
Leo Okawa Ericson writes:
> Fontification of long code blocks can be very slow. The patch, which should be
> in another other email, mitigates this by
> adding an option to delay the fontification after the user has become idle by
> using idle timers. This seems to be faster from my limited testing, but I'm not
> sure if something will go horribly wrong because of the timers.
Thanks for the patch. My initial reaction is that I'm not sure about
adding an idle timer for a particular aspect of fontification. If we do
go this route, I think the case needs to be made why this spot is
special, and why we don't expect or would reject follow-up patches for
this and that other area.
Have you explored whether jit-lock (e.g., jit-lock-defer-time) helps for
your use case?
Kyle Meyer <kyle@kyleam.com> writes: > Have you explored whether jit-lock (e.g., jit-lock-defer-time) helps for > your use case? No I didn't know about it. I have tried it now and it seems to solve the same problem as my patch. > If we do go this route, I think the case needs to be made why this > spot is special, and why we don't expect or would reject follow-up > patches for this and that other area. > I can't think of a reason either (now that I know that jit-lock exists) so I will retract my patch.
Marking as closed on updates.orgmode.org via the X-Woof-Patch header.
Leo Okawa Ericson <leo@relevant-information.com> writes:
> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.
Marking as closed on updates.orgmode.org via the X-Woof-Patch header.
Leo Okawa Ericson <leo@relevant-information.com> writes:
> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.
Marking as closed on updates.orgmode.org via the X-Woof-Patch header.
Leo Okawa Ericson <leo@relevant-information.com> writes:
> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.