emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65


From: Carlos Pita
Subject: 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/)]
Date: Fri, 21 Dec 2018 20:37:43 -0300

Hi Nicolas, thank you for letting me know.

I've been giving it a try but it doesn't really fix the main problem
AFAICS (I've just redefined org-do-latex-and-related as in [1], maybe
I'm missing something). It's not surprising because I don't think you
can work around it without installing a region extension function.

For example, in order to reproduce one possible problem:

1) write \begin{xxx}
2) in the next line write xxx
3) now, in a third line, write \end{xxx}

This basic example already fails because you're not entering the start
and end delimiters at the same time (maybe you're using some snippet
facility for that?). Then you have an array of more complex cases:
blocks that are larger than jit-lock-chunk-size, changing one of the
ends of the block and restoring it, etc.

There is no perfect solution that I know of, but at the bare least you
have to let the font lock framework know that some entire  syntactical
region has changed. Also you have to ignore search limits since one
chunk won't do it as a syntactical unit, but you are already doing
this. Even doing all this, some border cases remain, in particular if
you have a really large block and you go to the end of it and change
its delimiter and then restore it, the jit framework will proceed by
chunks upwards but only when you scroll up and progressively reveal
the block, so in general it won't be refontified until you get near
the top delimiter and the search finally identifies a syntactic unit
from the top to the bottom. I don't think this case is important in
practice, but it's a good illustration of how things are working under
the hood.

Also, there is the fact that this limitations are shared by the font
locking of #+BEGIN/END blocks. Even if search limits are ignored, the
region extension is still missing there too.

I've considerably improved my region extension function since my last
post, if you're interested in adding it I could write a proper patch,
but here it is anyway:

(defun my-org-extend-region (beg end _old-len)
  (let ((begin-re "\\(\\\\\\[\\|\\(#\\+begin_\\|\\\\begin{\\)\\S-+\\)")
        (end-re "\\(\\\\\\]\\|\\(#\\+end_\\|\\\\end{\\)\\S-+\\)")
        (extend (lambda (r1 r2 dir)
                  (let ((re (replace-regexp-in-string "\\(begin\\|end\\)" r1
                             (replace-regexp-in-string "[][]" r2
                              (match-string-no-properties 0)))))
                    (re-search-forward (regexp-quote re) nil t dir)))))
    (save-match-data
      (save-excursion
        (goto-char beg)
        (back-to-indentation)
        (cond ((looking-at end-re)
               (cons (or (funcall extend "begin" "[" -1) beg) end))
              ((looking-at begin-re)
               (cons beg (or (funcall extend "end" "]" 1) end)))
              (t (cons beg end)))))))

Now it better supports nested blocks (of different types at least) and
also displaymath \[ \] delimiters.

Best regards
--
Carlos

[1] 
https://code.orgmode.org/bzg/org-mode/commit/af3e2b1856be4088071bd01f386560cff1e292bc?style=unified



reply via email to

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