From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: regexp font-lock highlighting Date: Mon, 06 Jun 2005 11:33:34 +0200 Message-ID: <42A4186E.1080902@gmx.at> References: <429AD1B5.1020408@gmx.at> <42A16247.7010204@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1118051895 7085 80.91.229.2 (6 Jun 2005 09:58:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Jun 2005 09:58:15 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 06 11:58:06 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DfELq-0004Ow-GH for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2005 11:56:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfES8-0000Be-8w for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2005 06:03:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DfEPP-00081M-IZ for emacs-devel@gnu.org; Mon, 06 Jun 2005 06:00:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DfEPM-0007z0-Dy for emacs-devel@gnu.org; Mon, 06 Jun 2005 06:00:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfEPK-0007we-5t for emacs-devel@gnu.org; Mon, 06 Jun 2005 06:00:34 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1DfEPf-00069g-Ss for emacs-devel@gnu.org; Mon, 06 Jun 2005 06:00:56 -0400 Original-Received: (qmail invoked by alias); 06 Jun 2005 09:31:02 -0000 Original-Received: from N957P003.adsl.highway.telekom.at (EHLO [62.47.63.131]) [62.47.63.131] by mail.gmx.net (mp016) with SMTP; 06 Jun 2005 11:31:02 +0200 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: rms@gnu.org In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:38154 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38154 > Note that I only fixed the endless looping behavior here. My code is > not suitable when you use a support mode like jit-lock and change the > delimiters of regexp groups. > > I don't understand that last sentence. What does it mean to "change > the delimiters of regexp groups"? Could you please show us a concrete > test case that still has a problem--and describe the problem exactly? > Sorry, I couldn't understand that sentence either. It's not so easy to show a concrete test case since the problem depends on the particular settings of font-lock and jit-lock. Consider the following stretch from `tex-mode.el'. (setq paragraph-start (concat "[ \t]*\\(\\$\\$\\|" "\\\\[][]\\|" "\\\\" (regexp-opt (append (mapcar 'car latex-section-alist) '("begin" "label" "end" "item" "bibitem" "newline" "noindent" "newpage" "footnote" "marginpar" "parbox" "caption")) t) "\\>\\|\\\\[a-z]*" (regexp-opt '("space" "skip" "page") t) "\\>\\)")) Here the innermost group delimited by "\\(" and "\\)" stretches from the second to the last line and should get painted accordingly. If you now delete the "\\)" the painting should disappear. If you next undo the change, the painting generally doesn't reappear since font-lock refontifies from the line preceding the one where the change occurred - with `font-lock-lines-before' at its default value - only. The reason for this is documented in the Elisp manual: *Warning:* Do not design an element of `font-lock-keywords' to match text which spans lines; this does not work reliably. While `font-lock-fontify-buffer' handles multi-line patterns correctly, updating when you edit the buffer does not, since it considers text one line at a time. If you have patterns that typically only span one line but can occasionally span two or three, such as `...', you can ask Font Lock to be more careful by setting `font-lock-multiline' to `t'. But it still will not work in all cases. I could avoid painting regexp groups that span multiple lines, but this would deprive me from highlighting many interesting things. I could set `font-lock-lines-before' to a higher value but this would slow down fontification in general and still not handle all cases. Anyway, I believe that I found a solution that does the right thing in most cases and will send it to you in the next days.