From xemacs-m  Thu Aug 14 03:33:34 1997
Received: from ethanol.gnu.ai.mit.edu (simon@ethanol.gnu.ai.mit.edu [128.52.46.64])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id DAA04116
	for <xemacs-beta@xemacs.org>; Thu, 14 Aug 1997 03:33:34 -0500 (CDT)
Received: by ethanol.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id EAA28831; Thu, 14 Aug 1997 04:33:15 -0400
Date: Thu, 14 Aug 1997 04:33:15 -0400
Message-Id: <199708140833.EAA28831@ethanol.gnu.ai.mit.edu>
From: Simon Marshall <simon@gnu.ai.mit.edu>
To: Colin Rafferty <craffert@ml.com>
CC: XEmacs Beta <xemacs-beta@xemacs.org>
In-reply-to: <ocr7mdqc9x6.fsf_-_@ml.com> (message from Colin Rafferty on 13
	Aug 1997 12:41:41 -0400)
Subject: Re: [patch] lazy-lock
X-Mailer: Emacs 19.34 (RMail)
Reply-to: Simon Marshall <simon@gnu.ai.mit.edu>

   I have found a bug in lazy-lock.  If `lazy-lock-hide-invisible' is nil,
   then we end up fontifying the entire buffer under XEmacs 20.3 (and
   probably other versions).

Hi Colin, please can you check whether it does occur in other
versions?  I don't have an XEmacs to try it on, and you didn't give a
clear way of reproducing it either.  Was it just with something like
C-x C-f anyfile RET?  If so, I wonder why noone has noticed it since
lazy-lock.el was first included in XEmacs.

   The bug is exposed when `lazy-lock-fontify-window' gets called between
   the time a file is loaded into a buffer and it is actually displayed.
   At that point, the call to `window-end' does not return the correct
   value, but instead, the end of buffer.

   According to the documentation, `window-end' must be called with the
   second argument `t' in order to guarantee the correct result.

I don't have the documentation, so I can't comment definitively, but I
presume that passing t as second arg has other implications.  For
example, if passing t as second arg forces a redisplay, it is likely
to break the `lazy-lock-hide-invisible' non-nil behaviour.

The reason for my suspicion is that if `lazy-lock-hide-invisible' is
nil, lazy-lock.el does a `sit-for' with NODISP nil before using
`window-end' (assuming that you're not using the hacked up version of
lazy-lock.el---and if you are you're doomed anyway).  It seems strange
that `window-end' should return an incorrect value *after* a
redisplay.

Ta, Si.

