From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: checkdoc (was: mh-e 6.2 imminent) Date: Thu, 24 Oct 2002 05:28:45 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200210240928.g9O9Sjs12808@rum.cs.yale.edu> References: <200210210726.g9L7QI1l014171@gbr.newt.com> <200210231948.g9NJmdBG015635@gbr.newt.com> <200210240725.g9O7PKI11467@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035451792 15301 80.91.224.249 (24 Oct 2002 09:29:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 24 Oct 2002 09:29:52 +0000 (UTC) Cc: "Stefan Monnier" , Bill Wohler , 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 184eJL-0003ye-00 for ; Thu, 24 Oct 2002 11:29:51 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 184eLS-0000FI-00 for ; Thu, 24 Oct 2002 11:32:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 184eIu-0001Ds-00; Thu, 24 Oct 2002 05:29:24 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 184eIV-0000Ef-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 05:28:59 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 184eIT-0000Dh-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 05:28:59 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 184eIT-0000DW-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 05:28:57 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g9O9Sjs12808; Thu, 24 Oct 2002 05:28:45 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Miles Bader 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:8728 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8728 > I've never heard of this `convention,' and indeed, it sounds kind of > dumb -- a `-flag' suffix doesn't really add any useful information > (if you know the _meaning_ of a variable, then you already know whether > it's boolean or not, and if you don't know the meaning, well, then it > hardly helps you to know that it's boolean!). It's sadly even mentioned in the elisp doc :-( work/emacs-0% grep -C flag lispref/tips.texi @item If a user option variable records a true-or-false condition, give it a name that ends in @samp{-flag}. [...] Luckily it's rarely folowed. > Why on earth does checkdoc try to enforce this? Can we take that out? I'd be happy to. > [I have my own agendas of course -- I'd like to make checkdoc complain > if people use a `-p' suffix for variables, or a `-face' suffix for > faces...] Agreed for the `-p'. For `-face', I'm still not sure either way. Stefan