* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
@ 2014-08-30 20:12 Drew Adams
2014-08-31 12:47 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Drew Adams @ 2014-08-30 20:12 UTC (permalink / raw)
To: 18367
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
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@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@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'
[-- Attachment #2: font-lock-2014-08-30.patch --]
[-- Type: application/octet-stream, Size: 13295 bytes --]
diff -c font-lock.el font-lock-patched-2014-08-30.el
*** font-lock.el Sat Aug 30 10:19:26 2014
--- font-lock-patched-2014-08-30.el Sat Aug 30 11:45:52 2014
***************
*** 1236,1249 ****
what properties to clear before refontifying a region.")
(defun font-lock-default-unfontify-region (beg end)
! "Unfontify the text between BEG and END.
! This function is the default `font-lock-unfontify-region-function'."
! (remove-list-of-text-properties
! beg end (append
! font-lock-extra-managed-props
! (if font-lock-syntactic-keywords
! '(syntax-table face font-lock-multiline)
! '(face font-lock-multiline)))))
;; Called when any modification is made to buffer text.
(defun font-lock-after-change-function (beg end &optional old-len)
--- 1236,1254 ----
what properties to clear before refontifying a region.")
(defun font-lock-default-unfontify-region (beg end)
! "Unfontify from BEG to END, except text with property `font-lock-ignore'."
! (let ((here (min beg end))
! (end1 (max beg end))
! chg)
! (while (< here end1)
! (setq chg (next-single-property-change here 'font-lock-ignore nil end1))
! (unless (get-text-property here 'font-lock-ignore)
! (remove-list-of-text-properties
! here chg (append font-lock-extra-managed-props
! (if font-lock-syntactic-keywords
! '(syntax-table face font-lock-multiline)
! '(face font-lock-multiline)))))
! (setq here chg))))
;; Called when any modification is made to buffer text.
(defun font-lock-after-change-function (beg end &optional old-len)
***************
*** 1380,1388 ****
(or (keywordp (car prev))
(memq (car prev) '(foreground-color background-color)))
(setq prev (list prev)))
! (put-text-property start next prop
! (append val (if (listp prev) prev (list prev)))
! object)
(setq start next))))
(defun font-lock-append-text-property (start end prop value &optional object)
--- 1385,1393 ----
(or (keywordp (car prev))
(memq (car prev) '(foreground-color background-color)))
(setq prev (list prev)))
! (put-text-property-unless-ignore start next prop
! (append val (if (listp prev) prev (list prev)))
! object)
(setq start next))))
(defun font-lock-append-text-property (start end prop value &optional object)
***************
*** 1400,1408 ****
(or (keywordp (car prev))
(memq (car prev) '(foreground-color background-color)))
(setq prev (list prev)))
! (put-text-property start next prop
! (append (if (listp prev) prev (list prev)) val)
! object)
(setq start next))))
(defun font-lock-fillin-text-property (start end prop value &optional object)
--- 1405,1413 ----
(or (keywordp (car prev))
(memq (car prev) '(foreground-color background-color)))
(setq prev (list prev)))
! (put-text-property-unless-ignore start next prop
! (append (if (listp prev) prev (list prev)) val)
! object)
(setq start next))))
(defun font-lock-fillin-text-property (start end prop value &optional object)
***************
*** 1413,1419 ****
(let ((start (text-property-any start end prop nil object)) next)
(while start
(setq next (next-single-property-change start prop object end))
! (put-text-property start next prop value object)
(setq start (text-property-any next end prop nil object)))))
;; For completeness: this is to `remove-text-properties' as `put-text-property'
--- 1418,1424 ----
(let ((start (text-property-any start end prop nil object)) next)
(while start
(setq next (next-single-property-change start prop object end))
! (put-text-property-unless-ignore start next prop value object)
(setq start (text-property-any next end prop nil object)))))
;; For completeness: this is to `remove-text-properties' as `put-text-property'
***************
*** 1480,1495 ****
;; still be necessary for other users of syntax-ppss anyway.
(syntax-ppss-after-change-function start)
(cond
! ((not override)
! ;; Cannot override existing fontification.
! (or (text-property-not-all start end 'syntax-table nil)
! (put-text-property start end 'syntax-table value)))
! ((eq override t)
! ;; Override existing fontification.
! (put-text-property start end 'syntax-table value))
! ((eq override 'keep)
! ;; Keep existing fontification.
! (font-lock-fillin-text-property start end 'syntax-table value))))))
(defun font-lock-fontify-syntactic-anchored-keywords (keywords limit)
"Fontify according to KEYWORDS until LIMIT.
--- 1485,1500 ----
;; still be necessary for other users of syntax-ppss anyway.
(syntax-ppss-after-change-function start)
(cond
! ((not override)
! ;; Cannot override existing fontification.
! (or (text-property-not-all start end 'syntax-table nil)
! (put-text-property-unless-ignore start end 'syntax-table value)))
! ((eq override t)
! ;; Override existing fontification.
! (put-text-property-unless-ignore start end 'syntax-table value))
! ((eq override 'keep)
! ;; Keep existing fontification.
! (font-lock-fillin-text-property start end 'syntax-table value))))))
(defun font-lock-fontify-syntactic-anchored-keywords (keywords limit)
"Fontify according to KEYWORDS until LIMIT.
***************
*** 1585,1591 ****
(setq beg (max (nth 8 state) start))
(setq state (parse-partial-sexp (point) end nil nil state
'syntax-table))
! (when face (put-text-property beg (point) 'face face))
(when (and (eq face 'font-lock-comment-face)
(or font-lock-comment-start-skip
comment-start-skip))
--- 1590,1596 ----
(setq beg (max (nth 8 state) start))
(setq state (parse-partial-sexp (point) end nil nil state
'syntax-table))
! (when face (put-text-property-unless-ignore beg (point) 'face face))
(when (and (eq face 'font-lock-comment-face)
(or font-lock-comment-start-skip
comment-start-skip))
***************
*** 1595,1604 ****
(goto-char beg)
(if (looking-at (or font-lock-comment-start-skip
comment-start-skip))
! (put-text-property beg (match-end 0) 'face
font-lock-comment-delimiter-face)))
(if (looking-back comment-end-regexp (point-at-bol) t)
! (put-text-property (match-beginning 0) (point) 'face
font-lock-comment-delimiter-face))))
(< (point) end))
(setq state (parse-partial-sexp (point) end nil nil state
--- 1600,1609 ----
(goto-char beg)
(if (looking-at (or font-lock-comment-start-skip
comment-start-skip))
! (put-text-property-unless-ignore beg (match-end 0) 'face
font-lock-comment-delimiter-face)))
(if (looking-back comment-end-regexp (point-at-bol) t)
! (put-text-property-unless-ignore (match-beginning 0) (point) 'face
font-lock-comment-delimiter-face))))
(< (point) end))
(setq state (parse-partial-sexp (point) end nil nil state
***************
*** 1632,1641 ****
((not override)
;; Cannot override existing fontification.
(or (text-property-not-all start end 'face nil)
! (put-text-property start end 'face val)))
((eq override t)
;; Override existing fontification.
! (put-text-property start end 'face val))
((eq override 'prepend)
;; Prepend to existing fontification.
(font-lock-prepend-text-property start end 'face val))
--- 1637,1646 ----
((not override)
;; Cannot override existing fontification.
(or (text-property-not-all start end 'face nil)
! (put-text-property-unless-ignore start end 'face val)))
((eq override t)
;; Override existing fontification.
! (put-text-property-unless-ignore start end 'face val))
((eq override 'prepend)
;; Prepend to existing fontification.
(font-lock-prepend-text-property start end 'face val))
***************
*** 1661,1671 ****
(when (and font-lock-multiline (>= limit (line-beginning-position 2)))
;; this is a multiline anchored match
;; (setq font-lock-multiline t)
! (put-text-property (if (= limit (line-beginning-position 2))
! (1- limit)
! (min lead-start (point)))
! limit
! 'font-lock-multiline t)))
(save-match-data
;; Find an occurrence of `matcher' before `limit'.
(while (and (< (point) limit)
--- 1666,1676 ----
(when (and font-lock-multiline (>= limit (line-beginning-position 2)))
;; this is a multiline anchored match
;; (setq font-lock-multiline t)
! (put-text-property-unless-ignore (if (= limit (line-beginning-position 2))
! (1- limit)
! (min lead-start (point)))
! limit
! 'font-lock-multiline t)))
(save-match-data
;; Find an occurrence of `matcher' before `limit'.
(while (and (< (point) limit)
***************
*** 1707,1735 ****
(funcall matcher end))
;; Beware empty string matches since they will
;; loop indefinitely.
! (or (> (point) (match-beginning 0))
! (progn (forward-char 1) t)))
! (when (and font-lock-multiline
! (>= (point)
! (save-excursion (goto-char (match-beginning 0))
! (forward-line 1) (point))))
! ;; this is a multiline regexp match
! ;; (setq font-lock-multiline t)
! (put-text-property (if (= (point)
! (save-excursion
! (goto-char (match-beginning 0))
! (forward-line 1) (point)))
! (1- (point))
! (match-beginning 0))
! (point)
! 'font-lock-multiline t))
! ;; Apply each highlight to this instance of `matcher', which may be
! ;; specific highlights or more keywords anchored to `matcher'.
! (setq highlights (cdr keyword))
! (while highlights
! (if (numberp (car (car highlights)))
! (font-lock-apply-highlight (car highlights))
! (set-marker pos (point))
(font-lock-fontify-anchored-keywords (car highlights) end)
;; Ensure forward progress. `pos' is a marker because anchored
;; keyword may add/delete text (this happens e.g. in grep.el).
--- 1712,1738 ----
(funcall matcher end))
;; Beware empty string matches since they will
;; loop indefinitely.
! (or (> (point) (match-beginning 0)) (progn (forward-char 1) t)))
! (when (and font-lock-multiline
! (>= (point) (save-excursion (goto-char (match-beginning 0))
! (forward-line 1) (point))))
! ;; this is a multiline regexp match
! ;; (setq font-lock-multiline t)
! (put-text-property-unless-ignore (if (= (point)
! (save-excursion
! (goto-char (match-beginning 0))
! (forward-line 1) (point)))
! (1- (point))
! (match-beginning 0))
! (point)
! 'font-lock-multiline t))
! ;; Apply each highlight to this instance of `matcher', which may be
! ;; specific highlights or more keywords anchored to `matcher'.
! (setq highlights (cdr keyword))
! (while highlights
! (if (numberp (car (car highlights)))
! (font-lock-apply-highlight (car highlights))
! (set-marker pos (point))
(font-lock-fontify-anchored-keywords (car highlights) end)
;; Ensure forward progress. `pos' is a marker because anchored
;; keyword may add/delete text (this happens e.g. in grep.el).
***************
*** 1742,1747 ****
--- 1745,1761 ----
\f
;; Various functions.
+ (defun put-text-property-unless-ignore (start end property value &optional object)
+ "`put-text-property', but ignore text with property `font-lock-ignore'."
+ (let ((here (min start end))
+ (end1 (max start end))
+ chg)
+ (while (< here end1)
+ (setq chg (next-single-property-change here 'font-lock-ignore object end1))
+ (unless (get-text-property here 'font-lock-ignore object)
+ (put-text-property here chg property value object))
+ (setq here chg))))
+
(defun font-lock-compile-keywords (keywords &optional syntactic-keywords)
"Compile KEYWORDS into the form (t KEYWORDS COMPILED...)
Here each COMPILED is of the form (MATCHER HIGHLIGHT ...) as shown in the
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
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-09-30 16:45 ` Michael Heerdegen
0 siblings, 2 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-08-31 12:47 UTC (permalink / raw)
To: Drew Adams; +Cc: 18367
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-08-31 12:47 ` Stefan Monnier
@ 2014-08-31 15:30 ` Drew Adams
2014-08-31 20:08 ` Stefan Monnier
2014-09-01 18:45 ` Wolfgang Jenkner
2014-09-30 16:45 ` Michael Heerdegen
1 sibling, 2 replies; 15+ messages in thread
From: Drew Adams @ 2014-08-31 15:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 18367
> > 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
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
1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-08-31 20:08 UTC (permalink / raw)
To: Drew Adams; +Cc: 18367
>> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-08-31 20:08 ` Stefan Monnier
@ 2014-08-31 20:56 ` Drew Adams
0 siblings, 0 replies; 15+ messages in thread
From: Drew Adams @ 2014-08-31 20:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 18367
> >> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-08-31 15:30 ` Drew Adams
2014-08-31 20:08 ` Stefan Monnier
@ 2014-09-01 18:45 ` Wolfgang Jenkner
2014-09-01 19:08 ` Eli Zaretskii
1 sibling, 1 reply; 15+ messages in thread
From: Wolfgang Jenkner @ 2014-09-01 18:45 UTC (permalink / raw)
To: Drew Adams; +Cc: 18367
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-09-01 18:45 ` Wolfgang Jenkner
@ 2014-09-01 19:08 ` Eli Zaretskii
2014-09-01 19:43 ` Wolfgang Jenkner
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-09-01 19:08 UTC (permalink / raw)
To: Wolfgang Jenkner; +Cc: 18367
> From: Wolfgang Jenkner <wjenkner@inode.at>
> Date: Mon, 01 Sep 2014 20:45:58 +0200
> Cc: 18367@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-09-01 19:08 ` Eli Zaretskii
@ 2014-09-01 19:43 ` Wolfgang Jenkner
2014-09-01 20:04 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Wolfgang Jenkner @ 2014-09-01 19:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 18367
On Mon, Sep 01 2014, Eli Zaretskii wrote:
>> From: Wolfgang Jenkner <wjenkner@inode.at>
>> Date: Mon, 01 Sep 2014 20:45:58 +0200
>> Cc: 18367@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-09-01 19:43 ` Wolfgang Jenkner
@ 2014-09-01 20:04 ` Eli Zaretskii
0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2014-09-01 20:04 UTC (permalink / raw)
To: Wolfgang Jenkner; +Cc: 18367
> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: 18367@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
.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-08-31 12:47 ` Stefan Monnier
2014-08-31 15:30 ` Drew Adams
@ 2014-09-30 16:45 ` Michael Heerdegen
2014-09-30 17:14 ` Drew Adams
1 sibling, 1 reply; 15+ messages in thread
From: Michael Heerdegen @ 2014-09-30 16:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 18367
Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-09-30 16:45 ` Michael Heerdegen
@ 2014-09-30 17:14 ` Drew Adams
2015-06-20 16:58 ` Drew Adams
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Drew Adams @ 2014-09-30 17:14 UTC (permalink / raw)
To: michael_heerdegen, Stefan Monnier; +Cc: 18367
> > > 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'!"
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-09-30 17:14 ` Drew Adams
@ 2015-06-20 16:58 ` Drew Adams
2016-04-30 13:44 ` Lars Ingebrigtsen
2016-04-30 14:28 ` Stefan Monnier
2 siblings, 0 replies; 15+ messages in thread
From: Drew Adams @ 2015-06-20 16:58 UTC (permalink / raw)
To: michael_heerdegen, Stefan Monnier; +Cc: 18367
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
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
2016-04-30 14:28 ` Stefan Monnier
2 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-30 13:44 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen, 18367, Stefan Monnier
Drew Adams <drew.adams@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2014-09-30 17:14 ` Drew Adams
2015-06-20 16:58 ` Drew Adams
2016-04-30 13:44 ` Lars Ingebrigtsen
@ 2016-04-30 14:28 ` Stefan Monnier
2 siblings, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2016-04-30 14:28 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen, 18367
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#18367: 24.4.50; [PATCH] Text property `font-lock-ignore', to protect from font-lock
2016-04-30 13:44 ` Lars Ingebrigtsen
@ 2016-04-30 16:32 ` Drew Adams
0 siblings, 0 replies; 15+ messages in thread
From: Drew Adams @ 2016-04-30 16:32 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: michael_heerdegen, 18367, Stefan Monnier
> > 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'].
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-04-30 16:32 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2016-04-30 14:28 ` Stefan Monnier
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).