[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Feature request] face property `raise'
From: |
Wedler, Christoph |
Subject: |
RE: [Feature request] face property `raise' |
Date: |
Fri, 11 Apr 2003 21:34:03 +0200 |
Kevin Rodgers wrote:
> Wedler, Christoph wrote:
>> 2. the ability to define "abstract" properties and assign one ore more
>> of them to text (parts). Each abstract property represents a list of
>> (concrete) properties (with their values).
> Isn't that what the `category' property provides?
It looks like. I wouldn't have guessed that Emacs introduces two
abstraction mechanism, which
- work completely different (categories: simple symbol, face: list of
face names with some merging algorithm),
- work for a different set of properties
I think the error started when Emacs tried to define groups of different
properties:
1. there are properties called text properties like `invisible',
2. there are properties called face attributes, which you have to
specify together in the text property `face' (you can specify
abstractions = the face name, and concrete properties = the face
attributes here),
3. there are properties called display specs, which you have to specify
together in the text property `display',
4. there are properties called space properties, which you have to
specify together in the display spec `space', which you have to
specify together with other display specs in the text property
`display'.
This doesn't make anything clearer, it just leads to confusion that you
have to set/get/change different properties differently. Additionally,
there is no clear distrinction which group you should choose for a new
property.
The distinction is probably not along the lines:
- how => face property
- where => display property
if <info:(elisp)Display Property> starts with
The `display' text property (or overlay property) is used to insert
images into text, and also control other aspects of how text displays.
Therefore, some properties are defined twice:
- you can specify the text size via 2 (:height) and 3 (height)
- you can specify the space width via 3 (space-width) and 4 (:width)
and I could somehow understand that you want to avoid a similar
situation for the `raise' property...
A fix would be:
A. Don't define different groups of different properties: make all
properties text properties (or group all special = non-user-defined
text properties together)
B. Just provide one abstraction mechanism for all special properties
with the ability to merge the abstract properties (like face
merging).
I would use faces as the abstraction mechanism because
- there is a way how user can customize the face properties
- there is a package (font-lock) which can set the the abstract
properties automatically
To categories: I'm not sure whether they help me resetting "my"
properties if the is a function like `remove-yank-excluded-properties'
in subr.el...
- Christoph
- [Feature request] face property `raise', Wedler, Christoph, 2003/04/07
- RE: [Feature request] face property `raise', Wedler, Christoph, 2003/04/08
- RE: [Feature request] face property `raise', Wedler, Christoph, 2003/04/09
- RE: [Feature request] face property `raise', Wedler, Christoph, 2003/04/10
- RE: [Feature request] face property `raise',
Wedler, Christoph <=
- RE: [Feature request] face property `raise', Wedler, Christoph, 2003/04/29