From: Richard Stallman <rms@gnu.org>
Cc: abraham@dina.kvl.dk, emacs-devel@gnu.org
Subject: Re: reducing defface redundancy
Date: Tue, 9 Jul 2002 12:51:17 -0600 (MDT) [thread overview]
Message-ID: <200207091851.g69IpHP13832@aztec.santafe.edu> (raw)
In-Reply-To: <buohej9bsku.fsf@mcspd15.ucom.lsi.nec.co.jp> (message from Miles Bader on 09 Jul 2002 10:25:37 +0900)
Can you say why you think this? I think it gets about as close as we
can to `doing the intuitive thing' when a someone uses the simple face
customization -- it's really impossible to always do things correctly,
since we'd have to read the user's mind.
The user who operates at that level won't be shown, and may not know,
at which level the various attributes were specified. If person
changes two attributes, and one change affects all terminals while the
other does not, that will be a surprise.
Here is an idea. Let's eliminate the concept of nested or "common"
attribute specs, and make the list look like a simple cond. However,
the face to inherit from should be unconditional. Thus, when you want
common attributes for face A in various conditions, you put them in
another face B and make A inherit from B.
This way, either all the attributes specified directly in face A are
general or all are specific to a particular kind of terminal. Thus,
customizing A is a simple matter, and its behavior is clear.
In terms of the actual features of defface, this is almost a return to
the way it was a year ago. However, using the inheritance we can get
the effect of nesting of specifications.
next prev parent reply other threads:[~2002-07-09 18:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-20 3:12 reducing defface redundancy Miles Bader
2002-04-20 7:14 ` Eli Zaretskii
2002-04-20 15:59 ` Per Abrahamsen
2002-04-20 17:35 ` Eli Zaretskii
2002-04-21 9:12 ` Per Abrahamsen
2002-04-20 17:41 ` Alex Schroeder
2002-04-21 2:00 ` Miles Bader
2002-04-21 9:17 ` Per Abrahamsen
2002-04-21 9:34 ` Miles Bader
2002-04-22 7:47 ` Richard Stallman
2002-04-22 7:47 ` Richard Stallman
2002-04-22 8:15 ` Miles Bader
2002-04-23 0:24 ` Richard Stallman
2002-04-23 1:36 ` Miles Bader
2002-04-24 17:54 ` Richard Stallman
2002-04-24 20:06 ` Miles Bader
2002-04-25 9:52 ` Per Abrahamsen
2002-04-26 3:18 ` Richard Stallman
2002-07-03 6:38 ` Miles Bader
2002-07-03 9:31 ` Kai Großjohann
2002-07-03 14:50 ` Kim F. Storm
2002-07-08 18:20 ` Richard Stallman
2002-07-09 1:25 ` Miles Bader
2002-07-09 18:51 ` Richard Stallman [this message]
2002-07-09 18:51 ` Richard Stallman
2002-07-09 20:52 ` Stefan Monnier
2002-07-10 19:20 ` Richard Stallman
2002-07-11 17:01 ` Stefan Monnier
2002-07-12 1:28 ` Miles Bader
2002-07-12 17:37 ` Richard Stallman
2002-04-21 20:02 ` Richard Stallman
2002-04-22 0:28 ` Miles Bader
2002-04-22 22:37 ` 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=200207091851.g69IpHP13832@aztec.santafe.edu \
--to=rms@gnu.org \
--cc=abraham@dina.kvl.dk \
--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.