unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: drew.adams@oracle.com, emacs-devel@gnu.org
Subject: Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?]
Date: Sat, 30 Jul 2005 19:43:13 -0500 (CDT)	[thread overview]
Message-ID: <200507310043.j6V0hDm25599@raven.dms.auburn.edu> (raw)
In-Reply-To: <E1Dz10R-0002a4-7L@fencepost.gnu.org> (rms@gnu.org)

Richard Stallman wrote:

       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

   That seems like the right thing to me.  If the user set the variable,
   he probably wanted to control the mode.

In the text you quoted, I was talking about defcustoms with a :set
function that are _not_ minor modes.  The vast majority of minor modes
use custom-initialize-default, so the custom-initialize-reset problems
do not apply to them.

					       _even_ if the user customized
       the variable outside Custom, possibly in an attempt to avoid the :set
       function.

   So what?  One can't please everybody.

I thought that we decided that use of Custom was optional, that people
should be able to customize everything in their .emacs and completely
ignore Custom, if that is what they wanted to do.
custom-initialize-reset effectively makes the Custom way of
customizing things mandatory.  If you try to customize things manually
in your .emacs you subject yourself to Custom overriding you at random
moments, without notice, when some file is loaded (for instance by Custom).

	 This has repeatedly caused me
       (and other people) problems in practice.

   If you describe these problems, we could think about whether they are
   worth solving by changing this mechanism.  However, if the problems
   only occur with a few particularly troublesome variables, it would be
   easier to deal with them one by one.

Prior cases that were known to give problems have been solved already
in various ways, but people just keep writing new very intrusive :set
functions.  I have proposed a solution for one very bad example in a
different thread.  I plan to install that solution if I do not hear
any objections to it.

But custom-initialize-reset can give bad surprises to people
customizing a variable outside Custom, even for very reasonable :set
functions.  For instance, suppose that setting a variable only takes
effect if a timer is set.  People using Custom have come to expect
that just setting a variable through Custom is sufficient.  So you
have to provide a :set function that calls the timer.  Now somebody
who wants the feature sometimes enabled and sometimes not might set a
very complex value for the variable in his .emacs and then enable and
disable the feature for that complex value by repeatedly setting and
unsetting the (autoloadable) timer.  But every so often the feature
will be mysteriously silently enabled, when some file is silently
loaded, for instance by Custom.  (That is why, in defcustoms I write
that call a timer in a :set function, I usually use
custom-initialize-set, or, if the standard value does not require the
timer, custom-initialize-default.)

Sincerely,

Luc.

  reply	other threads:[~2005-07-31  0:43 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
2005-07-30 23:44         ` Richard M. Stallman
2005-07-31  0:43           ` Luc Teirlinck [this message]
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=200507310043.j6V0hDm25599@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=drew.adams@oracle.com \
    --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).