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: Tue, 19 Jul 2005 23:05:28 -0500 (CDT)	[thread overview]
Message-ID: <200507200405.j6K45SZ18998@raven.dms.auburn.edu> (raw)
In-Reply-To: <874qaqg8w0.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Tue, 19 Jul 2005 10:41:42 -0400)

Stefan Monnier wrote:
   
   Please check the commit-history of this piece of code (e.g. with
   vc-annotate) to see that it used to do what you say it "should" do
   (i.e. also call the minor-mode function if the init-value is non-nil).

First of all, I assume the lack of reaction to my patch means that you
no longer object to it.  I will wait another day or so to make sure
that this is indeed the case.  I will have to do something reasonably
soon, since without that patch (or proper alternative) Emacs fails to
build on certain operating systems.  To answer the above quote, the
define-minor-mode code used to contain:

;; If the mode is global, call the function according to the default.
,(if globalp `(if ,mode (,mode 1))))))

until you started making various changes to this section of
define-minor-mode.  The original code I quoted above had the
shortcoming of performing part of the initialization outside of the
defcustom, which can be confusing.  But it _did_ enable the mode if
the defcustom sat the variable to t and that was the intended purpose
of the code, as the comment makes clear.

   The current code follows the following idea:

   Loading a file should change Emacs's state as little as possible, so the
   init-value of a minor mode should *describe* (not determine) the default
   state of the minor-mode (in the case where the minor-mode function is not
   executed).

I understood that.  However setting the mode variable to t without
enabling the mode has some very bad consequences, to the point that I
believe it could be considered an outright bug.  If the mode has a
lighter, the mode line claims that the mode is enabled, whereas it is
not, confusing the user.  Even though the mode variable is non-nil,
the mode is disabled, so `M-x foo-mode' should enable it.  Instead,
`M-x foo-mode' is actually a no-op in this situation, which is also
very confusing to the user.

With the current code (with or without the code I propose to delete),
if you want to enable a global minor mode by default, you have to
preload the library that defines the minor mode before startup.el is
loaded and then enable the mode by calling the minor mode function in
startup.el.  (Calling it in startup.el instead of in the file defining
the minor mode prevents calling it again if for some reason the file
gets reloaded.)  This way you avoid the bugs described above.  Of
course, the author of a package not included with Emacs can not
preload his file.  So the author of such a file should put
`(if foo-mode (foo-mode 1))' in his file, at a place late enough that
calling foo-mode does not produce any errors.

One solution is to just document the above.  (Many people do not know
it.)  This would have the advantage that, even after the code I
propose to remove is removed, define-minor-mode does not need to be
called near the end of the file, because it would never call the minor
mode function.

Another solution is to change the :initialize function.  There are
some reasons why this would appear to be cleaner.  However, it would
require changing the order in which define-minor-mode does things and,
_if_ a global minor mode is enabled by default, then define-minor-mode
would have to be called at a place in the file where calling the minor
mode function will not lead to an error.

Sincerely,

Luc.

  reply	other threads:[~2005-07-20  4:05 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
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 [this message]
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=200507200405.j6K45SZ18998@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).