[Top][All Lists]

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

Re: kill ring menu

From: Miles Bader
Subject: Re: kill ring menu
Date: 30 May 2002 16:24:46 +0900

Colin Walters <address@hidden> writes:
> For example, we need to change face_at_buffer_position in xfaces.c to
> use Fget_char_property.  Right now, it uses Fget_text_property to
> explicitly get text properties, and then uses overlays_at to get
> overlays, and merges the face properties.
> However, I can't just change the Fget_text_property call to
> Fget_char_property, because that would incorrectly pick up any overlay
> `face' property *before* a text property `face' value.
> So we need new functions (or an optional argument to Fget_char_property)
> which allows one to get the value of a text property or overlay, while
> respecting `char-property-alternatives-alist'.

Probably, but I don't think it should be very hard.

The normal way get-char-property works is basically:

   (or (get-overlay-property ...)
       (get-text-property ...))

I guess the suggstion for property alternatives is to make it instead:

   (or (get-overlay-property ...)
       (get-text-property ...)
       (get-alternative-overlay-property ...)
       (get-alternative-text-property ...))

The think about the case you found is that it really needs to look at
_both_ properties, so it can merge them, so it can never use
get-char-property.  So it should be like:

   (merge-faces (or (get-overlay-property ...)
                    (get-alternative-overlay-property ...))
                (or (get-text-property ...)
                    (get-alternative-text-property ...)))

> We could alternatively just change all the primitives so that they
> always respect the alternatives alist; that probably has its own
> drawbacks.

No, that's wrong I think; they are primitives, whereas this feature is
intended (in my mind) as a higher-level wrapper that only affects things
like display.

Perhaps it would be most convenient if each primitive could _optionally_
lookup alternatives (e.g., add an optional parameter
`respect-alternatives' or somethign), so it's easy for programmers to
get either view -- but the default should be not to.

> Perhaps the number of places which need to explicitly respect the
> difference between text properties and overlays is small.  But I just
> hate for there to have to be those places at all.

There's no real choice, since they have to use both at the

97% of everything is grunge

reply via email to

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