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: Bug in Custom Date: Fri, 30 Jun 2006 19:14:06 -0500 (CDT) Message-ID: <200607010014.k610E6WN015030@jane.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1151712996 28072 80.91.229.2 (1 Jul 2006 00:16:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 1 Jul 2006 00:16:36 +0000 (UTC) Cc: abraham@dina.kvl.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 01 02:16:22 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 1FwT8C-0002wi-GM for ged-emacs-devel@m.gmane.org; Sat, 01 Jul 2006 02:14:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FwT8B-0003Gn-J4 for ged-emacs-devel@m.gmane.org; Fri, 30 Jun 2006 20:14:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FwT7y-0003Gg-Do for emacs-devel@gnu.org; Fri, 30 Jun 2006 20:14:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FwT7v-0003FE-FU for emacs-devel@gnu.org; Fri, 30 Jun 2006 20:14:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FwT7v-0003F3-CJ for emacs-devel@gnu.org; Fri, 30 Jun 2006 20:14:23 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FwTKn-0002JV-MP for emacs-devel@gnu.org; Fri, 30 Jun 2006 20:27:42 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k610EFSZ021143; Fri, 30 Jun 2006 19:14:15 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.4) with ESMTP id k610E7Xu015033; Fri, 30 Jun 2006 19:14:07 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k610E6WN015030; Fri, 30 Jun 2006 19:14:06 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org 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:56334 Archived-At: I reported this bug a month and a half ago, but it is still present. When I first reported it, the person who introduced the bug did apparently not even read my explanations and declared the bug to be a "feature". In the interest of Custom users, it would be good if somebody else (Richard?) tried to understand my arguments of why this really is a bug. I CC-ed Per in case he is interested. Start Emacs, assuming that fill-column is at its standard value of 70 and do M-: (setq-default fill-column 71) `M-x customize-option fill-column RET' Edit to 72 and set for current session, using the State Menu. Then choose "Erase Customization" from the State Menu. The value should now be 70 and the State STANDARD. Instead, the value is 71 and we see: CHANGED outside Customize; operating on it here may be unreliable. To which Chong Yidong replied: I don't see the problem: the value 71 is the last value that fill-column had before it was changed with customize. That's why erasing customizations brings back this value. I already refuted this a month and a half ago, but in the hope that somebody else might be willing to actually try to understand why this makes no sense, I will try one last time. If somebody uses setq on a variable in his .emacs, he should not use "Erase Customization" in a Custom buffer, because it will not work, so we do no have to worry about that case. However if somebody sets variables for the current session only, then he can do that alternatively through Custom buffers and through other means (say using interactive functions such as minor modes or, say, fringe-mode, or using ielm). The choice between the two depends exclusively on what is more convenient at the time. The user should be able to get the standard value back using "Erase Customization", not the value he last set when it was more convenient not to use Custom. Even more importantly, if some Lisp code sets the variable behind the user's back, then the user should be able to get the standard value back using "Erase Customization". The fact that he has to do that is already bad enough. Custom should not make things a lot worse, by not even allowing the user to do that, The new "feature" is nowhere documented. It is not mentioned in the NEWS under `** Customize changes' and (emacs)Changing a Variable still 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. The problem is caused by the `changed' theme, which tries to restore the last value set _outside_ Custom. This theme makes no sense. Themes do not override options set explicitly by the user using Custom. So they should definitely not override options set by the user by other means (which would make the `changed' theme irrelevant). The choice between using Custom or other means is normally made based on convenience and nothing else. I believe that the "feature" was introduced by the following change: 2005-12-23 Chong Yidong ... (custom-variable-state-set, custom-face-state-set): Check theme-value instead of saved-value. Even if it is agreed that the above is a bug, I will not fix it myself. I got so disillusioned by the fact that Custom is apparently being heavily redesigned (in a feature freeze, shortly before a release) by somebody who does not understand Custom well enough to understand that the above really _is_ a bug, as well as by the reaction I got when I first reported the bug, that I no longer use Custom or have any interest in it. To me this it seems like Custom is bound to be destroyed by the pathologically anti-modular Custom Themes code, so any further work on it by me seems to be a waste of my time. I just reported the above one last time for the sake of Custom users. Sincerely, Luc.