[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possible bug in anchored font-lock functions
From: |
Stefan Monnier |
Subject: |
Re: possible bug in anchored font-lock functions |
Date: |
Sun, 11 Nov 2018 16:22:10 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> 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