Mercurial > hg > xemacs-beta
diff lisp/font-lock.el @ 531:0493e9f3c27f
[xemacs-hg @ 2001-05-12 11:16:12 by ben]
event-msw.c: eliminate cygwin warnings.
dired.c, syswindows.h, win32.c: find the Net* functions the hard way to avoid errors on win 9x.
find-paths.el: fix error with null EXCLUDE-REGEXP.
font-lock.el: fix problem reported by hrvoje with buffers starting with a space.
lib-complete.el: add a variable to control where `find-library' looks, analogous to `find-function-source-path'.
etags.c: new version from Francesco.
Makefile.in.in: i'm getting real tired of incomplete commits. is this getting worse or something?
author | ben |
---|---|
date | Sat, 12 May 2001 11:16:25 +0000 |
parents | 7039e6323819 |
children | e62e90435c57 |
line wrap: on
line diff
--- a/lisp/font-lock.el Fri May 11 05:49:46 2001 +0000 +++ b/lisp/font-lock.el Sat May 12 11:16:25 2001 +0000 @@ -904,15 +904,12 @@ font-lock-maximum-size (cdr (or (assq major-mode font-lock-maximum-size) (assq t font-lock-maximum-size)))))) - ;; Font-lock mode will refuse to turn itself on if in batch mode, or if - ;; the current buffer is "invisible". The latter is because packages - ;; sometimes put their temporary buffers into some particular major mode - ;; to get syntax tables and variables and whatnot, but we don't want the - ;; fact that the user has font-lock-mode on a mode hook to slow these - ;; things down. - (if (or noninteractive (eq (aref (buffer-name) 0) ?\ )) - (setq on-p nil)) - (if (equal (buffer-name) " *Compiler Input*") ; hack for bytecomp... + ;; Font-lock mode will refuse to turn itself on if in batch mode + ;; to avoid potential (probably not actual, though) slowdown. We + ;; used to try to "be nice" by avoiding doing this in temporary + ;; buffers. But with the deferral code we don't need this, and it + ;; definitely screws some things up. + (if (noninteractive) (setq on-p nil)) (cond (on-p (make-local-hook 'after-change-functions)