From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: possible bug in anchored font-lock functions
Date: Sun, 11 Nov 2018 16:22:10 -0500 [thread overview]
Message-ID: <jwv5zx35n6n.fsf-monnier+gmane.emacs.devel@gnu.org> (raw)
In-Reply-To: 87r2frg078.fsf@gmail.com
> 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
prev parent reply other threads:[~2018-11-11 21:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-11 14:26 possible bug in anchored font-lock functions Sam Halliday
2018-11-11 15:43 ` Sam Halliday
2018-11-11 21:22 ` Stefan Monnier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv5zx35n6n.fsf-monnier+gmane.emacs.devel@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.