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: checkdoc (was: mh-e 6.2 imminent) Date: Mon, 28 Oct 2002 16:37:03 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <20021028213703.GA4555@gnu.org> References: <200210240928.g9O9Sjs12808@rum.cs.yale.edu> <5x65vsozso.fsf@kfs2.cua.dk> <20021024144551.GA9747@gnu.org> <5xsmyvolsh.fsf@kfs2.cua.dk> <5xvg3qyiqp.fsf@kfs2.cua.dk> <5x7kg4dcr7.fsf@kfs2.cua.dk> <87elaabbh9.fsf@enberg.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035841064 5895 80.91.224.249 (28 Oct 2002 21:37:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 28 Oct 2002 21:37:44 +0000 (UTC) Cc: rms@gnu.org, storm@cua.dk, monnier+gnu/emacs@rum.cs.yale.edu, miles@lsi.nec.co.jp, wohler@newt.com, emacs-devel@gnu.org, mh-e-devel@lists.sourceforge.net Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 186HZr-0001Wc-00 for ; Mon, 28 Oct 2002 22:37:39 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 186HeA-0000v4-00 for ; Mon, 28 Oct 2002 22:42:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 186HaU-0002PT-00; Mon, 28 Oct 2002 16:38:18 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 186HZQ-0001pt-00 for emacs-devel@gnu.org; Mon, 28 Oct 2002 16:37:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 186HZO-0001oz-00 for emacs-devel@gnu.org; Mon, 28 Oct 2002 16:37:11 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 186HZN-0001o1-00 for emacs-devel@gnu.org; Mon, 28 Oct 2002 16:37:09 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.10) id 186HZH-0001ia-00; Mon, 28 Oct 2002 16:37:03 -0500 Original-To: Henrik Enberg Content-Disposition: inline In-Reply-To: <87elaabbh9.fsf@enberg.org> User-Agent: Mutt/1.3.28i Blat: Foop Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8858 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8858 On Mon, Oct 28, 2002 at 08:38:10PM +0100, Henrik Enberg wrote: > I think it's pretty natural to end them with -face. And take something > like `font-lock-keyword-face', what would be a better name? `font-lock-keyword' [e.g., (setq font-lock-keyword-face 'font-lock-keyword) ] > the current name is self-documenting. If we ended every variable in `-variable', they would all be "self documenting" too. The question is whether this is useful property, more than it is an annoying one (and I think you'll agree that calling every variable foo-variable would be really annoying!). When I look at source code [I just did this using grep] that refers to constant face names, which is the main place where this matters, I see things like: (defface foo-face ...) (defvar blah-blah-face 'foo-face) (put-text-property X Y 'face 'foo-face) (set-face-foreground 'foo-face "...") (copy-face 'foo-face) (let ((face (make-face 'foo-face))) ...) (cons 'foo-face list-of-faces) Note that all these cases, the `-face' in the face name doesn't help at all, because the variable/function/macro/property two which the constant face is being assigned/passed almost always _explicitly_ makes it clear that a face is being operated upon. In the `-face' suffix seems redundant, because it's entirely obvious -- even to someone who doesn't understand what the source code does! -- that it's a face being manipulated. I find the above situation pretty typical. The main exception, as far as I can see, is font-lock specifications, which generally look like indecipherable gobs of hair, so the face names tend to stand out as the one thing who's meaning is obvious. So to summarize, I don't think such face names really help at all, they just make the source code ugly. -Miles -- P.S. All information contained in the above letter is false, for reasons of military security.