[Top][All Lists]

[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

> 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.


reply via email to

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