From: Carlos Pita <carlosjosepita@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: 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 [thread overview]
Message-ID: <CAELgYhesRfV1=wdF0xDv3vf_rmRh-N1eso5Pbpr0oFQfAqJxrg@mail.gmail.com> (raw)
In-Reply-To: <87woo5xkgf.fsf@nicolasgoaziou.fr>
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
next prev parent reply other threads:[~2018-12-21 23:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 22:32 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
2018-11-27 22:58 ` Carlos Pita
2018-11-27 23:49 ` Nicolas Goaziou
2018-11-28 0:14 ` Carlos Pita
2018-11-28 0:27 ` Carlos Pita
2018-11-28 1:22 ` Carlos Pita
2018-11-28 10:57 ` Nicolas Goaziou
2018-11-28 15:02 ` Carlos Pita
2018-11-28 16:55 ` Carlos Pita
2018-11-28 17:28 ` Carlos Pita
2018-11-28 18:38 ` Carlos Pita
2018-11-28 22:46 ` Carlos Pita
2018-12-03 3:54 ` Carlos Pita
2018-12-03 4:18 ` Carlos Pita
2018-12-19 21:42 ` Nicolas Goaziou
2018-12-21 23:37 ` Carlos Pita [this message]
2018-12-21 23:54 ` Carlos Pita
2018-12-22 0:42 ` Carlos Pita
2018-12-22 0:46 ` Carlos Pita
2018-12-22 2:38 ` Carlos Pita
2018-12-22 8:21 ` Nicolas Goaziou
2018-12-22 13:16 ` Carlos Pita
2018-12-22 15:07 ` Carlos Pita
2019-01-01 16:46 ` Nicolas Goaziou
2019-01-01 17:11 ` Carlos Pita
2019-01-01 17:14 ` Carlos Pita
2019-01-01 18:17 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAELgYhesRfV1=wdF0xDv3vf_rmRh-N1eso5Pbpr0oFQfAqJxrg@mail.gmail.com' \
--to=carlosjosepita@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).