GNU bug report logs - #18367
24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18367 in the body.
You can then email your comments to 18367 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from
 font-lock
Date: Sat, 30 Aug 2014 13:12:44 -0700 (PDT)

[Message part 1 (text/plain, inline)]

Bug or missing feature: Prevent font-lock from changing text
properties on text that has property `font-lock-ignore'.  See
http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00540.html

Patch attached.  ChangeLog entry:

2014-08-30 Drew Adams  <drew.adams <at> oracle.com>
	* font-lock.el: Respect text property `font-lock-ignore'.
        (put-text-property-unless-ignore): New function.
	(font-lock-default-unfontify-region): Do not unfontify if
	text has property `font-lock-ignore'.
	(font-lock-prepend-text-property, font-lock-append-text-property)
	(font-lock-fillin-text-property, font-lock-apply-syntactic-highlight)
	(font-lock-fontify-syntactically-region, font-lock-apply-highlight)
	(font-lock-fontify-anchored-keywords)
	(font-lock-fontify-keywords-region):
        Use put-text-property-unless-ignore, not put-text-property.

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-08-15 on LEG570
Bzr revision: 117706 rgm <at> gnu.org-20140815043406-p5hbu97cbm7pulcn
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

[font-lock-2014-08-30.patch (application/octet-stream, attachment)]

Message #8 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 18367 <at> debbugs.gnu.org
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Sun, 31 Aug 2014 08:47:33 -0400

> Bug or missing feature: Prevent font-lock from changing text
> properties on text that has property `font-lock-ignore'.  See
> http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00540.html

Could you add a short explanation for why font-lock-face is
not sufficient?


        Stefan

Message #11 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 18367 <at> debbugs.gnu.org
Subject: RE: bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to
 protect from font-lock
Date: Sun, 31 Aug 2014 08:30:54 -0700 (PDT)

> > Bug or missing feature: Prevent font-lock from changing text
> > properties on text that has property `font-lock-ignore'.  See
> > http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00540.html
> 
> Could you add a short explanation for why font-lock-face is
> not sufficient?

Sorry, but I don't know why it might be imagined sufficient.  Can
you hint how?  IOW, so far, I don't see how it is relevant at all.

If you could please hint how one might use `font-lock-face' to
protect ad hoc highlighting that uses `face', then I can perhaps
try to add a short explanation about that, if you think the bug
report is still relevant in that case.

But if you really think that `font-lock-face' is sufficient, then
why not just close the bug?  In that case, however, I would still
appreciate knowing how.

Trying to see what you might have in mind...

I see this in (elisp) `Font Lock Basics' about `font-lock-face':

 If your mode fontifies text explicitly by adding `font-lock-face'
 properties, it can specify `(nil t)' for `font-lock-defaults' to turn
 off all automatic fontification.  However, this is not required; it is
 possible to fontify some things using `font-lock-face' properties and
 set up automatic fontification for other parts of the text.

The last sentence sounds vaguely related (the first sentence seems
irrelevant).  But it says nothing about how you would do it, so I
don't really understand it.  And it presumably is, like the first
sentence, talking about some mode, whereas there is nothing about
any mode in the feature I described (ad hoc highlighting, whether
or not the buffer is font-locked).

I see this in (elisp) `Search-based Fontification':

 If it is `prepend', the face specified by FACESPEC is
 added to the beginning of the `font-lock-face' property.  If it is
 `append', the face is added to the end of the `font-lock-face'
 property.

That too tells me nothing about what the resulting behavior is, or
what `font-lock-face' is for.

(elisp) `Other Font Lock Variables' says this about it:

 Variable: font-lock-extra-managed-props
 This variable specifies additional properties (other than
 `font-lock-face') that are being managed by Font Lock mode.  It is
 used by `font-lock-default-unfontify-region', which normally only
 manages the `font-lock-face' property.  If you want Font Lock to
 manage other properties as well, you must specify them in a
 FACESPEC in `font-lock-keywords' as well as add them to this list.
 *Note Search-based Fontification::.

Again, I'm afraid that tells me nothing about what `font-lock-face'
is for or how to use it.  It seems to be saying only that
`font-lock-face' is removed by `font-lock-default-unfontify-region'
and you can change the var to have it also remove other properties.
(But the code of that function does not refer to `font-lock-face'
at all AFAICT (?).)  And it makes the vague statement that
`font-lock-face' is "managed by Font Lock mode", whatever that might
mean.

(elisp) `Precalculated Fontification' says this:

 Some major modes such as `list-buffers' and `occur' construct the
 buffer text programmatically.  The easiest way for them to support Font
 Lock mode is to specify the faces of text when they insert the text in
 the buffer.

 The way to do this is to specify the faces in the text with the
 special text property `font-lock-face' (*note Special Properties::).
 When Font Lock mode is enabled, this property controls the display,
 just like the `face' property.  When Font Lock mode is disabled,
 `font-lock-face' has no effect on the display.

 It is ok for a mode to use `font-lock-face' for some text and also
 use the normal Font Lock machinery.  But if the mode does not use the
 normal Font Lock machinery, it should not set the variable
 `font-lock-defaults'.

That says only (AFAICT) that if some text has property
`font-lock-face' then that property "controls the display, just
like the `face' property".  But it does not say what that means.
And it says that when font-lock is disabled, highlighting with
`font-lock-face' is also disabled, which is hardly the aim of the
feature I proposed.

That passage seems to correspond to what I have understood in the
past about `font-lock-face': It lets you use font-lock to highlight
text, i.e., to have some given highlighting handled by font-lock -
to let a major mode "support Font Lock mode".  That is opposite to
the feature I proposed, AFAICT.

Finally, we get to what is presumably the main place (e.g. indexed)
that `font-lock-face' is described, (elisp) `Special Properties':

 `font-lock-face'
 This property specifies a value for the `face' property that Font
 Lock mode should apply to the underlying text.  It is one of the
 fontification methods used by Font Lock mode, and is useful for
 special modes that implement their own highlighting.  *Note
 Precalculated Fontification::.  When Font Lock mode is disabled,
 `font-lock-face' has no effect.

That doesn't help me understand, I'm afraid.  AFAICT, all it says
is that `font-lock-face' is used like `face' by font-lock.  I don't
see how that text distinguishes it from `face', except in name.
(I know that it is distinguished, but that passage does not speak
to that.)

Coming to the code: Each occurrence of `font-lock-face' in
`font-lock.el' simply pairs it with `face', treating the two the
same way.  These are the only occurrences there:

font-lock.el:1378:      (and (memq prop '(face font-lock-face))
font-lock.el:1398:      (and (memq prop '(face font-lock-face))

If I look at how `font-lock-face' is used elsewhere in the code,
e.g. in `occur' (as suggested by (elisp) `Precalculated
Fontification'), it seems that the use case for it is to apply
a face to text in an ad hoc way (good), i.e., other than by using
`font-lock-keywords', and yet to have font-lock effect/control
that highlighting (bad, er, not the feature I have in mind).

And that is exactly what I have understood for `font-lock-face'
in the past:

You can apply it to text any way you like, without bothering
with `font-lock-keywords', and yet font-lock will "control" it:
turning font-lock on shows the highlighting; turning font-lock
off hides it.

IOW, AFAICT, it is a way to get font-lock to control additional
(e.g. ad hoc) highlighting, beyond the control provided by
`font-lock-keywords'.

Presumably the reason for using a different property from
`face' for this is so that font-lock does not turn on/off all
`face'-propertied text, in particular, so that `font-lock-mode'
need not be on for some `face'-propertied text to be highlighted.
Of course, that does not prevent font-lock from turning OFF
other highlighting, which is the point of the feature I proposed.

If I have understood correctly, giving font-lock control over
additional (e.g. non `font-lock-keywords') highlighting is what
`font-lock-face' is for.  And in that case it is opposite to the
feature I propose, which is to remove font-lock control over
given ad hoc highlighting.

Please let me know what I am missing or misunderstand.

Message #14 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 18367 <at> debbugs.gnu.org
Subject: Re: bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore',
 to protect from font-lock
Date: Sun, 31 Aug 2014 16:08:59 -0400

>> Could you add a short explanation for why font-lock-face is
>> not sufficient?
> Sorry, but I don't know why it might be imagined sufficient.

Can you please just answer the damn question?


        Stefan

Message #17 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 18367 <at> debbugs.gnu.org
Subject: RE: bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to
 protect from font-lock
Date: Sun, 31 Aug 2014 13:56:29 -0700 (PDT)

> >> Could you add a short explanation for why font-lock-face is
> >> not sufficient?
> >
> > Sorry, but I don't know why it might be imagined sufficient.
> 
> Can you please just answer the damn question?

Can you please control your nastiness?

I answered your "damn" question to the best of my ability, trying
to guess what you mean by it.  I do not claim to be an expert
on `font-lock-face', and I did not mention it in my bug report.

I have no idea why you think `font-lock-face' is sufficient
for the feature I requested - how (you think) it provides it.
I'm not a mind reader.

I listed several ways in which (I think) `font-lock-face' is
unrelated to the feature and does not provide it.  Apparently
that is not enough for you.

In that case, please say how you see `font-lock-face' as being
sufficient to provide the feature.  What, in your eyes, is
the relation between `font-lock-face' and the requested feature?

If you do that then I will hopefully understand what you have
in mind, and I will hopefully be able to show why I think you
are wrong (i.e., show why `font-lock-face' is not sufficient),
in the terms you will have expressed.

Or perhaps then I will agree with you that `font-lock-face'
is sufficient to realize the feature.  But without your saying
anything about what you mean, I cannot speak more to your vague
(and now nasty) inquiry.

So far, nothing from you - only heat, no light.

Message #20 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Jenkner <wjenkner <at> inode.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 18367 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Mon, 01 Sep 2014 20:45:58 +0200

On Sun, Aug 31 2014, Drew Adams wrote:

> (elisp) `Other Font Lock Variables' says this about it:
>
>  Variable: font-lock-extra-managed-props
>  This variable specifies additional properties (other than
>  `font-lock-face') that are being managed by Font Lock mode.  It is
>  used by `font-lock-default-unfontify-region', which normally only
>  manages the `font-lock-face' property.  If you want Font Lock to
>  manage other properties as well, you must specify them in a
>  FACESPEC in `font-lock-keywords' as well as add them to this list.
>  *Note Search-based Fontification::.

I think `font-lock-face' is a typo here (it should read `face').

It is clear from looking a the code (or doing some experiments) that
font-lock-default-unfontify-region doesn't remove the `font-lock-face'
property.

Wolfgang

Message #23 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wolfgang Jenkner <wjenkner <at> inode.at>
Cc: 18367 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Mon, 01 Sep 2014 22:08:03 +0300

> From: Wolfgang Jenkner <wjenkner <at> inode.at>
> Date: Mon, 01 Sep 2014 20:45:58 +0200
> Cc: 18367 <at> debbugs.gnu.org
> 
> On Sun, Aug 31 2014, Drew Adams wrote:
> 
> > (elisp) `Other Font Lock Variables' says this about it:
> >
> >  Variable: font-lock-extra-managed-props
> >  This variable specifies additional properties (other than
> >  `font-lock-face') that are being managed by Font Lock mode.  It is
> >  used by `font-lock-default-unfontify-region', which normally only
> >  manages the `font-lock-face' property.  If you want Font Lock to
> >  manage other properties as well, you must specify them in a
> >  FACESPEC in `font-lock-keywords' as well as add them to this list.
> >  *Note Search-based Fontification::.
> 
> I think `font-lock-face' is a typo here (it should read `face').
> 
> It is clear from looking a the code (or doing some experiments) that
> font-lock-default-unfontify-region doesn't remove the `font-lock-face'
> property.

The "it" in that text alludes to font-lock-extra-managed-props, not to
font-lock-face.  After all, the former is what is being documented in
the text you cited; the latter is just mentioned because
font-lock-face is another kind of specification of "additional"
properties of interest to Font Lock.

Message #26 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Jenkner <wjenkner <at> inode.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18367 <at> debbugs.gnu.org
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Mon, 01 Sep 2014 21:43:31 +0200

On Mon, Sep 01 2014, Eli Zaretskii wrote:

>> From: Wolfgang Jenkner <wjenkner <at> inode.at>
>> Date: Mon, 01 Sep 2014 20:45:58 +0200
>> Cc: 18367 <at> debbugs.gnu.org
>> 
>> On Sun, Aug 31 2014, Drew Adams wrote:
>> 
>> > (elisp) `Other Font Lock Variables' says this about it:
>> >
>> >  Variable: font-lock-extra-managed-props
>> >  This variable specifies additional properties (other than
>> >  `font-lock-face') that are being managed by Font Lock mode.  It is
>> >  used by `font-lock-default-unfontify-region', which normally only
>> >  manages the `font-lock-face' property.  If you want Font Lock to
>> >  manage other properties as well, you must specify them in a
>> >  FACESPEC in `font-lock-keywords' as well as add them to this list.
>> >  *Note Search-based Fontification::.
>> 
>> I think `font-lock-face' is a typo here (it should read `face').
>> 
>> It is clear from looking a the code (or doing some experiments) that
>> font-lock-default-unfontify-region doesn't remove the `font-lock-face'
>> property.
>
> The "it" in that text alludes to font-lock-extra-managed-props, not to
> font-lock-face.

I don't think the "it" is a problem here.

>  After all, the former is what is being documented in
> the text you cited; the latter is just mentioned because
> font-lock-face is another kind of specification of "additional"
> properties of interest to Font Lock.

But, `font-lock-face' is of no interest to
font-lock-default-unfontify-region, the `face' property is.

font-lock-default-unfontify-region does not remove the `font-lock-face'
property, it removes the `face' property.

font-lock-default-unfontify-region does not "manage" the
`font-lock-face' property, it "manages" the `face' property.

Sorry, for saying three times the same thing, but Drew cited this part
of the manual and it seems to be the reason why Stefan's request didn't
make sense to him.

Wolfgang

Message #29 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wolfgang Jenkner <wjenkner <at> inode.at>
Cc: 18367 <at> debbugs.gnu.org
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Mon, 01 Sep 2014 23:04:27 +0300

> From: Wolfgang Jenkner <wjenkner <at> inode.at>
> Cc: 18367 <at> debbugs.gnu.org
> Date: Mon, 01 Sep 2014 21:43:31 +0200
> 
> > The "it" in that text alludes to font-lock-extra-managed-props, not to
> > font-lock-face.
> 
> I don't think the "it" is a problem here.
> 
> >  After all, the former is what is being documented in
> > the text you cited; the latter is just mentioned because
> > font-lock-face is another kind of specification of "additional"
> > properties of interest to Font Lock.
> 
> But, `font-lock-face' is of no interest to
> font-lock-default-unfontify-region, the `face' property is.
> 
> font-lock-default-unfontify-region does not remove the `font-lock-face'
> property, it removes the `face' property.
> 
> font-lock-default-unfontify-region does not "manage" the
> `font-lock-face' property, it "manages" the `face' property.

The cited text says that font-lock-default-unfontify-region uses
font-lock-extra-managed-props.  That is all it says; all the rest is
just comments and references to related features
.

Message #32 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 18367 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Tue, 30 Sep 2014 18:45:30 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> > Bug or missing feature: Prevent font-lock from changing text
> > properties on text that has property `font-lock-ignore'.  See
> > http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00540.html
>
> Could you add a short explanation for why font-lock-face is
> not sufficient?

I'm not sure about that question.  But I see a problem in cases where
packages use the 'face property without using font-lock (e.g. Helm does
this in its Completions buffer) and other packages come and invoke
font-lock in such a buffer (like e.g. rainbow-delimiters does/did in
it's globalized mode).  In such a case, all the fontification with 'face
is erased.

I guess it is an error to use 'face in any buffer that could become
subject to font-locking caused by some mode or package.  If that's the
case - if it is recommended to use font-lock-face in all these
situations, we should say in the manual that 'face is dangerous to use
in such situations:

  (info "(elisp) Special Properties")

Michael.

Message #35 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: michael_heerdegen <at> web.de, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 18367 <at> debbugs.gnu.org
Subject: RE: bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to
 protect from font-lock
Date: Tue, 30 Sep 2014 10:14:31 -0700 (PDT)

> > > Bug or missing feature: Prevent font-lock from changing text
> > > properties on text that has property `font-lock-ignore'.  See
> > > http://lists.gnu.org/archive/html/emacs-devel/2014-
> > > 08/msg00540.html
> >
> > Could you add a short explanation for why font-lock-face is
> > not sufficient?
> 
> I'm not sure about that question.  But I see a problem in cases
> where packages use the 'face property without using font-lock...
> and other packages come and invoke font-lock in such a buffer....
> In such a case, all the fontification with 'face is erased.
> 
> I guess it is an error to use 'face in any buffer that could become
> subject to font-locking caused by some mode or package.  If that's
> the case - if it is recommended to use font-lock-face in all these
> situations, we should say in the manual that 'face is dangerous to
> use in such situations: (info "(elisp) Special Properties")

It should not be "an error" to use `face' in a font-locked buffer.

That's precisely the problem, IMO: Font-lock has taken over property
`face'.  That's not right.  It does not (should not) own `face'.
There should at least be a simple way to say "Hands off this
occurrence of `face'!"

Message #38 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: michael_heerdegen <at> web.de, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 18367 <at> debbugs.gnu.org
Subject: RE: bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to
 protect from font-lock
Date: Sat, 20 Jun 2015 09:58:20 -0700 (PDT)

Let me try refreshing this.

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.

It is not.  I stated the essential difference in the emacs-devel
thread that is associated with this bug:
http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00583.html

  What I am talking about is the opposite: 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'.

And we can also do that already by adding a given property to
`font-lock-extra-managed-props'.

The point of the patch I sent is to let you really tell font-lock
"hands-off" anywhere you like, i.e., make it so that font-lock-mode
has no effect on the given text.

Again: "I don't want turning font-lock on or off to affect the given
highlighting at all."

So how about it?  How about applying the simple code change that
fixes this?

Message #41 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, 18367 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Sat, 30 Apr 2016 15:44:52 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #48 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, 18367 <at> debbugs.gnu.org
Subject: Re: bug#18367: 24.4.50;
 [PATCH] Text property `font-lock-ignore', to protect from font-lock
Date: Sat, 30 Apr 2016 10:28:58 -0400

> It should not be "an error" to use `face' in a font-locked buffer.

FWIW, I agree.  That's a big part of the motivation behind my proposal
to add

   *** Several text-property planes

in etc/TODO.  But currently the only "solution" to the above problem is
`font-lock-face` (tho it only solves the problem if it's OK for your face
to be disabled when font-lock-mode is disabled).


        Stefan

Message #51 received at 18367 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: michael_heerdegen <at> web.de, 18367 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: 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)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.