From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: michael_heerdegen@web.de, 18367@debbugs.gnu.org,
Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Sat, 30 Apr 2016 08:32:43 -0800 (GMT-08:00) [thread overview]
Message-ID: <d69e60e2-66ed-444f-9aa3-4c7eae184b8b@default> (raw)
In-Reply-To: <87zisbqkh7.fsf@gnus.org>
> > It should not be "an error" to use `face' in a font-locked buffer.
>
> I think that ship has sailed a long time ago. Closing.
It has not sailed. The patch does not take anything away from
the use of `font-lock-face' or `font-lock-extra-managed-props'.
It just adds additional control, and it does so simply.
As stated earlier:
It seems that people are mistaking adding a property to
`font-lock-extra-managed-props', or using `font-lock-face'
instead of `face', as a solution to the problem that the
proposed patch fixes.
They do not solve the same problem. This problem and
solution are independent of the problem and solution
behind the existence of `font-lock-face' and
`font-lock-extra-managed-props'.
What I am talking about is the opposite [of using
`font-lock-face' or `font-lock-extra-managed-props']:
Not giving font-lock control over additional, ad hoc
highlighting, but taking font-lock control away, for
given ad hoc highlighting. I don't want turning font-lock
on or off to affect the given highlighting at all.
That's the point. It's not that I'm looking for a way
to let font-lock control some non-`font-lock-keywords'
highlighting. That we can do already, using property
`font-lock-face' [or by adding a given property to
`font-lock-extra-managed-props'].
next prev parent reply other threads:[~2016-04-30 16:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-30 20:12 bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock Drew Adams
2014-08-31 12:47 ` Stefan Monnier
2014-08-31 15:30 ` Drew Adams
2014-08-31 20:08 ` Stefan Monnier
2014-08-31 20:56 ` Drew Adams
2014-09-01 18:45 ` Wolfgang Jenkner
2014-09-01 19:08 ` Eli Zaretskii
2014-09-01 19:43 ` Wolfgang Jenkner
2014-09-01 20:04 ` Eli Zaretskii
2014-09-30 16:45 ` Michael Heerdegen
2014-09-30 17:14 ` Drew Adams
2015-06-20 16:58 ` Drew Adams
2016-04-30 13:44 ` Lars Ingebrigtsen
2016-04-30 16:32 ` Drew Adams [this message]
2016-04-30 14:28 ` Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d69e60e2-66ed-444f-9aa3-4c7eae184b8b@default \
--to=drew.adams@oracle.com \
--cc=18367@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=michael_heerdegen@web.de \
--cc=monnier@iro.umontreal.ca \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).