Re: Question about copy-region-as-kill

[Colin Walters]

On Sun, 2002-04-07 at 08:20, Miles Bader wrote:

> What I'm arguing for is to keep the current interfaces, because I think
> they're both useful.  Whether or not they use the same underlying
> mechanism is an implementation detail (about which others are more
> knowledgable than I).

No, it's not just an implementation detail!  With the current text
properties/overlays separation, it is going to be a big pain to change
ibuffer to use overlays.  Maybe there is a better way to do it, but I
really don't see one (if someone does, please speak up!).  And it will
certainly be slower, as you noted in a different thread.  Not only that,
but it will generate more garbage: I will have to cons up at least one
cell for each string returned, plus bind lots of variables, *and* add
properties to the overlay one at a time.

If we had extents like mechanism as the underlying implementation of
both text properties and overlays, then I could fall back to just using
the raw extents interface to solve my problem.

> We've already got an implementation that provides both; why change (but
> see below)?

It provides both, as totally separate things.  I want to be able to pick
and choose from the features of each.

> >From your description, it sounds like you would be happy if [certain]
> text-properties could be optionally suppressed from being copied by a
> user; true?

That would solve this particular problem, yes. 

> What I'm not sure of why you seem to have come to the conclusion that a
> whole-sale reworking of the way text-properties and overlays work is
> required.

I guess the only thing I can say to this is that extents make a whole
lot more sense to me.  I agree with you that text properties and
overlays cover the majority of cases, but I think there is something
more fundamental lying behind both of them.