From xemacs-m  Thu Aug 21 12:57:08 1997
Received: from newman.aventail.com (root@newman.aventail.com [199.238.236.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id MAA17439
	for <xemacs-beta@xemacs.org>; Thu, 21 Aug 1997 12:57:07 -0500 (CDT)
Received: from kramer.in.aventail.com (wmperry@kramer.in.aventail.com [192.168.1.12])
	by newman.aventail.com (8.8.5/8.8.5) with ESMTP id KAA21285;
	Thu, 21 Aug 1997 10:56:58 -0700 (PDT)
Received: (from wmperry@localhost)
	by kramer.in.aventail.com (8.8.5/8.8.5) id KAA17081;
	Thu, 21 Aug 1997 10:56:10 -0700
To: Jan Vroonhof <vroonhof@math.ethz.ch>
Cc: xemacs-beta@xemacs.org
Subject: Re: A prototype solution for true demand locking..
References: <199708211520.LAA26108@ten-thousand-dollar-bill.MIT.EDU> <by67szo39g.fsf@midget.math.ethz.ch>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
From: wmperry@aventail.com (William M. Perry)
Date: 21 Aug 1997 10:56:09 -0700
In-Reply-To: Jan Vroonhof's message of "21 Aug 1997 19:27:23 +0200"
Message-ID: <8667szfmiu.fsf@kramer.in.aventail.com>
Lines: 50
X-Mailer: Gnus v5.4.64/XEmacs 20.3(beta18) - "Bratislava"

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> David Bakhash <cadet@MIT.EDU> writes:
> 
> > 	can you explain briefly (for the dummies like me) how this would 
> > the avg XEmacs programmer who uses extents?  I'm not seeing it.
> 
> The main idea is that it would NOT affect the avarages extent
> programmer. 
> 
> > I don't 
> > know about the lazy-lock thing, but can you just give an exaple or two
> > if this patch's utility?  I actually do understand most of the extent
> > properties, but this one's over my head.
> 
[...]
> - Lazy lock has to keep track of which parts of the buffer are
>   fontified and which are not. This smells of extents.
> - The only part of Emacs which knows exactly what is visible is the
>   Redisplay code. However the golden rules forbid the redisplay code
>   calling lazy lock directly because it is lisp.

  This could be useful for Emacs/W3 as well.  It would be great if I didn't 
have to look up all the font/face related information about a chunk of text 
(which can be pretty expensive considering its something like 30 different
properties, and I have to go through the cascade for each one) until it is
actually displayed in the buffer.

> So it would be nice if we could have a clean system to have a hook
> called exactly when a specified piece of the buffer became visible.
> That's exactly what my patch does. It attaches a "hook" to each extent
> that is run when the extent becomes visible. This is determined by the
> redisplay code so the information is as exact as possible.

  I can see the utility in this, but I think setting it up as a single-shot 
function is not necessarily the right way to do it.  I'd call it something
like 'display-hook' (redisplay-hook(s)?), and make it up to the package to
make it one-shot or not, by modifying the extent from within the hook.

[...]

> As you play around with it you will see that you can outsmart the current
> naive implementation by making large jumps, especially on a beta XEmacs
> with all the extent debugging code compiled in.  You will see blue text
> that after a brief moment flashes red.

  I don't think there's a way to get around this. :)  Unless we make XEmacs 
lisp much much much faster.

-Bill P.

