[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect
bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
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
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