From xemacs-m  Thu Aug 21 12:27:35 1997
Received: from frege.math.ethz.ch (root@frege-d-math-north-g-west.math.ethz.ch [129.132.145.3])
	by xemacs.org (8.8.5/8.8.5) with SMTP id MAA16160
	for <xemacs-beta@xemacs.org>; Thu, 21 Aug 1997 12:27:34 -0500 (CDT)
Received: from midget (vroonhof@midget [129.132.145.4]) by frege.math.ethz.ch (8.6.12/Main-STAT-mailer) with ESMTP id TAA10817 for <xemacs-beta@xemacs.org>; Thu, 21 Aug 1997 19:27:23 +0200
Received: (vroonhof@localhost) by midget (SMI-8.6/D-MATH-client) id TAA21268; Thu, 21 Aug 1997 19:27:23 +0200
To: xemacs-beta@xemacs.org
Subject: Re: A prototype solution for true demand locking..
References: <199708211520.LAA26108@ten-thousand-dollar-bill.MIT.EDU>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Jan Vroonhof <vroonhof@math.ethz.ch>
Date: 21 Aug 1997 19:27:23 +0200
In-Reply-To: David Bakhash's message of Thu, 21 Aug 1997 11:20:32 -0400 (EDT)
Message-ID: <by67szo39g.fsf@midget.math.ethz.ch>
Lines: 141
X-Mailer: Gnus v5.4.55/XEmacs 19.15

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.

This patch attempts to solve the following problem:

Suppose that you want to font-lock a buffer, just for example assume
that the buffer is now blue and you want to make it red.
Just keep in mind that what we are really talking about is
font-locking and font-locking is slow.

So what do you when you have 10 MByte buffer to make red? You can
either have the user wait till you have finished doing the coloring
(normal font-lock), you can cache the data in a file so the
font-locking becomes faster (fast-lock) or you can just color the part
that the users sees. That is where lazy-lock comes in.

Lazy-lock tries to do demand coloring, it just colors the part of the
buffer that is actally visible. (It does some other stuff too, but
lets forget about that for moment). That sounds trivial but it is
actually very complicated currently. The problem is that as the user
moves the window around, opens new windows etc the visible part of the
buffer changes. When that happens we quickly have to color the parts
that just have become visible. Ok, you say we do that, fine, problem
solved.

However there are two problems with that
  1. Exactly what is visible is not known till after redisplay. Ugh!
     This is currently solved by coloring a bit more than hopefully
     needed and some guess work.
  2. How do we now when something has become visible?

There are current three solutions for problem 2:
 2a: [Lazylock 1]. Check everytime something has happened. The problem
 with this, most of the time we don't need to do anyhting and we have
 just wasted our efforts. This makes Emacs really slow (a lot of the
 slow Emacs complaints are due to this). There was also a probablem
 that there was no way to check often enough.
 2b. [FSF solution, Lazylock 2]: Have a function called everytime
     something relevant might have changed. This is done in FSF 19.34
     and lazy-lock 2 makes use of this. However since there a lot of
     ways the things might change, you need a lot of hooks. Therefore
     Ben thought of this as ugly.
 2c. [Emacs 19.14,Lazy-lock 1+Ben patch]. Make a way to check often
     enough. That solves the problem at the end of 1, but makes Emacs
     even slower.

[See lazy-lock.el v2 (19.34) for a discussion about this].

Now my thoughts were:

- 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.

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.

Look at blue.el

(defun blue-shame (extent)
  "Make the extent turn red"
  (set-extent-face extent 'blue-red))

This function turns an extent red. This we put in the hook function
since we want it run only when needed.

(defun make-timid-blue-extent (spos epos &optional buffer)
  "Make a blue extent that will change color if it is displayed"
     (let ((extent (make-extent spos epos buffer)))
       (when extent
	 (set-extent-face extent 'blue-blue)
         (set-extent-one-shot-function extent
                       'blue-shame))
       extent))

This function sets up a new extent and attaches the hook to it. It
also also makes the extent blue for debugging purposes, normally we
would do nothing but setup the one-shot-function.

(defvar find-timid-step-size 100
  "Make timid extents of this size")

(defun find-timid-file (file)
   "Find a file and color it timidly blue."
  (interactive "ftimid file:")
  (let ((buffer (find-file-noselect file))
         start)
      (setq start  (point-min buffer))   
      (while (< start (point-max buffer))
         (make-timid-blue-extent start
           (min (point-max buffer) (+ start find-timid-step-size)) buffer)
         (setq start (+ start find-timid-step-size)))))

Now this function finds a file in a hidden buffer (so currently
nothing is in view) and cuts it up in blue chunks.
The idea is now that everytime a new piece of blue comes into view it
is quickly colored red so that user doens't notice.

Try doing find-timid-file on large text file. Remmeber the text is
colored blue!. Then switch to the buffer containing the file. You will
see red text, because XEmacs quickly recolored it.

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.

However I hope that even this simple implementation will show how it
works. I hope will play around with it to see where the problem areas
are.

Any questions?

Jan



        








