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: Wed, 28 Nov 2018 19:46:36 -0300 [thread overview]
Message-ID: <CAELgYhcyyjFPGNT7ZN7H4Xyisok1U5RZrFK9DtrF1wNchy7o_g@mail.gmail.com> (raw)
In-Reply-To: <CAELgYhdrFy2W_BdYOH9TUvawsVy1JY=wgHUsu4AZ8xnmkGTLvA@mail.gmail.com>
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 <carlosjosepita@gmail.com> 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.
next prev parent reply other threads:[~2018-11-28 22:47 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 [this message]
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
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=CAELgYhcyyjFPGNT7ZN7H4Xyisok1U5RZrFK9DtrF1wNchy7o_g@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).