bug#22399: org-mode fontification

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Sure.  With
>
> --8<---------------cut here---------------start------------->8---
>
> #+BEGIN_SRC elisp
>   (require 'cl-lib)
>   (message "test")
> #+END_SRC
> --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
problem,


        Stefan


--- 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.")