Re: enriched-mode and switching major modes.

[Stefan <monnier@iro.umontreal.ca>]

>     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