[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kill ring menu

From: Colin Walters
Subject: Re: kill ring menu
Date: 31 May 2002 00:29:32 -0400

On Thu, 2002-05-30 at 21:53, Miles Bader wrote:
> Colin Walters <address@hidden> writes:
> > Or alternatively, we could view it as a primitive feature, much
> > like default-text-properties.
> Do people think this would be safe?  I guess the precedent of
> `default-text-properties' suggests that it should be.


> The patch gives higher a priority to `default-text-properties',
> which I think is wrong -- that only should be used if there
> really is no alternative except returning nil (IMHO).

Well, I think it's pretty arbitrary which has higher priority.  I don't
have a strong opinion, so if you think `default-text-properties' should
come last, that's fine.

> Also, it seems like overlays should implement the same feature
> (my general view is that, when possible, any special features
> should work identically for T.P.s and overlays).  

Actually, I thought it would work after changing "textget", but I didn't
test it :/  You're right, it doesn't work.

> However that's
> more complicated, for several reasons; e.g. the code to do
> overlay lookup is duplicated in several places [this is stupid,
> IMO, at least it seems like it should use some cpp macros or
> something].  

A lot of the overlays code is less than ideal, I would say.

> Also, because this feature allows several properties
> to `interact', it would present the question of whether
> properties could use property alternatives from the `other side'
> (i.e. TPs from overlays, overlays from TPs); allowing that would
> make the implementation even more complicated.

Oh, good point.  Well, this is a good reason to start changing code to
use `get-char-property'¹.

> Anyway, personally I'd be happy with a text-property only
> implementation at first.  What do other people think?

I don't know.  It certainly does reduce the aesthetic appeal of the
implementation; `font-lock-face' does work for both text properties and

¹ Not to bring up this debate again, but just to point it out: I think
that the low-level implementation distinction between text properties
and overlays is a large factor in this complication.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]