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: obsolete comment in tool-bar.el Date: Thu, 7 Jul 2005 14:15:35 -0500 (CDT) Message-ID: <200507071915.j67JFZT29961@raven.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1120766053 369 80.91.229.2 (7 Jul 2005 19:54:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2005 19:54:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 07 21:54:10 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DqcRM-0001Tg-9c for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2005 21:53:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqcSj-0004Pb-LA for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2005 15:55:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DqcMW-0001iK-KR for emacs-devel@gnu.org; Thu, 07 Jul 2005 15:48:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DqcMV-0001fS-8W for emacs-devel@gnu.org; Thu, 07 Jul 2005 15:48:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqcGt-0007rh-PT for emacs-devel@gnu.org; Thu, 07 Jul 2005 15:42:55 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dqbz4-0008Lh-Bf for emacs-devel@gnu.org; Thu, 07 Jul 2005 15:24:30 -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 j67JHhCK012663; Thu, 7 Jul 2005 14:17:43 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j67JFZT29961; Thu, 7 Jul 2005 14:15:35 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: brakjoller@gmail.com In-reply-to: (message from Mathias Dahl on Thu, 07 Jul 2005 14:40:49 +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: , 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:40584 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40584 Mathias Dahl wrote: I found this in tool-bar.el: ;; We want to pretend the toolbar by standard is on, as this will make ;; customize consider disabling the toolbar a customization, and save ;; that. We could do this for real by setting :init-value above, but ;; that would turn on the toolbar in MS Windows where it is currently ;; useless, and it would overwrite disabling the tool bar from X ;; resources. If anyone want to implement this in a cleaner way, ;; please do so. ;; -- Per Abrahamsen 2002-02-21. (put 'tool-bar-mode 'standard-value '(t)) I don't know if the comment refers to the line of code just under it or to more lines in the file or if it is old and does not refer to anything :), but I am wondering about the sentence with "...in MS Windows where it is currently useless". It is not useless at all now, it is very much useful. Shall the comment be removed and / or the code changed maybe? This is one of between 20 and 30 (I forgot the exact number) options with a similar problem. Start `emacs -Q', do `M-x customize-rogue' and you get the list. If you choose "Erase Customization" for them in a Custom buffer, very unexpected things can happen. The Custom buffer shows: CHANGED outside Customize; operating on it here may be unreliable. to warn you about that. We decided that all should be fixed by putting the correct standard value in the defcustom. The trouble for most of them is that they are preloaded and when the standard value is computed the variables that are needed to compute the standard value are not yet defined. Before fixing more, we need a decision on the best way to do fix them. I explain the three alternatives below. At first I solved this by using (if I remember everything correctly): (defvar rogue-var) ;; to silence the compiler for the next line. (unless (default-boundp rogue-var) (setq rogue-var nil)) (defcustom rogue-var ... ... :initialize 'custom-initialize-set ...) This ensures that the defcustom is not evaluated when the file is preloaded. It then gets re-evaluated in a special way in startup.el. This is the first alternative. Stefan Monnier objected to what he perceived as "ugliness". His solution, which is currently implemented for the two options we fixed was to put in some boundp and fboundp's for all variables and functions that are not yet defined. This results in an essentially arbitrary temporary value, which does not matter, because it is not used until it gets reevaluated in startup.el. This is the second alternative. There some problems with Stefan's approach. Stefan and I both fixed one option this way. We both made the mistake of assuming that some variable or function "obviously" had to already be defined and hence did not need the (f)boundp. On certain operating systems, people could not build CVS Emacs anymore. Trivial to fix once noticed, but one better hope somebody notices before the release (although right now a release does not exactly appear to be imminent). Things can be done completely safely by _always_ putting the value computed by the defcustom inside a condition-case, whether one has the impression it needs it or not, just for absolute safety. This is the third alternative. I guess this will offend some people's sense of esthetics, just as much as my original solution. Both the (f)boundp and the condition-case solutions have the disadvantage that somebody trying to customize an option correctly for all environments by choosing "Show initial Lisp expression" in a Custom buffer and trying to edit it, gets a version that is cluttered with all kinds of confusing subtleties, which are not necessary in his .emacs, because all variables and functions are defined there. I still like my original solution best. Even with my original solution, which simplifies the work somewhat, scanning the Emacs source tree (_including_ the C source) for everything that influences the standard value and then rewriting the equivalent expression (often from C to Lisp) in the defcustom can take, in certain cases, quite some work. In some cases, it _might_ even require new primitives. With two done and between twenty and thirty to go, this does not look too good. If one his not careful, people may add additional options to the rogue list, making matters worse. I had to prevent that in one case. Sincerely, Luc.