RE: Using "Emacs Configure" **and** modifying .emacs

[Drew Adams]

> > > And that's not hard to do: just use
> > > `customize-variable' instead of `setq', for
> > > user options. How hard is that? If you want
> > > something shorter, define an alias...
> >
> > I don't think it is about being difficult, or
> > long, rather what is the benefit?
> 
> I think Drew has explained that pretty well. Besides,
> the "defcustom" ("15.3 Defining Customization Variables"
> node in the elisp doc does a good job, too.
> 
> > What kind of function(s) get triggered? Is it
> > to ensure the new value of the variable makes
> > sense? That is, some variant of validating
> > the input?
> 
> Yes. (The :type arg of defcustom)
> 
> > Or is it to control behavior in a wider sense,
> > so that some function, that does something, is
> > set to something depending on the value of
> > the variable?
> 
> Yes. (Among others, :set, but also perhaps :initialize,
> :set-after, etc.)
> 
> > If it is about validation, i.e. making sure the
> > variable value makes sense (is within some
> > range or have a certain type; is a member of
> > the input domain set) then I never bothered
> > with that.
> 
> Some dont want a validation to explode deep whithin
> the guts of some module loaded by another module,
> where the user has no clue about what the heck is
> going on, but next to the place where a variable
> is being set to a value it's not supposed to have.
> 
> Sometimes I can sympathize with that :-)

Indeed.

TL;DR: Few start out embracing `defcustom'.  Some end up 
realizing how to live with it and take advantage of it.

At the risk of belaboring this (if that hasn't been
done already - if it has, apologies):

If you do everything you do with Emacs Lisp code only
for your own use then, yes, you can take care of all
places where a variable is used/set.  You can find them
and make them do the right thing, even in situations
where dependent behavior is involved.

But if you provide code that others (people or libraries)
use then the situation can be a bit different.  You have
no real control over all of the places and ways that a 
variable might be set.

Declaring some things about the variable, its intended
behavior/uses (or non-behavior/non-uses) can serve to
_let others know what to expect_.  It gives them a
heads-up, similar to how a code comment can do that.

If nothing else, you can think of `defcustom' as
providing such a declaration of intent - about the
types of values expected by your code, dependencies
wrt value changes, etc.  `defcustom' is a way of
letting users (people, libraries) know stuff about
_your_ uses of the variable - what your code does
with it.

In the context of others who use your variable,
features provided by `defcustom' can be helpful.
Provided, that is, that they understand that it is
a variable that is helped by `defcustom', so that
they use `custom-*' and `customize-*' functions to
set and save it.

That's really the point, I think.

A library author uses `defcustom' to:

1. Let human users, especially but not only
   non-Lispers, use Customize to _interactively_
   browse, test, set, and persistently save the
   variable.

2. Let other code take advantage of type-checking
   (`:type'); setup, updating, synchronizing, etc.
   trigger functions (`:set' etc.); linking to doc,
   download, Commentary, etc. URLS (`:link');
   persistence, etc.

That's all.  No one is trying to make you use `custom*'
functions or Customize.

One point is that you will likely be interacting with 
variables that someone has defined using `defcustom',
so it behooves you to understand what that means: what 
`defcustom' offers and how you might take advantage of
that.

A second point is that if you write code that might be
used by others then you can take advantage of what
`defcustom' offers you and your users (people & code).
Not that you must; only that you can.  Again, it can
help you to be aware of what `defcustom' offers;
that's all.

The same things apply to faces and `defface'.
`defface', `defcustom', and `defgroup' are your friends -
or they can be, if you are interested.

FWIW, many of us wrote Elisp code mainly for ourselves,
to start with.  And many of us didn't care about or use
`defcustom'.  And many of us didn't bother with Customize
interactively.

Later, some of us started sharing some of our code, and
we  eventually started using `defcustom' to easily give
users a way to persist their choices.  But we still
didn't really care about the various features `defcustom'
offers.

At some point, some of us fell upon the gotcha of trying
to set a user option created by someone else and not
realizing there was more going on than just changing the
value - e.g. a `:set' function.

We've all been pretty much where you are, I think
(Emmanuel), in case that helps.  No one, I think, starts
out as a fan of Customize.  Few, I think, realize or care
about the benefits of `defcustom' features, at the outset.

My bet is that as you share your code more with others
(people & libraries), those _users_ will help you learn
the benefits of `defcustom', and little by little you
will change your view: something like
i-dont-need-it--i-can-do-all-i-want-in-my-own-corner
will become something more like
i-can-do-this-to-make-things-easier-for-myself-and-users.