From xemacs-m  Thu Feb 27 09:05:28 1997
Received: from maes.esrin.esa.it (maes.esrin.esa.it [192.106.252.50])
	by xemacs.org (8.8.5/8.8.5) with SMTP id JAA02969
	for <xemacs-beta@xemacs.org>; Thu, 27 Feb 1997 09:05:23 -0600 (CST)
Received: from mail.esrin.esa.it (plod.esrin.esa.it) by maes.esrin.esa.it with SMTP id AA24616
  (5.65c/IDA-1.4.4 for <xemacs-beta@xemacs.org>); Thu, 27 Feb 1997 16:04:46 +0100
Received: from penelope.esa.it by mail.esrin.esa.it (4.1/SMI-4.1)
	id AA07869; Thu, 27 Feb 97 15:04:48 GMT
Date: Thu, 27 Feb 97 15:04:48 GMT
Message-Id: <9702271504.AA07869@mail.esrin.esa.it>
Received: by penelope.esa.it (4.1/SMI-4.1)
	id AA23432; Thu, 27 Feb 97 16:09:29 +0100
From: Simon Marshall <Simon.Marshall@esrin.esa.it>
To: XEmacs Beta <xemacs-beta@xemacs.org>
In-Reply-To: <199702271412.JAA16030@blight.IntraNet.com> (message from
	Jonathan Edwards on Thu, 27 Feb 1997 09:12:34 -0500 (EST))
Subject: Re: XEmacs-20.1-b3 is released
Reply-To: Simon Marshall <Simon.Marshall@esrin.esa.it>

SB> (Please) No more complaints about lazy(good-for-nothing)-lock.el.
SB> Either don't use it, or let's reach a consensus on which version
SB> should be used.

I assume you're talking about what version of lazy-lock.el version 1 to
use, following the 2 problems that started with b95.

1.  Process output hang is the sit-for on post-command-hook XEmacs bug.
This effects any lazy-lock.el version 1, at least if you have Lazy Lock
mode on anywhere and have stealth enabled.  So it effects b95 with
lazy-lock.el 1.14 + Ben hacks (from XEmacs 19.14), 1.15 and 1.16.  I just
tested this with XEmacs 19.15b95 to confirm it.

2.  Cursor movement slowness is a problem with version 1 made worse (for
me at least on SunOS 4.1.3) by the input-pending-p XEmacs bug.

So consensus is pointless at this stage---there are XEmacs bugs to fix.

SB> I take Simon's comments at the top seriously, and frankly I don't
SB> think XEmacs has the required features to handle it.  We either
SB> implement the functions he needs or we drop lazy-lock (IMO).

If you were happy having lazy-lock.el in XEmacs 19.12, 19.13 and 19.14
then I see no reason to change now.  But YMMV and it's your decision.

JE> My opinion: Breaking XEmacs for all users with lazy-lock loaded in
JE> their .emacs (as suggested by the sample.emacs) should not be an
JE> option. Either sync up with the needed FSF timer features (a
JE> non-trivial task, I presume), or revert to a version of lazy-lock that
JE> works (no worse than before).

I think Kyle is doing this, lazy-lock.el could use run-with-idle-timer.
However, that's just a (small) part of the (large) difference between
version 1 and version 2.  Probably Steve is talking about the
demand-driven fontification support.

Ta, Si.

