From xemacs-m  Mon Jan 27 16:15:12 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id QAA20357 for <XEmacs-Beta@xemacs.org>; Mon, 27 Jan 1997 16:15:03 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcaix12939; Mon, 27 Jan 1997 16:49:36 -0500 (EST)
Date: Mon, 27 Jan 1997 16:49:36 -0500 (EST)
Message-Id: <QQcaix12939.199701272149@crystal.WonderWorks.COM>
From: Kyle Jones <kyle_jones@wonderworks.com>
To: nuspl@purdue.edu
Cc: XEmacs-Beta@xemacs.org
Subject: Overlays
In-Reply-To: <199701272004.PAA31320@nvwls.cc.purdue.edu>
References: <199701272004.PAA31320@nvwls.cc.purdue.edu>

Joe Nuspl writes:
 > One of the comments on my overlay support was that overlay-properties
 > would included properties that were actually properties of the
 > underlying extent.  To fix this I could have overlays be a vector such
 > as:
 > 
 > 	['overlay extent plist]
 > 
 > 
 > This would provide an encapsulation of the overlays and fix the ``problem''.
 > However, there is a performance hit.
 > 
 > Is the returning of the extent properties enough of a problem to
 > warrant encapsulating the overlays?

It depends on the magnitude of the performance hit.  I have a
different idea for hiding the extent properties that will get the
plist support back into the C code.  Is this the bit that slows it
down?

A more serious problem is a program setting properties that have a
special meaning to XEmacs but no special meaning to FSF Emacs.
Set 'duplicable or 'detached for instance would have surprising
consequences for an unsuspecting application.  So proecting the
extent from an application expecting FSF property semantics
sounds like a good thing.

By the way I tested the current overlay.el against my setnu.el
package.  After one change to my package, which seemed
reasonable, it worked.

