From xemacs-m  Mon Feb 24 15:19:12 1997
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210])
	by xemacs.org (8.8.5/8.8.5) with SMTP id PAA18647
	for <xemacs-beta@xemacs.org>; Mon, 24 Feb 1997 15:19:11 -0600 (CST)
Received: from suomi by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id OAA06110; Mon, 24 Feb 1997 14:19:09 -0700
Received: by suomi (SMI-8.6) id OAA22546; Mon, 24 Feb 1997 14:19:09 -0700
Sender: mdb@cdc.noaa.gov
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: [19.15-b95 / 20.1-b2] lazy-lock lossage?
Organization: CIRES, University of Colorado
X-Attribution: mb
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 24 Feb 1997 14:19:08 -0700
Message-ID: <vk67zhvr5f.fsf@cdc.noaa.gov>
Lines: 52
X-Mailer: Gnus v5.4.15/XEmacs 19.15

Something bizarre is going on with lazy-lock and font-locking of
compilation buffers. For instance, visiting the efs directory and then
doing `M-x grep -in highlight dired*.el' (never mind what I was
looking for ;-), gives this bogus answer (cut out of the *grep* buffer):

------------------------------------------------------------------------------
   cd /home/mdb/gnu/lib/xemacs-20.1-b2/lisp/efs/
   grep -in highlight dired*.el /dev/null

   grep finished (matches found) at Mon Feb 24 14:00:29
------------------------------------------------------------------------------

[ there are no matches listed in the *grep* buffer ] 

Not to mention the fact that it takes an extremely long time to
finish. Of course, the answer is really:

------------------------------------------------------------------------------
cd /home/mdb/gnu/lib/xemacs-20.1-b2/lisp/efs/
grep -in highlight dired*.el /dev/null
dired-faces.el:21:(defcustom dired-do-highlighting t
dired-faces.el:22:  "Set if we should use highlighting according to filetype."
dired-fsf.el:41:  (put-text-property start end 'mouse-face 'highlight)
dired-xemacs.el:427:    (set-extent-property filename-extent 'highlight t)
dired-xemacs.el:459:		  ((null dired-do-highlighting) nil)
dired-xemacs.el:484:(defun dired-highlight-filename-mark (extent)
dired-xemacs.el:524:	  (if dired-do-highlighting
dired-xemacs.el:525:	      (dired-highlight-filename-mark extent))
dired-xemacs.el:723:  (set-extent-property extent 'highlight t)

grep finished (matches found) at Mon Feb 24 14:08:39
------------------------------------------------------------------------------

This is how I was previously enabling lazy-lock:

  ;(autoload 'turn-on-lazy-lock "lazy-lock"
  ;  "Unconditionally turn on Lazy Lock mode.")
  ;(add-hook 'font-lock-mode-hook 'turn-on-lazy-lock)

But just evaling those (uncommented) lines after an `xemacs -q' does
not trigger the bug. However, if I don't enable lazy-lock and leave
those lines commented out, it works fine, too, which leads me to
believe it is some interaction with lazy-lock.

I realize that interaction must be in my `.emacs', but before going
through that laborious process I thought I'd see if anyone else has
noticed anything like this. In particular, I think some recent posts
have again noticed slowdowns in the compilation buffers -- do those
people who have reported this also use lazy-lock?

-- 
  -mb-

