emacs-devel
[Top][All Lists]
Advanced

[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: Tue, 13 May 2003 19:17:53 +0200

Richard Stallman wrote:

 >       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.

That's true then for face properties.  If this is generally true, this
would mean:

  - overlay A from S to E with high prio, mouse-face: nil
  - overlay B from S to E with low prio, mouse-face: some-face

 => there is no highlighting when the mouse is in the region S to E

Is this the case?  Or is there highlighting (nil would be the null value for
mouse-face).

 >     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):

 >     [...] b. prop-name, i.e., another symbol

 > I would suggest to use b:

I agree.

 > 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.

Stefan is probably right that this is might not be true anymore...

 >      b. direct face attributes in the face property:

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

 > That would be necessary.

Sure, if backward-compatibility is an important issue...

 >      c. category attribute

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

 > That would be necessary.

Same as above (backward-compatibility).

 > Meanwhile, there is an important implementation efficiency issue here.
 > The display code currently checks for just a few properties, and that
 > makes it efficient.

It depends -- let's look at an example with overlays both defining
the display property:

  - overlay A from S to E with high prio, display: (D1 a1 D2 a2)
  - overlay B from S to E with low prio,  display: (D1 b1 D3 b3)

What's the "combined" display property?

  a. (D1 a1 D2 a2) ?

  b. (D1 a1 D2 a2 D3 b3)

I assume the answer is a.  But, if we see the properties Dx as
independent properties, b would be the correct answer.  (A similar
example could be constructed with face attributes in the property
`face' -- what's the answer there?)

 > Clean though this new design is, we may need to stay with the old
 > design if we cannot make the new one efficient.

Without extra checks for backward-compatibility properties ('category'
etc) and if the above answer is b, there don't need to be a difference
with the efficiency.  Otherwise, there might be...

- Christoph




reply via email to

[Prev in Thread] Current Thread [Next in Thread]