Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]

[Carlos Pita]

As a possible fix I implemented this
font-lock-extend-after-change-region-function:

(defun my-org-extend-region (beg end old-len)
  (let ((begin-re "[\t ]*\\(#\\+BEGIN\\|\\\\begin{\\)")
        (end-re "[\t ]*\\(#\\+END\\|\\\\end{\\)"))
    (save-excursion
      (goto-char beg)
      (beginning-of-line)
      (if (looking-at end-re)
          (setq beg (or (re-search-backward begin-re nil t) beg))
        (when (looking-at begin-re)
          (setq end (or (re-search-forward end-re nil t) end))))))
  (cons beg end))

It's simple and efficient. The idea is that if you have changed one
endpoint of a #+BEGIN/#+END or \begin{/\end{ block, then you'd better
extend the fontification region up to the other end. This way the
extension only triggers when a BEGIN/END/begin/end match is found in
the current line after a change, making the whole thing quite
lightweight.

Notice that I added the BEGIN/END case because I was having some
issues with org blocks also, although they were less frequent, just
some border cases. This hook made the behavior more robust and
predictable.

Maybe you would like to add this (or something similar or better)
while initializing org mode font lock stuff.

Once this is in place it's trivial to get native fontification of
latex snippets working as explained above, without the need to
disrespect search limits.

So, to sum up:

1. There is a bug and some kind of region extension is in order to
address it. Here I'm proposing one simple solution.

2. Then there is a feature request: add the ability to natively
fontify latex embedded fragments. I've also shown how to do that in a
couple of lines, but obviously some new customization option is also
required.

HIH
--
Carlos


On Wed, Nov 28, 2018 at 3:38 PM Carlos Pita <address@hidden> wrote:
>
> Well, now I do have found a bug ;). It's related to the limit issue I
> mentioned before. Indeed the problem with rehighlighting broken
> environments and highlighting new environments also happens for basic
> latex fontification when org-highlight-latex-and-related is set to
> '(latex), it has nothing to do with my modification in order to call
> org-src-font-lock-fontify-block. It seems that once you break the
> multiline structure (for example, by putting a space between "be" and
> "gin") org mode syntax highlighter is unable to identify it again once
> recomposed. More generally, it's unable to identify environments
> entered after the initial loading of the file into the buffer, being
> them slight "repairments" of previously existing ones or just brand
> new environments. Of course, systematically ignoring the search bound
> is not the right solution. I think some kind of region extension
> function is missing here.