unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]
Date: Thu, 28 Jul 2005 21:56:25 -0500 (CDT)	[thread overview]
Message-ID: <200507290256.j6T2uPh18315@raven.dms.auburn.edu> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICOEPJCKAA.drew.adams@oracle.com>

Drew Adams wrote:

   WRT the guideline of "loading must not change anything" - I agree, but I
   think that turning on a minor mode is usually relatively benign, because it
   can be turned off easily. Users loading a library that defines a minor mode
   will not be shocked if the mode is turned on by default, if the logical
   initial value to use is something other than nil.

   Otherwise, if we're going to be rigid about this guideline (perhaps there
   are good reasons to do that, even in this case),

Emacs is completely inconsistent in how well it follows these
guidelines.

The _default_ :initialize function is custom-initialize-reset.  That
means that whenever a file containing a defcustom with a :set function
is loaded, that :set function is called _even_ if the user customized
the variable outside Custom, possibly in an attempt to avoid the :set
function.  In vain.  The `custom-initialize-reset' bully will force
the :set function on the user anyway.  This has repeatedly caused me
(and other people) problems in practice.  We have systematically dealt
with these problems on a one by one basis by overriding the default
with an explicit, more polite, :initialize function for those
defcustoms for which problems were reported.  But additional problems
keep popping up on a regular basis (see the `fringe-indicators'
thread).  The problems are often not that easy to trace down to
custom-initialize-reset, because they occur when a file is loaded and
for instance Custom loads tons of files behind the user's back.  The
reason for picking `custom-initialize-reset' as the default are
autoloaded defcustoms with a :set function.  But I believe that there
_must_ be other ways to deal with such defcustoms than the bullyish
custom-initialize-reset.

A second :initialize function is custom-initialize-set.  That one only
calls the :set function if the variable is still unbound.  This means
that, if nothing else, the user can avoid the :set function by setting
the variable outside Custom in his .emacs file.  (For preloaded
defcustoms, the user can undo the effects of the :set function in his
.emacs file.)  For non-preloaded defcustoms, even setting the variable
to its standard value avoids calling the :set function, which could be
useful, if you do not want the :set function to set a timer, hide some
text, make some text read-only or perform all kind of other
"courtesies" that :set functions like to do.

On the other hand, the only :set function considered safe for minor
modes is custom-initialize-default, which _never_ calls the :set
function on initialization.  This is completely inconsistent as the
minor-mode :set functions are usually benign compared to some other
:set functions that are out there.  (See `fringe-indicators' for a
really bad example of :set function abuse.)  Actually, the standard
:set function of define-minor-mode is one of the few classes of
functions for which even custom-initialize-reset would be safe.

So on the one hand I have trouble convincing people that we should
try to get rid (after the release) of custom-initialize-reset by
finding another solution for the autoload problem and on the other
hand, I have trouble convincing Stefan that the _much_ more benign
custom-initialize-set can be safe for minor modes that are natural to
enable by default.

Sincerely,

Luc.

  reply	other threads:[~2005-07-29  2:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-27 14:57 [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Richard M. Stallman
2005-07-27 16:04 ` Luc Teirlinck
2005-07-28 16:58   ` Stefan Monnier
2005-07-28 17:43     ` [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Drew Adams
2005-07-29  2:56       ` Luc Teirlinck [this message]
2005-07-30 23:44         ` Richard M. Stallman
2005-07-31  0:43           ` Luc Teirlinck
2005-07-31 14:58             ` Juanma Barranquero
2005-08-01  0:45             ` Richard M. Stallman
2005-08-01  1:47               ` Luc Teirlinck
2005-08-01  5:33               ` Juanma Barranquero
2005-08-01 16:46                 ` Richard M. Stallman
2005-07-31  1:02           ` Luc Teirlinck
2005-08-01  0:45             ` Richard M. Stallman
2005-07-29 15:59       ` Stefan Monnier
2005-07-29 17:43         ` Drew Adams
2005-07-30  4:22         ` Luc Teirlinck
2005-07-30 13:58           ` [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?] Drew Adams
2005-07-30 21:46             ` Luc Teirlinck
2005-07-29  1:48     ` [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Luc Teirlinck
2005-07-29 17:10       ` Stefan Monnier

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=200507290256.j6T2uPh18315@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@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).