* 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 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
* 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
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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.