From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: [Martin.Buchmann@uni-jena.de: Re: erase customization does not work] Date: Thu, 17 Nov 2005 18:54:28 -0600 (CST) Message-ID: <200511180054.jAI0sSh07595@raven.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1132275438 9406 80.91.229.2 (18 Nov 2005 00:57:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 Nov 2005 00:57:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 18 01:57:11 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EcuXS-0002Ta-Sz for ged-emacs-devel@m.gmane.org; Fri, 18 Nov 2005 01:55:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EcuXS-00039x-Bn for ged-emacs-devel@m.gmane.org; Thu, 17 Nov 2005 19:55:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EcuX1-00034m-05 for emacs-devel@gnu.org; Thu, 17 Nov 2005 19:55:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EcuWz-00034I-D8 for emacs-devel@gnu.org; Thu, 17 Nov 2005 19:55:10 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EcuWz-00034C-5w for emacs-devel@gnu.org; Thu, 17 Nov 2005 19:55:09 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EcuWy-0006B4-KX; Thu, 17 Nov 2005 19:55:08 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id jAI0t2oM027230; Thu, 17 Nov 2005 18:55:02 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id jAI0sSh07595; Thu, 17 Nov 2005 18:54:28 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (rms@gnu.org) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Thu, 17 Nov 2005 18:55:02 -0600 (CST) 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:46193 Archived-At: Richard Stallman wrote: Could someone please debug this and ack? The problem is that the current code assumes that, in a group customization buffer, the mapc in Custom-reset-default will loop over all variables and faces in the Custom buffer, calling custom-{face,variable}-reset-standard on all of them. This assumption is false. The mapc loop has only one single iteration: it calls `custom-group-reset-standard' on the buffer's group. `custom-group-reset-standard' then iterates over the variables and faces. The group widget has a nil :custom-standard-value and no 'standard-value. Hence, in a group customization buffer, Custom-reset-default produced an error before your latest change and is a no-op after that change. The following would make the buffer-wide "Erase Customization" button work probably as well as the "Reset" and "Reset to saved" buttons: (defun Custom-reset-standard (&rest ignore) "Erase all customization (either current or saved) for the group members. The immediate result is to restore them to their standard settings. This operation eliminates any saved settings for the group members, making them as if they had never been customized at all." (interactive) (let ((children custom-options)) (mapc (lambda (widget) (when (memq (widget-get widget :custom-state) '(modified set changed saved rogue)) (widget-apply widget :custom-reset-standard))) children))) *I did not heavily test the above function* and do not recommend installing it, but if somebody else wants to install it (without attributing it to me), then that is OK with me. The problem is that I believe that this is a dangerous button, that could make people loose a lot of customizations carefully built up over the years, by inadvertently clicking mouse-1 on it (just to give focus to the frame). When that happens, I prefer them to blame somebody else, rather than me. Although other people will probably not agree with me on this, I personally believe that the best thing would be to get rid of these buffer-wide buttons altogether, _except_ for buffers customizing single options, where they are OK and convenient. The buffer-wide "Erase Customization" button has apparently *never* worked _in a group customization buffer_ in any released Emacs version. Nobody ever noticed until now (after 8 years and seven months). The other two buttons ("Reset" and "Reset to saved") apparently only started working until a change by Markus Rost made them work in 2002 after nearly six years. Before that, nobody apparently noticed that they did not work. All evidence that barely anybody ever uses them. I know that there was a thread (I participated in it) in which people claimed that most people would actually always use the buffer-wide buttons, because that is what they are used to from other applications. How come it took six, respectively eight and a half, years for _somebody_ among all those people to notice that the buttons they were using were actually no-ops (or threw errors) in group customization buffers? Sincerely, Luc.