unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: rms@gnu.org, mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
Subject: Re: obsolete comment in tool-bar.el
Date: Fri, 15 Jul 2005 20:47:52 -0500 (CDT)	[thread overview]
Message-ID: <200507160147.j6G1lqt13574@raven.dms.auburn.edu> (raw)
In-Reply-To: <jwvzmsnolem.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 15 Jul 2005 16:44:20 -0400)

Here is the code:

       ;; If the mode is global, call the function according to the default.
       ,(if globalp
           `(if (and load-file-name (not (equal ,init-value ,mode)))
		 (eval-after-load load-file-name '(,mode (if ,mode 1 -1))))

I believe that this code definitely should be removed.

What does this code do?  Nothing, if the current value of the minor
mode variable is equal to the standard value.  That is, it does _not_
enable the mode if the standard value is t, even though the defcustom
sets the minor mode variable to t, thereby introducing a bug, which
the programmer using `define-minor-mode' will have to hand correct.

It only does something (other than throwing unnecessary errors) if the
define-minor-mode is loaded in a file and the minor mode variable has
a value different from the default _and_ out of sync with the actual
situation, something that can only occur if there is a bug in Emacs or
a user mistake.

Now what is this code _trying_ to do?  To "call the function according
to the default", if we are to believe the comment.  That would mean
that we should call the minor mode function if ,init-value is t and
the minor mode variable was unbound before the defcustom got executed.

So, to do what the comment says, we should replace the default
:initialize for minor modes from 'custom-initialize-default to
'custom-initialize-set.  Then the only effect that loading the file
would have would be to establish the intended default if the user did
not override that default before the file got loaded.  (Note: do not
confuse custom-initialize-set with the very disruptive default
:initialize function custom-initialize-reset.)  This would avoid both
problems I pointed out with the present approach.  It would still mean
that define-minor-mode should not be called too soon, but only if the
minor mode is to be enabled by default, which is rare for a global
minor mode.

Maybe, in spite of the comment, the code is _really_ trying to do what
it actually does: try to bring the mode variable back in sync with the
actual situation if it has gotten out of sync due to some bug.  But
that is a very misguided thing to do.  If the source of the bug is
Emacs, we should correct the bug in the code, not hide it by
correcting it more or less at random in this clumsy way.  If the user
setq-ed the variable rather than calling the function or setting the
variable through Custom, then you have to give the user the
opportunity to find out that it does not work.  Correcting it at
random when a file gets loaded is not helping the user, but leading
him into total confusion: sometimes setting the variable works,
sometimes not, but then at some given moment, say when browsing Custom
for unrelated reasons, it all of a sudden starts working again.

Sincerely,

Luc.

  parent reply	other threads:[~2005-07-16  1:47 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-07 12:40 obsolete comment in tool-bar.el Mathias Dahl
2005-07-07 19:15 ` Luc Teirlinck
2005-07-08  6:40   ` Mathias Dahl
2005-07-08 15:29     ` Luc Teirlinck
2005-07-08 17:40   ` Richard M. Stallman
2005-07-08 18:53     ` Drew Adams
2005-07-09  1:53       ` Luc Teirlinck
2005-07-09  4:20       ` Richard M. Stallman
2005-07-09  2:35     ` Luc Teirlinck
2005-07-10  5:19       ` Richard M. Stallman
2005-07-11  3:21         ` Luc Teirlinck
2005-07-11 16:53           ` Richard M. Stallman
2005-07-11 17:56             ` David Kastrup
2005-07-11 20:28               ` Luc Teirlinck
2005-07-12  3:20               ` Richard M. Stallman
2005-07-13  3:02                 ` Luc Teirlinck
2005-07-13 16:52                   ` Richard M. Stallman
2005-07-14  2:08                     ` Luc Teirlinck
2005-07-14  8:14                       ` YAMAMOTO Mitsuharu
2005-07-14 16:50                         ` Luc Teirlinck
2005-07-14 18:30                         ` Luc Teirlinck
2005-07-15  4:35                           ` Stefan Monnier
2005-07-15 13:53                             ` Luc Teirlinck
2005-07-15 20:44                               ` Stefan Monnier
2005-07-15 22:05                                 ` Luc Teirlinck
2005-07-15 22:46                                 ` Luc Teirlinck
2005-07-16  1:47                                 ` Luc Teirlinck [this message]
2005-07-16  2:04                                 ` Luc Teirlinck
2005-07-19  2:59                                   ` Luc Teirlinck
2005-07-19 14:41                                     ` Stefan Monnier
2005-07-20  4:05                                       ` Luc Teirlinck
2005-07-21  5:40                                         ` Stefan Monnier
2005-07-20  8:34                                     ` Richard M. Stallman
     [not found]                       ` <E1Dt8bd-0001fH-Eu@fencepost.gnu.org>
2005-07-14 22:05                         ` Luc Teirlinck
2005-07-15  3:24                           ` Luc Teirlinck
2005-07-15 18:10                             ` Richard M. Stallman
2005-07-16  2:32                               ` Luc Teirlinck
2005-07-13  3:20                 ` Luc Teirlinck
2005-07-09  3:57     ` Luc Teirlinck
2005-07-09  7:55       ` Eli Zaretskii
2005-07-09 13:57         ` Luc Teirlinck
2005-07-12  4:13           ` YAMAMOTO Mitsuharu
2005-07-12 12:20             ` YAMAMOTO Mitsuharu
2005-07-12 18:25               ` Luc Teirlinck
2005-07-12 23:58                 ` Luc Teirlinck
2005-07-13 16:52                   ` Richard M. Stallman
2005-07-12 20:19               ` Luc Teirlinck
2005-07-13  1:53               ` Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200507160147.j6G1lqt13574@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    --cc=mituharu@math.s.chiba-u.ac.jp \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).