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