[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Feature request] face property `raise'
From: |
Miles Bader |
Subject: |
Re: [Feature request] face property `raise' |
Date: |
Wed, 14 May 2003 16:57:31 -0400 |
User-agent: |
Mutt/1.3.28i |
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