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: Fri, 21 Dec 2018 23:38:35 -0300 Message-ID: References: <87h8g2kv81.fsf@gmail.com> <87lg5ershk.fsf@nicolasgoaziou.fr> <87d0qpsc4g.fsf@nicolasgoaziou.fr> <87woo5xkgf.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]:54139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaXBh-00064H-2u for emacs-orgmode@gnu.org; Fri, 21 Dec 2018 21:38:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gaXBg-0001MF-FB for emacs-orgmode@gnu.org; Fri, 21 Dec 2018 21:38:49 -0500 Received: from mail-yb1-xb42.google.com ([2607:f8b0:4864:20::b42]:42751) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gaXBg-0001Ls-7h for emacs-orgmode@gnu.org; Fri, 21 Dec 2018 21:38:48 -0500 Received: by mail-yb1-xb42.google.com with SMTP id q145so1326055ybq.9 for ; Fri, 21 Dec 2018 18:38:48 -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 Nicolas, I have modified org-fontify-meta-lines-and-blocks-1 following your approach: @@ -5991,6 +5991,13 @@ by a #." (dc3 (downcase (match-string 3))) end end1 quoting block-type) (cond + ((and (match-end 4) (equal dc3 "+end")) + (save-match-data + (save-excursion + (when (re-search-backward + (concat "^[ \t]*#\\+begin" (match-string 4) "\\>.*") + nil t) ;; on purpose, we look further than LIMIT + (org-fontify-meta-lines-and-blocks-1 limit))))) ((and (match-end 4) (equal dc3 "+begin")) ;; Truly a block (setq block-type (downcase (match-string 5)) Nevertheless I'm not quite satisfied. If you play a bit with opening and ending delimiters and moving around the buffer you will quite easily find border cases in which the block is indeed recognized and properties adequately set but still font locking is only partially refreshed until you scroll, move to another buffer, etc. I tried any combination of save-match-data and save-excursion wrapping the recursive call, even without any of them, to no avail. What I think it's happening here is that ignoring the limit forwards could be a tolerable trick, but when you start jumping forward and backwards in you fontification function, font-lock routines lose track of what is meant to be refreshed; and if, instead, you save everything before jumping around it's like nothing or too little have been refontified from the point of view of the framework. I still believe that explicitly extending the region is a saner approach, it's the documented one at least. Maybe you could rewrite my function in a better way using the precomputed latex regexps and augmenting them with #+BEGIN/END counterparts. That still relies on ignoring limits in the font locking function but from a cursory inspection I understand the framework is quite robust when you move the point further than allowed. Also, as I've said before, some border cases remain when the block is too large (larger than the jit chunk) and you break the ending delimiter, but nothing to worry about. Best regards -- Carlos