From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel Subject: Re: Bug in Custom Date: Sat, 1 Jul 2006 09:04:57 -0400 (EDT) Message-ID: References: <200607010014.k610E6WN015030@jane.dms.auburn.edu> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1151759160 651 80.91.229.2 (1 Jul 2006 13:06:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 1 Jul 2006 13:06:00 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 01 15:05:57 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FwfAa-0007wH-Pg for ged-emacs-devel@m.gmane.org; Sat, 01 Jul 2006 15:05:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FwfAa-0007ev-2m for ged-emacs-devel@m.gmane.org; Sat, 01 Jul 2006 09:05:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FwfAP-0007eP-Uz for emacs-devel@gnu.org; Sat, 01 Jul 2006 09:05:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FwfAP-0007e5-Bi for emacs-devel@gnu.org; Sat, 01 Jul 2006 09:05:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FwfAP-0007e2-93 for emacs-devel@gnu.org; Sat, 01 Jul 2006 09:05:45 -0400 Original-Received: from [69.168.108.225] (helo=rattlesnake.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FwfNP-0004fa-74 for emacs-devel@gnu.org; Sat, 01 Jul 2006 09:19:11 -0400 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.115) Sat, 1 Jul 2006 09:04:57 -0400 (EDT) Original-To: emacs-devel@gnu.org In-reply-to: <200607010014.k610E6WN015030@jane.dms.auburn.edu> (message from Luc Teirlinck on Fri, 30 Jun 2006 19:14:06 -0500 (CDT)) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:56347 Archived-At: I reported this bug a month and a half ago, but it is still present. Someone could (partially) fix the bug by revising the words "Erase Customization" in the `State' menu to "Change this Value to Previous". The bug occurs because of different ways people think of the notion of "Customization". Most people that I know think of what you do in this buffer as similar to evaluating (setq fill-column 72) in a *scratch*, .emacs, or other buffer, but with a different function. (In this case, `custom-set-variables'.) In addition, they think of "Customization" as something you do with that different function (or with `custom-set-faces'). That is to say, "Customization" in this context is not what you do when you evaluate `(setq fill-column 72)' in your `user-init-file', it is what you do when you evaluate (custom-set-variables '(fill-column 72)) So "Erase Customization" does exactly what most of the people I know expect. Moreover, it fits what RMS has said to expect. Because of the different understandings of what `customization' means, you are suggesting that evaluating a `custom-set-variables' expression should change values set by evaluating a `setq' expression in your existing customization file. In addition, you are suggesting that another way of saying "customize" should be "evaluating a `setq' expression". (info "(emacs)Changing a Variable") says: `Erase Customization' This sets the variable to its standard value, and updates the text accordingly. This also eliminates any saved value for the variable, so that you will get the standard value in future Emacs sessions. Yes, this is clearly a bug. The action does not set the variable to its standard value; the action changes it to what ever it was before using the `custom-set-variables' function. The new value is only sometimes its standard value. The documentation should be reworded. Incidently, the second sentence in the documentation for `Custom-reset-standard' should also be reworded, too. The first line of that documentation is accurate: Erase all customization (either current or saved) for the group members. But the second line is not: The immediate result is to restore them to their standard values. Indeed, since many new people will think that customization refers to the effects of evaluating a `setq' expression as well as a `custom-set-*' expression, perhaps the word `customization' and its cognates should all be changed. That would mean, for example, changing the phrase "customization buffer" to "novices' change buffer". It could mean changing `custom' to `novices-special-evaluation'. -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc