From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Mark D. Baushke" Newsgroups: gmane.emacs.devel Subject: Re: mh-e 6.2 imminent Date: Thu, 24 Oct 2002 02:13:44 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: <200210240913.g9O9Dim97039@merlot.juniper.net> References: <200210210726.g9L7QI1l014171@gbr.newt.com> <200210231948.g9NJmdBG015635@gbr.newt.com> <200210240725.g9O7PKI11467@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1035450935 11864 80.91.224.249 (24 Oct 2002 09:15:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 24 Oct 2002 09:15:35 +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 184e5V-00035B-00 for ; Thu, 24 Oct 2002 11:15:33 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 184e7c-0008Ln-00 for ; Thu, 24 Oct 2002 11:17:44 +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 184e4k-0004Us-00; Thu, 24 Oct 2002 05:14:46 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 184e3r-0002B6-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 05:13:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 184e3m-0001xq-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 05:13:49 -0400 Original-Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by monty-python.gnu.org with esmtp (Exim 4.10) id 184e3l-0001tI-00; Thu, 24 Oct 2002 05:13:45 -0400 Original-Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9O9Dim97039; Thu, 24 Oct 2002 02:13:44 -0700 (PDT) (envelope-from mdb@juniper.net) Original-To: Miles Bader In-reply-to: Mail from Miles Bader dated 24 Oct 2002 17:21:49 +0900 X-Mailer: mh-e 6.1+cvs; nmh 1.0.4; Emacs 21.1 X-Face: #8D_6URD2G%vC.hzU List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8723 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8723 Miles Bader writes: > "Stefan Monnier" writes: > > Don't take checkdoc too literally. I for one strongly dislike the > > idea of using -flag postfixes, as I've already mentioned somewhere, > > among other things because it's not a widely followed convention > > and because many boolean variables turn into 3-way (or more) variables > > over time. > > 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!). > > Why on earth does checkdoc try to enforce this? Can we take that out? I would certainly not complain about a configuration option to turn off the `-flag' suffix convention. However, at least a few of the variables that are going to be renamed have what I consider to be a worse problem. They end with a `-p' suffix which I really dislike for variables to have. User defcustom variables: mh-bury-show-buffer -> mh-bury-show-buffer-flag mh-clean-message-header -> mh-clean-message-header-flag mh-do-not-confirm -> mh-do-not-confirm-flag mh-insert-x-mailer-p -> mh-insert-x-mailer-flag mh-recenter-summary-p -> mh-recenter-summary-flag mh-reply-show-message-p -> mh-reply-show-message-flag mh-show-use-goto-addr -> mh-show-use-goto-addr-flag Internal variables to be renamed: save-modification-flag-p -> mh-save-modification-flag mh-page-to-next-msg-p -> mh-page-to-next-msg-flag mh-mhn-compose-insert-p -> mh-mhn-compose-insert-flag mh-nmh-p -> mh-nmh-flag > [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...] I would support such changes to checkdoc for the `-p' suffix. Would you care to share the argument for the `-face' suffix? I suspect that mh-e has some of these and if we are going to do a renaming, we may as well try to accommodate all such changes now rather than later. Feel free to add comments to the SourceForge.Net bugid #627015 https://sourceforge.net/tracker/?func=detail&atid=113357&aid=627015&group_id=13357 on this topic. Thanks, -- Mark