Re: [Feature request] face property `raise'

[Richard Stallman <rms@gnu.org>]

Please forgive me for taking a long time to look at this proposal.
It is not that I am not interested.

       As opposed to the current behaviour (new in Emacs-21?), you cannot
       specify individual properties with the text property `face', because
       this is not needed: face attributes are normal "direct" text/overlay
       properties.

That would be an incompatible change.  For the sake of not breaking
applications, let's not change this one thing.

       Questions considered below:

	- face/property merging: a property is defined directly and/or in
	  more than one face -- which one to choose?

This issue exists in the current design, and we resolved it by saying
that faces are specified in some order.  The specification of any given
property wins.

	- how does the face/property merging relate with properties
	  specified by overlays?

Overlays come before text properties, same as now.
The ordering among properties is controlled by the priority.

	 iii. :null (or some other value) = not specified.  In this case
	      `get-text-property' and friends must return that value if a
	      properties is not specified

In the current design, the value :unspecified means aface attribute is
unspecified.  I think that is essentially your option 3.

I think we should use alists, so that the absence of a property
in an alist is clearly distinct from specifying nil.

    I see two possibilities for a naming convention for built-in properties
    (I do not discuss the individual names of the properties in this mail):

     a. :prop-name, i.e. a symbol starting with a colon,

     b. prop-name, i.e., another symbol

    Currently, text/overlay properties use a, face attribute use b, display
    properties use a and space properties (grouped in the display spec
    `space') use b.

Yes, it is rather inconsistent.

    I would suggest to use b:

I agree; the backward-compatibility issue is decisive.
However, we could recognize the existing face attribute
keywords as properties too.

     a. The display property.  The options:

	  i. obsolete, ignore it

I think that is ok.  The display property is not used in very much
code.

     b. direct face attributes in the face property:

	iii. obsolete, use it (with prio as it is now)

That would be necessary.

     c. category attribute

	 ii. obsolete, use the symbol as an additional face (with lowest
	     prio)

That would be necessary.

Meanwhile, there is an important implementation efficiency issue here.
The display code currently checks for just a few properties, and that
makes it efficient.  Clean though this new design is, we may need
to stay with the old design if we cannot make the new one efficient.