From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Per Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: doc elisp intro cross reference fixes Date: Wed, 26 Nov 2003 19:03:57 +0100 Organization: The Church of Emacs Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87wua28zux.fsf@zip.com.au> <87ad6vdsxi.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069870203 5278 80.91.224.253 (26 Nov 2003 18:10:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 26 Nov 2003 18:10:03 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Nov 26 19:10:01 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AP46z-00046R-00 for ; Wed, 26 Nov 2003 19:10:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AP46y-00035s-00 for ; Wed, 26 Nov 2003 19:10:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AP52m-0007i5-MV for emacs-devel@quimby.gnus.org; Wed, 26 Nov 2003 14:09:44 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AP4zd-0005Nk-CS for emacs-devel@gnu.org; Wed, 26 Nov 2003 14:06:29 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AP4yc-0004kx-Ef for emacs-devel@gnu.org; Wed, 26 Nov 2003 14:06:03 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AP4ya-0004iZ-Hb for emacs-devel@gnu.org; Wed, 26 Nov 2003 14:05:24 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AP419-0002b6-00 for ; Wed, 26 Nov 2003 19:03:59 +0100 Mail-Followup-To: emacs-devel@gnu.org X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AP418-0002ay-00 for ; Wed, 26 Nov 2003 19:03:58 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AP417-00019t-00 for ; Wed, 26 Nov 2003 19:03:57 +0100 Original-Lines: 40 Original-X-Complaints-To: usenet@sea.gmane.org X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ Mail-Copies-To: nobody User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:GdbT+twW50xEJpMt8+DrvwuFzpM= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18144 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18144 Stefan Monnier writes: > Could someone explain to me the subtle differences between: > - defvar with a * in the docstring. > - defcustom with no * in the docstring. > - defcustom with a * in the docstring. The way I have treated them are: If the variable has a value that the user is likely to want to save between sessions, use defcustom. If the variable has a value that the user is likely to want to change multiple times in a single session during normal use, use *. Something like "foo-mime-type-alist" should be defcustom without *, as it is something pretty complex you'd want to define once, and then use for ever after. You'd change it only to get it right, not as part of normal use. But something like case-fold-search would be a prototypical example of an option the user may want to change several times in a session. On the other hand, it should also be clear that 1) programmers don't understand the distinction I spend a lot of time fixing removing or adding "*" from Gnus options, most other developers seemed to either add it always or never. Even to the degree of adding or removing * from old code so everything was the same. 2) programmers can't judge when an option is something users would want to change as part of normal use 3) having too many choices for set-variable is much less of a problem than having too few. so I think it would be best to retire the "*" convention entirely. Actually enforcing it would be too much work for too little gain.