From: "Wedler, Christoph" <christoph.wedler@sap.com>
Subject: [Feature request] face property `raise'
Date: Mon, 7 Apr 2003 19:33:20 +0200 [thread overview]
Message-ID: <67B8CED503F3D511BB9F0008C75DAD660548556B@dewdfx17> (raw)
I would like to see a face property `raise' with the same semantics as
the display property `raise'. At least, I would like to see that such a
property is considered a good idea.
A face in Emacs is a named collection of graphical attributes (see
<info:(elisp)Faces>).
There are a couple of advantages of faces versus display properties
(`image' and STRING don't really relate well to the other display
properties), I'll demonstrate them with an example `subscript-face':
1. With faces, you have a nice mechanism which abstracts the logical
property "being a subscript" from some physical properties (e.g.,
"baseline raised by 0.3ex", "font-size 80%", ...)
2. Users can use the usual way to customize things.
3. There is a standard mechanism to "merge" faces. Packagages which
use text properties have to define their own merging code.
4. Since faces are named, packages can easily remove the faces from a
text region. If a package A uses text properties, it's much more
difficult just to remove the properties where A is the owner.
5. There is a package which can set faces according to the syntactical
structure of the code/text: font-lock. We could easily define
font-lock keywords for super- and subscripts.
(I know that the font-lock.el in the Emacs development version has
the variable `font-lock-extra-managed-props' which you might think
might be used to set display properties, but it doesn't help
too much due to 3 and 4 above.)
- Christoph
next reply other threads:[~2003-04-07 17:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-07 17:33 Wedler, Christoph [this message]
2003-04-08 6:45 ` [Feature request] face property `raise' Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2003-04-08 17:52 Wedler, Christoph
2003-04-08 18:54 ` Kai Großjohann
2003-04-09 18:06 Wedler, Christoph
2003-04-09 18:50 ` Kai Großjohann
2003-04-10 6:23 ` Richard Stallman
2003-04-10 18:48 Wedler, Christoph
2003-04-10 23:14 ` Kevin Rodgers
2003-04-11 19:34 Wedler, Christoph
2003-04-13 11:22 ` Richard Stallman
2003-04-29 18:19 Wedler, Christoph
2003-05-13 1:47 ` Richard Stallman
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
2003-05-13 17:17 Wedler, Christoph
2003-05-13 21:23 ` Miles Bader
2003-05-14 21:04 ` Richard Stallman
2003-05-14 17:45 Wedler, Christoph
2003-05-14 20:57 ` Miles Bader
2003-05-15 15:42 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67B8CED503F3D511BB9F0008C75DAD660548556B@dewdfx17 \
--to=christoph.wedler@sap.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).