all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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




      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.