[Top][All Lists]

[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

From: Drew Adams
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)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]