Re: Question about copy-region-as-kill

[Colin Walters <walters@verbum.org>]

On Mon, 2002-04-08 at 02:18, Miles Bader wrote:

> I am claiming that text-properties and overlays are desirable
> _interfaces_ to certain bits of functionality.  If you `change ibuffer
> to use overlays' you're changing which _interface_ you use.  This
> interface change wouldn't be any easier if text-properties were
> implemented in terms of some sort of super-overlay.

If text properties were implemented in terms of a super-overlay (i.e.
extent), then I could manually use however they were implemented to
achieve "text properties" which are specific to a buffer.  In other
words, presumably text properties would be implemented entirely in Lisp
over extents, so I could just modify that code.

Presumably though, we would already have library code that does this.

> What you _really_ seem want (though you never seem to come right out and
> say it; or at least I missed it) is to be able to have buffer-specific
> text-properties without changing the interface you use.  

In this specific case, yes.  You are right that I am arguing for two
separate things.

1) buffer-specific text properties at the very minimum
2) the ability to fall back to a more general, and more powerful
interface to properties and text; i.e. something like XEmacs' extents. 
This would give the Lisp-level Emacs programmer a lot more freedom and
power.

> If there are text-property features that you think overlays should
> have, state them, and give some practical justification why they would
> be good.

I think an "overlay" should be able to optionally be associated with
text, or at least attempt to follow it around.  Like the XEmacs
duplicable property.  We'd like this for the case where an "object-type"
interface would be good, but we *do* want the properties to conceptually
be associated with the text.

> If there are overlay features that you think text-properties should
> have, state them, and give practical justification why they would
> be good.

I think text properties should optionally be able to be specific to the
current buffer.  This would solve the ibuffer problem.

> However, if there's a long list of such (well justified!) features, then
> maybe you're right, and a merged implementation would be better.  There
> are a lot of disadvantages to such a merged implementation, so there
> has to be a lot of justification too.

I'm curious what the disadvantages you see are.  I don't claim to be an
expert in this area, so there certainly exists the possibility that
there are major disadvantages.  But the existence of the XEmacs extent
mechanism seems to argue strongly that even if such disadvantages exist,
they are outweighed by the advantages.