emacs-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]