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