unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Miles Bader <miles@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: reducing defface redundancy
Date: 21 Apr 2002 11:00:16 +0900	[thread overview]
Message-ID: <871yd9q09b.fsf@tc-1-100.kawasaki.gol.ne.jp> (raw)
In-Reply-To: <rj4ri62weq.fsf@zuse.dina.kvl.dk>

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> Please, always remember that the usability of the defface UI is far
> more important than the usability of the defface Lisp interface.
> defface is really a sibling to defcustom.

They have different constraints though:

Since the defface spec is used by default, by _all_ users of emacs, it
has to be very flexible, and deal with all sorts of possible environments.
The changes I described would be very useful for allowing it to do that
job better.

The face-customization UI on the other hand, is only used by a single
user to define his personal faces; since a given user generally uses
only a small number of different environments, he usually doesn't need
all that flexibility, and is happy with a simpler representation.

> So when making changes to the defface, please consisder first:
> 
> 1. How will these changes affect the UI?

It need not affect it at all.

Remember, by default (unless you select `Show All Display Specs'), the
face customization widget basically tosses out all the clauses of the
current defface spec except the active one.  So, 99% of the time, the
user only deals with the _current_ definition of a face, and is happy.

So, the question is, what should be done for the advanced user, that
really does want to define a complex face using the UI, that works
under different display types?

If my proposal for defface is adopted, I forsee the UI interface
basically `flattening' the defface spec before passing it to the widget.
In other words, it would percolate up all conditional and `or' clauses
to the top-level so the result looks like a traditional defface spec
(in the case of an `or' vector this would result in the vector being
translated into conditional clauses, using the `capable' test I
suggested).

Indeed, this flattening could happen when the defface macro is
expanded, if the flattened form is easier for the infrastructure to
deal with (certainly it would make implementation easier, since
wouldn't have to change any existing functions except defface!).

Here are some examples of flattening:

  1) My previous example `subtle-yet-underlined-mode-line':

      (:inherit mode-line
       :underline t
       ((((background light)) :background "grey90")
        (((background dark))  :background "grey10"))))

     Flattens into:

      ((((background light))
        :inherit mode-line
        :underline t
        :background "grey90")
       (((background dark))  
        :inherit mode-line
        :underline t
        :background "grey10"))

  2) My previous example `emph-yellow':

      (:foreground "yellow"
        [(:weight bold) (:slant italic) (:underline t)]))

     Flattens into:

      ((((capable :weight bold))
        :foreground "yellow"
        :weight bold)
       (((capable :slant italic))
        :foreground "yellow"
        :slant italic)
       (t
        :foreground "yellow"
        :underline t))

So as you can see, my proposal really is just a way to make defface
easier and more convenient.  It won't make the UI any less useful, or
indeed even change it.

And remember, it doesn't just make defface specs less redundant, it also
makes it possible to write _simpler_ defface specs, which more closely
follow the thinking of the face designer.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

  parent reply	other threads:[~2002-04-21  2:00 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 [this message]
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
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

  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=871yd9q09b.fsf@tc-1-100.kawasaki.gol.ne.jp \
    --to=miles@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 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).