emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: obsolete comment in tool-bar.el


From: Stefan Monnier
Subject: Re: obsolete comment in tool-bar.el
Date: Fri, 15 Jul 2005 16:44:20 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>    AFAIK, the motivation was also for some other cases where the user may
>    somehow setq the variable before loading the file.  IIRC this setq may
>    actually be done by Custom (at a time where it doesn't yet know that
>    the var have a :setter).

> The user should not set a minor mode variable directly unless setting
> the variable is all that is needed to enable the mode, in which case
> there is no need to call the function if the variable is already set.
> The same applies to Custom.

Can you prevent users and Custom from doing it?  If not, the "should not"
consideration is fairly meaningless.

> Moreover, if it is done before loading the file, it is done before the
> define-minor-mode.

Of course.  I'm not sure why you say it, tho.  I must be
misunderstanding something.

> In Elisp, if you call a function before it is defined, you get an
> error.  If you reference a variable before it is defined, you get a
> compiler warning, unless you use a compiler defvar.  That is true in
> particular for :set functions if the defcustom is not produced by
> define-minor-mode.  Why should defcustoms defined by define-minor-mode
> be the lone exception?  I do not believe that having to define
> functions and variables before using them is that horrible, but if it
> is, then should not changes in the way files are loaded or compiled be
> implemented, instead of this define-minor-mode only kludge?

In 99% of the cases, a minor mode's main body is only executed after the
whole file was loaded, so programmers do not expect it to be executed while
the file is being loaded.  This is empirically true.  The eval-after-load
trick turns the 99% into 100%, thus removing corner case bugs.

>    Miles complained loudly (in the form of comments, some of which
>    may still be in the current elisp code ;-)
> These comments make no sense.

If you do not understand them, I fear you may not understand the problem
well enough to judge what's the least bad solution.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]