From xemacs-m  Tue Feb 25 03:33:51 1997
Received: from lemming0.lem.uni-karlsruhe.de (jens@lemming0.lem.uni-karlsruhe.de [129.13.103.195])
	by xemacs.org (8.8.5/8.8.5) with SMTP id DAA25851
	for <xemacs-beta@xemacs.org>; Tue, 25 Feb 1997 03:33:50 -0600 (CST)
Received: (from jens@localhost) by lemming0.lem.uni-karlsruhe.de (8.6.12/8.6.9) id KAA06286; Tue, 25 Feb 1997 10:30:31 +0100
To: xemacs-beta@xemacs.org
Subject: Re: [19.15-b95 / 20.1-b2] lazy-lock lossage?
References: <vk67zhvr5f.fsf@cdc.noaa.gov> 	<u9lo8dhora.fsf@neal.ctd.comsat.com> 	<vk3eulvpur.fsf@cdc.noaa.gov> <199702242235.PAA23295@branagh.ta52.lanl.gov> <m2d8tplq8v.fsf@altair.xemacs.org> <m3rai5fz3s.fsf@jens.metrix.de> <m2iv3h71bx.fsf@altair.xemacs.org>
X-Face: Z[@OB)("ZvE?ev~1b+b!0ZUB.$%rh.9qE>dVf>q}Q/V?%d`J3gd!LR\aAZ8<Hwi]xTA(:*c;i3,?K?+rCy*^b$)a,}E?eo},}x2]5LlJysyoUOK"o[>K)'\Ulb7y-7*.If^;rHl['oa)n_M7E6w+LDKMs"G8_`c)uOS1^}.1|8Ill]7X68X-paeUOpBhz<F`B0?~^2Et~GYfw~/0]H]nx4~C_E/_mp#^7Ixc:
Reply-To: jens@lemcbed.lem.uni-karlsruhe.de
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
From: Jens Lautenbacher <jens@lemming0.lem.uni-karlsruhe.de>
Date: 25 Feb 1997 10:30:30 +0100
In-Reply-To: Steven L Baur's message of 25 Feb 1997 00:10:42 -0800
Message-ID: <x2g1yl1bd5.fsf@lemming0.lem.uni-karlsruhe.de>
Lines: 27
X-Mailer: Gnus v5.4.15/XEmacs 19.15

Steven L Baur <steve@miranova.com> writes:

> Jens Lautenbacher writes:
> 
> > I glanced through the comments at the beginning of lazy lock and I'm
> > just wondering if there are any plans to give it the necessary support
> > in XEmacs, too.
> 
> I don't have any problems about integrating the necessary patches (if
> they're doable), but given how much better fast-lock works on current
> XEmacs -vs- lazy-lock I don't think it's worth it.

Oh yes, I really think it would be worth it. I used fast lock some
time ago, and while its not a bad thing, it's still not nice having a
really big file and the need to wait for it on the first load.

Using lazy lock and lazy-lock-hide-ivisible to nil gives no noticable
slowdown on editing and you can start right after loading (OK, and
after func-menu went through this...)

It's simply the coolest thing since sliced bread.

Besides the mentioned problems 19.15 feels much faster know for me in
the usual editing situations.

    Jens

