From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Fri, 24 Sep 2004 08:50:40 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <01c49c75$Blat.v2.2.2$7a37cb00@zahav.net.il> <01c49d70$Blat.v2.2.2$f7cfb860@zahav.net.il> <01c49da7$Blat.v2.2.2$cd5f7160@zahav.net.il> <01c49dc6$Blat.v2.2.2$3b624d40@zahav.net.il> Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CApXd-0007hg-00 for ; Fri, 24 Sep 2004 14:51:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CApdh-0008Mk-Va for ged-emacs-devel@m.gmane.org; Fri, 24 Sep 2004 08:57:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CApdL-0008Ec-C7 for emacs-devel@gnu.org; Fri, 24 Sep 2004 08:57:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CApdI-0008Cr-Ui for emacs-devel@gnu.org; Fri, 24 Sep 2004 08:57:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CApdI-0008CS-KW for emacs-devel@gnu.org; Fri, 24 Sep 2004 08:57:04 -0400 Original-Received: from [206.47.199.166] (helo=simmts8-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CApX7-00071L-P0; Fri, 24 Sep 2004 08:50:42 -0400 Original-Received: from empanada.home ([67.70.165.30]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040924124850.YOPX1692.simmts8-srv.bellnexxia.net@empanada.home>; Fri, 24 Sep 2004 08:48:50 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id 65534302B04; Fri, 24 Sep 2004 08:50:40 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Fri, 24 Sep 2004 08:08:25 -0400") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (darwin) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27541 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27541 > XEmacs's version of overlays (called extents) can be part of the text > (which is a property they call `duplicable'). We could do the same. > We already did. That's what text properties are. It's not the same because: 1 - it does not preserve the identity: the text-propeties belong to characters, not to some external object. I.e. I can't do the equivalent of overlays-at, all I can do is to get all the text-properties whithout being able to distinguish "where they come from" and which ones were added together, ... 2 - I can't (in general) add a text-property to a given piece of text, and hours later say "what are the current start and end points of this property I added". 3 - An extent/overlay is limited to a single contiguous range, so when you add an extent/overlay with a `field' property, you can be sure that this field will stay as a single field. With text-propertis OTOH, if text is inserted in the middle of the field without inheriting properties, the field could be split into two. For Olivier's purpose, the model offered by overlays/extents is much easier to use. > The reason I decided that text properties should not belong to extents > which are objects is that there is no consistent way to preserve such > identities through cutting and pasting. Every way of doing it, that > I could see, gives inconsistent behavior in some cases. That I do > not want. Indeed, it's tricky business. > If you can design a system to attach text properties to extent objects > that gives consistent behavior, I would not object to implementing it. I think the semantics of `duplicable' extents is clear when the ducplicated text includes the whole extent, the problems only come up when trying to duplicate part of the text of an extent. Since the required behavior depends on the extent, we can't handle it automatically, and I just the `duplicate' property should thus be a function which will handle those "corner" cases. I.e. it doesn't solve the problem, but just pushes it to the package that decided to use a duplicable extent. My guess is that in practice, if a "partial copy" should duplicate the extent, text-properties will be a better interface, so in most cases the `duplicate' function will be set to something like `ignore'. Stefan