[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] bug#22399: org-mode fontification

From: Stefan Monnier
Subject: [O] bug#22399: org-mode fontification
Date: Mon, 25 Jan 2016 09:30:37 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

> Sure.  With
> --8<---------------cut here---------------start------------->8---
> #+BEGIN_SRC elisp
>   (require 'cl-lib)
>   (message "test")
> --8<---------------cut here---------------end--------------->8---
> in /tmp/scratch.org, run
>   emacs -Q --eval "(setq org-src-fontify-natively t)" --visit /tmp/scratch.org
> Go to the code block and hit C-c ' (org-edit-special), and then exit
> with another C-c '.  Without this change, the source block is no longer
> highlighted as elisp code when I return to the buffer.

I see the problem.  org-src-font-lock-fontify-block is using buffers
named " org-src-fontification:<major-mode>" in an unusual way:
they're updated via normal buffer modifications, but they're not put in
font-lock-mode, so all the font-lock machinery which tries to keep the
fontification up-to-date is short-circuited, so it triggers a bug in
font-lock-ensure where we made incorrect assumptions.

I installed the patch below into emacs-25, which should fix this


--- a/lisp/font-lock.el
+++ b/lisp/font-lock.el
@@ -1074,7 +1074,13 @@ font-lock-flush
 (defvar font-lock-ensure-function
   (lambda (_beg _end)
-    (unless font-lock-fontified (font-lock-default-fontify-buffer)))
+    (unless font-lock-fontified
+      (font-lock-default-fontify-buffer)
+      (unless font-lock-mode
+        ;; If font-lock is not enabled, we don't have the hooks in place to
+        ;; track modifications, so a subsequent call to font-lock-ensure can't
+        ;; assume that the fontification is still valid.
+        (setq font-lock-fontified nil))))
   "Function to make sure a region has been fontified.
 Called with two arguments BEG and END.")

reply via email to

[Prev in Thread] Current Thread [Next in Thread]