From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlos Pita 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 Message-ID: References: <87h8g2kv81.fsf@gmail.com> <87lg5ershk.fsf@nicolasgoaziou.fr> <87d0qpsc4g.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gS8bk-0002oa-Dq for emacs-orgmode@gnu.org; Wed, 28 Nov 2018 17:47:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gS8bi-0003aB-T5 for emacs-orgmode@gnu.org; Wed, 28 Nov 2018 17:47:00 -0500 Received: from mail-yb1-xb43.google.com ([2607:f8b0:4864:20::b43]:42767) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gS8bi-0003SV-IB for emacs-orgmode@gnu.org; Wed, 28 Nov 2018 17:46:58 -0500 Received: by mail-yb1-xb43.google.com with SMTP id o204-v6so11335151yba.9 for ; Wed, 28 Nov 2018 14:46:50 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org 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 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.