From: Lars Ingebrigtsen <larsi@gnus.org>
To: Joost Kremers <joost.kremers@phil.uni-goettingen.de>
Cc: 13917@debbugs.gnu.org
Subject: bug#13917: 24.3.50; Elisp manual: Font Lock Mode
Date: Fri, 01 Nov 2019 17:48:11 +0100 [thread overview]
Message-ID: <877e4jy244.fsf@gnus.org> (raw)
In-Reply-To: <87txojjjkq.fsf@phil.uni-goettingen.de> (Joost Kremers's message of "Sun, 10 Mar 2013 17:39:01 +0100")
Joost Kremers <joost.kremers@phil.uni-goettingen.de> writes:
> The Elisp manual, info node "(elisp) Search-based Fontification" states
> the following:
>
> ,----
> | `(MATCHER . FACESPEC)'
> | In this kind of element, FACESPEC is an expression whose value
> | specifies the face to use for highlighting. In the simplest case,
> | FACESPEC is a Lisp variable (a symbol) whose value is a face name.
> |
> | ;; Highlight occurrences of `fubar',
> | ;; using the face which is the value of `fubar-face'.
> | ("fubar" . fubar-face)
> |
> | However, FACESPEC can also evaluate to a list of this form:
> |
> | (face FACE PROP1 VAL1 PROP2 VAL2...)
> |
> | to specify the face FACE and various additional text properties to
> | put on the text that matches. If you do this, be sure to add the
> | other text property names that you set in this way to the value of
> | `font-lock-extra-managed-props' so that the properties will also
> | be cleared out when they are no longer appropriate. Alternatively,
> | you can set the variable `font-lock-unfontify-region-function' to
> | a function that clears these properties. *Note Other Font Lock
> | Variables::.
> `----
>
> However, a font lock entry of the type
>
> ,----
> | (MATCHER . (face FACE PROP1 VAL1 PROP1 VAL2))
> `----
>
> does not actually work. What works is any of the forms:
>
> ,----
> | (MATCHER . (0 (face FACE PROP1 VAL1 PROP1 VAL2)))
> | (MATCHER 0 (face FACE PROP1 VAL1 PROP1 VAL2))
> | (MATCHER (0 (face FACE PROP1 VAL1 PROP1 VAL2)))
> `----
>
> (Where the first two are of course equivalent).
Hm... is this a bug in the documentation or the code, though? It seems
like it would be logical for the described syntax to work, doesn't it?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2019-11-01 16:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 16:39 bug#13917: 24.3.50; Elisp manual: Font Lock Mode Joost Kremers
2019-11-01 16:48 ` Lars Ingebrigtsen [this message]
2021-05-31 6:40 ` Lars Ingebrigtsen
2021-05-31 12:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-01 5:57 ` Lars Ingebrigtsen
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=877e4jy244.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=13917@debbugs.gnu.org \
--cc=joost.kremers@phil.uni-goettingen.de \
/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.