From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Feature request] face property `raise'
Date: Mon, 12 May 2003 21:47:55 -0400 [thread overview]
Message-ID: <E19FOtX-0005Lu-00@fencepost.gnu.org> (raw)
In-Reply-To: <67B8CED503F3D511BB9F0008C75DAD66054855B9@dewdfx17> (christoph.wedler@sap.com)
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.
next prev parent reply other threads:[~2003-05-13 1:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-29 18:19 [Feature request] face property `raise' Wedler, Christoph
2003-05-13 1:47 ` Richard Stallman [this message]
2003-05-13 2:22 ` Miles Bader
2003-05-14 21:05 ` Richard Stallman
2003-05-13 14:13 ` Stefan Monnier
2003-05-14 21:04 ` Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2003-05-14 17:45 Wedler, Christoph
2003-05-14 20:57 ` Miles Bader
2003-05-15 15:42 ` Richard Stallman
2003-05-13 17:17 Wedler, Christoph
2003-05-13 21:23 ` Miles Bader
2003-05-14 21:04 ` Richard Stallman
2003-04-11 19:34 Wedler, Christoph
2003-04-13 11:22 ` Richard Stallman
2003-04-10 18:48 Wedler, Christoph
2003-04-10 23:14 ` Kevin Rodgers
2003-04-09 18:06 Wedler, Christoph
2003-04-09 18:50 ` Kai Großjohann
2003-04-10 6:23 ` Richard Stallman
2003-04-08 17:52 Wedler, Christoph
2003-04-08 18:54 ` Kai Großjohann
2003-04-07 17:33 Wedler, Christoph
2003-04-08 6:45 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E19FOtX-0005Lu-00@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.