9:53 p.m.
Can anybody explain to me the intention of the ***marked** line in the
code fragment below?
(defvar compilation-font-lock-keywords (purecopy
(list
'("^[-_.\"A-Za-z0-9/+]+\\(:\\|, line \\)[0-9]+:
\\([wW]arning:\\).*$" .
font-lock-keyword-face)
'("^[-_.\"A-Za-z0-9/+]+\\(: *\\|, line \\)[0-9]+:.*$" .
font-lock-function-name-face)
***'("^[^:\n]+-[a-zA-Z][^:\n]+$" . font-lock-doc-string-face)***
'("\\(^[-_.\"A-Za-z0-9/+]+\\)\\(: *\\|, line \\)[0-9]+" 1
font-lock-string-face t)
'("^[-_.\"A-Za-z0-9/+]+\\(: *[0-9]+\\|, line [0-9]+\\)" 1 bold t)
))
"Additional expressions to highlight in Compilation mode.")
Seems to me that this winds up highlighting WAY too much
stuff... pretty much any line with a hyphen in it, and no colons.
It winds up giving ugly results - for instance, if you do a recursive
make, and some directory names have hyphens, you get messages like
Entering foo-bar
getting highlighted, but messages like
Entering baz
are not, it just winds up looking inconsistent and random. I'd like
to remove this piece of compilation-font-lock-keywords, but I'd like
to understand why it's there, first.
8:21 a.m.
well, you got me motivated to clean stuff up a bit.
Charles G Waldman wrote:
Can anybody explain to me the intention of the ***marked** line in
the
code fragment below?
(defvar compilation-font-lock-keywords (purecopy
(list
'("^[-_.\"A-Za-z0-9/+]+\\(:\\|, line \\)[0-9]+:
\\([wW]arning:\\).*$" .
font-lock-keyword-face)
'("^[-_.\"A-Za-z0-9/+]+\\(: *\\|, line \\)[0-9]+:.*$" .
font-lock-function-name-face)
***'("^[^:\n]+-[a-zA-Z][^:\n]+$" . font-lock-doc-string-face)***
'("\\(^[-_.\"A-Za-z0-9/+]+\\)\\(: *\\|, line \\)[0-9]+" 1
font-lock-string-face t)
'("^[-_.\"A-Za-z0-9/+]+\\(: *[0-9]+\\|, line [0-9]+\\)" 1 bold t)
))
"Additional expressions to highlight in Compilation mode.")
Seems to me that this winds up highlighting WAY too much
stuff... pretty much any line with a hyphen in it, and no colons.
It winds up giving ugly results - for instance, if you do a recursive
make, and some directory names have hyphens, you get messages like
Entering foo-bar
getting highlighted, but messages like
Entering baz
are not, it just winds up looking inconsistent and random. I'd like
to remove this piece of compilation-font-lock-keywords, but I'd like
to understand why it's there, first.
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
Index: ChangeLog
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/ChangeLog,v
retrieving revision 1.156.2.374
diff -u -r1.156.2.374 ChangeLog
--- ChangeLog 2000/06/13 03:17:11 1.156.2.374
+++ ChangeLog 2000/07/07 07:19:37
＠＠ -1,3 +1,9 ＠＠
+2000-07-07 Ben Wing <ben(a)xemacs.org>
+
+ * font-lock.el (defvar font-lock-*-face): Removed.
+ * font-lock.el (font-lock-apply-highlight): Bind these face vars
+ only when necessary.
+
2000-06-08 Mike Alexander <mta(a)arbortext.com>
* code-process.el (call-process-region): If there is no coding
Index: font-lock.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/font-lock.el,v
retrieving revision 1.7.2.17
diff -u -r1.7.2.17 font-lock.el
--- font-lock.el 2000/05/25 06:12:29 1.7.2.17
+++ font-lock.el 2000/07/07 07:19:38
＠＠ -339,7 +339,7 ＠＠
MATCH :== An integer match subexpression number from MATCHER.
FACE-FORM :== The symbol naming a defined face.
- | Expression whos value is the face name to use. If you
+ | Expression whose value is the face name to use. If you
want FACE-FORM to be a symbol that evaluates to a face,
use a form like \"(progn sym)\".
＠＠ -578,28 +578,6 ＠＠
;;; Initialization of faces.
-;; #### barf gag retch. Horrid FSF lossage that we need to
-;; keep around for compatibility with font-lock-keywords that
-;; forget to properly quote their faces.
-(defvar font-lock-comment-face 'font-lock-comment-face
- "Don't even think of using this.")
-(defvar font-lock-doc-string-face 'font-lock-doc-string-face
- "Don't even think of using this.")
-(defvar font-lock-string-face 'font-lock-string-face
- "Don't even think of using this.")
-(defvar font-lock-keyword-face 'font-lock-keyword-face
- "Don't even think of using this.")
-(defvar font-lock-function-name-face 'font-lock-function-name-face
- "Don't even think of using this.")
-(defvar font-lock-variable-name-face 'font-lock-variable-name-face
- "Don't even think of using this.")
-(defvar font-lock-type-face 'font-lock-type-face
- "Don't even think of using this.")
-(defvar font-lock-reference-face 'font-lock-reference-face
- "Don't even think of using this.")
-(defvar font-lock-preprocessor-face 'font-lock-preprocessor-face
- "Don't even think of using this.")
-
(defconst font-lock-face-list
'(font-lock-comment-face
font-lock-string-face
＠＠ -1446,7 +1424,24 ＠＠
(override (nth 2 highlight)))
(let ((newface (nth 1 highlight)))
(or (symbolp newface)
- (setq newface (eval newface)))
+ (setq newface
+ ;; FSF lossage. Face names are defvarred to
+ ;; themselves. Ugly ugly ugly. We used to have the
+ ;; defvars ourselves, but doing it this way is much
+ ;; cleaner.
+ (let ((font-lock-comment-face 'font-lock-comment-face)
+ (font-lock-doc-string-face 'font-lock-doc-string-face)
+ (font-lock-string-face 'font-lock-string-face)
+ (font-lock-keyword-face 'font-lock-keyword-face)
+ (font-lock-function-name-face
+ 'font-lock-function-name-face)
+ (font-lock-variable-name-face
+ 'font-lock-variable-name-face)
+ (font-lock-type-face 'font-lock-type-face)
+ (font-lock-reference-face 'font-lock-reference-face)
+ (font-lock-preprocessor-face
+ 'font-lock-preprocessor-face))
+ (eval newface))))
(cond ((not start)
;; No match but we might not signal an error.
(or (nth 3 highlight)
8:21 a.m.
looks bogus. just comment it out with an explanation.
Charles G Waldman wrote:
Can anybody explain to me the intention of the ***marked** line in
the
code fragment below?
(defvar compilation-font-lock-keywords (purecopy
(list
'("^[-_.\"A-Za-z0-9/+]+\\(:\\|, line \\)[0-9]+:
\\([wW]arning:\\).*$" .
font-lock-keyword-face)
'("^[-_.\"A-Za-z0-9/+]+\\(: *\\|, line \\)[0-9]+:.*$" .
font-lock-function-name-face)
***'("^[^:\n]+-[a-zA-Z][^:\n]+$" . font-lock-doc-string-face)***
'("\\(^[-_.\"A-Za-z0-9/+]+\\)\\(: *\\|, line \\)[0-9]+" 1
font-lock-string-face t)
'("^[-_.\"A-Za-z0-9/+]+\\(: *[0-9]+\\|, line [0-9]+\\)" 1 bold t)
))
"Additional expressions to highlight in Compilation mode.")
Seems to me that this winds up highlighting WAY too much
stuff... pretty much any line with a hyphen in it, and no colons.
It winds up giving ugly results - for instance, if you do a recursive
make, and some directory names have hyphens, you get messages like
Entering foo-bar
getting highlighted, but messages like
Entering baz
are not, it just winds up looking inconsistent and random. I'd like
to remove this piece of compilation-font-lock-keywords, but I'd like
to understand why it's there, first.
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
8688
days inactive
8689
days old
2 comments
2 participants
participants (2)
-
Ben Wing -
Charles G Waldman