From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: defvar -> defcustom Date: Sun, 10 Oct 2004 18:29:15 -0500 (CDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200410102329.i9ANTFF12752@raven.dms.auburn.edu> References: NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1097451070 6111 80.91.229.6 (10 Oct 2004 23:31:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 10 Oct 2004 23:31:10 +0000 (UTC) Cc: Alex Schroeder , rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 11 01:30:56 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CGn9U-0006f3-00 for ; Mon, 11 Oct 2004 01:30:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGnGO-0000TO-Nb for ged-emacs-devel@m.gmane.org; Sun, 10 Oct 2004 19:38:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CGnGJ-0000TJ-8B for emacs-devel@gnu.org; Sun, 10 Oct 2004 19:37:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CGnGI-0000T6-Pm for emacs-devel@gnu.org; Sun, 10 Oct 2004 19:37:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGnGI-0000T1-N1 for emacs-devel@gnu.org; Sun, 10 Oct 2004 19:37:58 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CGn9I-000378-Ej; Sun, 10 Oct 2004 19:30:44 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i9ANUEiU014061; Sun, 10 Oct 2004 18:30:14 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i9ANTFF12752; Sun, 10 Oct 2004 18:29:15 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: Reiner.Steib@gmx.de In-reply-to: (message from Reiner Steib on Sun, 10 Oct 2004 15:09:47 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28204 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28204 I can not see why we should provide a function to make it convenient for people to do something they should not be doing: blindly replace defvar's by defcustom's. If people are going to try to do that, plenty of inappropriate defvar's are going to wind up in Custom buffers, cluttering them and confusing the user. Moreover, the resulting defcustom's are likely to be very far from the quality and reliability of most present defcustom's. Reiner Steib wrote: It cannot figure out the :type for all defvars, but I think 80% could be guessed heuristically (e.g. if value is t or nil, take 'boolean). Do not count on that one. Plenty of defvar's allow t and/or nil as defaults or special cases, whereas the "main" type is something else, often an integer or float, but potentially anything. The relatively best thing is to do if you are not 100% sure about the type is to specify _no_ type. That will give it type 'sexp, which may not be ideal, but at least is guaranteed not to mess up anything serious. I personally always specify `:type 'sexp' explicitly, even though it is the default anyway, just to show that I _did_ look at it. So if you did not look at it, it might be better to specify _no_ type, to avoid giving the impression that you did look at it. Alex Schroeder wrote: Current conventions would also allow to search backwards from the defvar to the closest preceding defgroup and just assume it. That is unfortunately correct. However it is dangerous to rely on this convention blindly. You _definitely_ do not want to rely on it in files like, say, simple.el, which has defgroup's all over the place and where anybody can add a new defgroup any day. More importantly, it is not just the :type or :group. People have come to rely on the fact that Custom does things for them automatically, that defvar does not do. Unless you are willing to make the use of Custom much more unpredictable, you will need to worry about whether you need one or more :set-after's, :load's, :require's and so on. You will need to worry about whether there is a need for a :set function and if yes, whether the default value of :initialize, namely `custom-initialize-reset', is really appropriate for that :set function (it quite often is not). Missing :set-after's or :require's may mean that when the user saves his customizations in .emacs, then these customizations will unpredictably sometimes be respected and sometimes not. That seems serious. So these are actually bigger problems than :type (which is the least important problem, _as long as_ you do _not_ try to guess) or :group. Sincerely, Luc.