RE: [Feature request] face property `raise'

["Wedler, Christoph" <christoph.wedler@sap.com>]

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