Re: [Feature request] face property `raise'

[Miles Bader]

On Wed, May 14, 2003 at 07:45:40PM +0200, Wedler, Christoph wrote:
>  > Your code is not a replacement for category -- category does much more.
> 
> What does it more?
> 
>  > I'm not sure why it was suggested to be marked `obsolete' anyway --
>  > `category' is a general abstraction mechanism for text properties
>  > (and overlays), not an ad-hoc display-related property.  [...]
> 
> Hmm, half my proposal was about using just one abstraction mechanism for
> all properties: faces.  (The other half was about not trying to group
> properties into direct text/overlay props, display specs, face
> attributes, etc...)

[note that I didn't read earlier messages in this thread, as it took a
while to notice that you had started proprosing sweeping changes to emacs
internals; the message to which I first responded is the first one I
noticed, so I don't have much sense of the actual implementation you're
proposing, merely the effects of it that you were discussing with richard]

`category' works with any property at all, so as a user, I can add a
category text property called `foo' and then add a property `blargh' to
the symbol `foo', and it will be inherited via the category property.

It doesn't make much sense to call this a face, since has no connection
whatsoever to faces or display, and isn't even anything emacs understands
at all, it's purely for user use (perhaps for internal book-keeping).  So
you're suggesting that I never-the-less use the face property to inherit
this?

If I swallow my discomfort at using faces for something that's not
face-related, where do I add my `blargh' property so that it will be
inherited?

[For reference, I'm talking about something like the following:

   (put-text-property BEG END 'category 'foo)
   (put 'foo 'blargh 'woggawoggawogga)

where `blargh' is a random user property]

>  > Do you have any evidence or reasoning to support this conclusion?  It
>  > sounds like your change would end up checking for many more
>  > properties...
> 
> Yes.  The "if the above answer is b" means that Emacs merges each
> display spec individually, i.e., the same as the corresponding direct
> properties would be merged with my approach.  In other words, the number
> of direct text/overlay props, display specs, face attributes, etc which
> Emacs would have to check now are not less than the number of direct
> properties to check with my approach.

The thing is that, if I understand what's going on, you _add_ the
possibility of many more direct properties that currently exist.  E.g.,
individual face attributes are now possible direct properties.  The result
is that while checking for YOUR_NEW_PROPS+OLD_PROPS is surely more
expensive than checking _just_ YOUR_NEW_PROPS, it's (1) decidely more
expensive (in terms of number-of-checks; I don't know real terms) than
just OLD_PROPS, and (2) really only marginally more expensive than just
YOUR_NEW_PROPS.

Please correct me if I'm misunderstanding what you're proposing.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research