Re: Question about copy-region-as-kill

[Miles Bader <miles@lsi.nec.co.jp>]

Colin Walters <walters@verbum.org> writes:
> > 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.

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.

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.  That is, to
extend the functionality of text-properties to include something that
overlays do.  I happen to think this would be a great change to
text-properties -- but that doesn't mean that the existing
implementations are fatally flawed!  Maybe they are, but this isn't the
evidence that shows that.

> 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.

I think the right answer is to extend text-properties so that you can
control which ones are copied out of a buffer.  Note that this solution
has _none_ of the drawbacks you list above.  [well, I think, anyway,
since some of them were a bit vague]

> 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.

Since the `raw extents' interface is (I think!) overlay-like, it
sounds like you'd have all the same pain, actually.

> > 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.

Please be more specific.  One reason why I don't think having two
separate implementations is bad, is that I don't think the separation is
as arbitrary as you do.

So:

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

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

You've already given example of the latter -- you want buffer-specific
text properties.  Now, as it happens this particular feature would be
pretty trivial to implement using the existing text-property
implementation.

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.

> > 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. 

Good.

> 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.

I've been very happy with TPs and overlays -- except for the issue of
unwanted copying of text properties.  In previous discussions about
how to handle that problem, the main stumbling block was what policy to
use to copy, and a merged implementation wouldn't help that at all.

Cheers,

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]