Re: obsolete comment in tool-bar.el

[Luc Teirlinck]

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 <address@hidden> 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.