From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: possible bug in anchored font-lock functions Date: Sun, 11 Nov 2018 16:22:10 -0500 Message-ID: References: <87r2frg078.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1541971242 32628 195.159.176.226 (11 Nov 2018 21:20:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Nov 2018 21:20:42 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 11 22:20:38 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gLx9o-0008Lh-MW for ged-emacs-devel@m.gmane.org; Sun, 11 Nov 2018 22:20:36 +0100 Original-Received: from localhost ([::1]:43685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLxBv-0005RI-1n for ged-emacs-devel@m.gmane.org; Sun, 11 Nov 2018 16:22:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLxBm-0005Kd-1y for emacs-devel@gnu.org; Sun, 11 Nov 2018 16:22:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLxBi-0006wN-18 for emacs-devel@gnu.org; Sun, 11 Nov 2018 16:22:37 -0500 Original-Received: from [195.159.176.226] (port=58504 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLxBh-0006sJ-CF for emacs-devel@gnu.org; Sun, 11 Nov 2018 16:22:33 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gLx9K-0007nV-JL for emacs-devel@gnu.org; Sun, 11 Nov 2018 22:20:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 33 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:ZoyGBgm/4NdC9YlMmdhZIQCENJI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231078 Archived-At: > However, if I use an an `anchored` matcher, having the form `(matcher . > anchored-highlighter)`, where the `anchored-highlighter` is a > `function`, my custom `font-lock-{beg,end}` regions are ignored and > `limit` is much reduced! Of course: the anchored matcher is for use within a particular subregion. By default, this subregion is the text between where MATCHER matched and end-of-line. > Further to this, I think I've tracked the issue to > `font-lock-fontify-anchored-keywords` which is called with a `limit` > parameter, but then `limit` is mutated very intentionally to the limit > generated by the outer matcher... so I think this is NOT a bug, but > just different behaviour to what I expected. i.e. the first pattern > resets the limit for the anchored highlighters. The docstring of font-lock-keywords explains the following: [...] The above-mentioned exception is as follows. The limit of the MATCHER search defaults to the end of the line after PRE-MATCH-FORM is evaluated. However, if PRE-MATCH-FORM returns a position greater than the position after PRE-MATCH-FORM is evaluated, that position is used as the limit of the search. It is generally a bad idea to return a position greater than the end of the line, i.e., cause the MATCHER search to span lines. [...] Of "bad idea" doesn't mean it can't work, but it comes with the usual caveat for multiline matches. Stefan