From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: reducing defface redundancy Date: 21 Apr 2002 11:00:16 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: <871yd9q09b.fsf@tc-1-100.kawasaki.gol.ne.jp> References: <877kn3qczq.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019354602 23683 127.0.0.1 (21 Apr 2002 02:03:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2002 02:03:22 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16z6hG-00069s-00 for ; Sun, 21 Apr 2002 04:03:22 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16z6hG-0006rO-00 for ; Sun, 21 Apr 2002 04:03:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16z6h4-00014g-00; Sat, 20 Apr 2002 22:03:10 -0400 Original-Received: from smtp02.fields.gol.com ([203.216.5.132]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16z6ev-00013I-00; Sat, 20 Apr 2002 22:00:57 -0400 Original-Received: from tc-2-138.kawasaki.gol.ne.jp ([203.216.25.138] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp02.fields.gol.com with esmtp (Magnetic Fields) id 16z6es-0007GM-00; Sun, 21 Apr 2002 11:00:54 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id CAC65307F; Sun, 21 Apr 2002 11:00:16 +0900 (JST) Original-To: Per Abrahamsen System-Type: i686-pc-linux-gnu In-Reply-To: Original-Lines: 94 X-Abuse-Complaints: abuse@gol.com Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2896 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2896 Per Abrahamsen 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