RE: Defcustoms, how do users find them?

[Drew Adams]

> > This defcustom is not autoloaded. How are users supposed to find it?
> > Should all defcustoms be autoloaded?
> 
> Autoloading of defcustom causes problems with default values.
> For autoloaded defcustoms the default is computed at the startup time
> before loading .emacs and calling custom-set-variables where 
> other variables
> get their values that may be used for computing the default value of
> the autoloaded defcustom.
> 
> Please see the related bug#4387 for more information:
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4387
> 
> There is the following etc/TODO task:
> 
>   ** Remove unnecessary autoload cookies from defcustoms.
>   This needs a bit of care, since often people have become used to
>   expecting such variables to always be defined, eg when they modify
>   things in their .emacs.
> 
> I'm not sure what does mean "This needs a bit of care"?
> So I hesitate to remove the autoload cookie from `find-name-arg'
> to fix the bug#4387.
> 
> PS: Removing the autoload cookie from `find-name-arg' also means
> adding (require 'find-dired) to rgrep where it is used, but it seems
> this is not a problem.

I'll generally keep out of this discussion. I'm no expert on Customize. I will
add my 2c now, though.

I agree with Lennart that it would be beneficial for users to have the _doc
strings_ of all (or at least most, if there are particular problems for some)
vanilla Emacs options available at startup.

IMO, this is as important (no - more important) for `C-h v' and apropos as it is
for `customize-variable'. The latter would let you see a list of options, but it
wouldn't tell you anything about them. In this I disagree with Lennart, who said
that providing all options for completion by `customize-variable' would be
sufficient.

IIUC, the difficulties Juri refers to have to do only (?) with the _values_ of
those options, not with their doc strings. IOW, there is an implementation
concern here, but it does not necessarily have to do with doc/help. (It might
have to do also with doc the way things are implemented today, but does it
_necessarily_ have to do with doc?)

Couldn't we find some way to more or less "autoload" (note the quotes) only the
doc strings and not also pre-initialize the values, since that could be
problematic (:set, :initialize etc.)?

`C-h v', apropos, etc. could then let you know what options are available and
what each option is for, even if the info these help commands provide might be
limited by not letting you know a value until the variable is bound.

IOW, being known wrt doc/help isn't, conceptually at least, the same thing as
having a value. Must we couple the two in a rigid way, so that users can know
about variables only if they have values?

The Emacs UI, more than any other I know of, makes it easy to discover what's
there - what's available on the surface as well as what's available under the
covers. It's too bad that we have this doc limitation. It's a shame we don't
provide doc strings for more options (and for more commands) from the get-go. By
such a limitation, we put (unnecessary?) obstacles in the way of user discovery
of what's possible.

I recognize that if we did what I'm asking then a simple `boundp' wouldn't be
sufficient, in commands that provide help, to distinguish variables from
non-variables. And I'm sure there are other implementation concerns and this is
not necessarily a simple thing. But we could at least think about it and not
just have the reaction "No, please god, no!".

And maybe this wouldn't really be a big deal in terms of implementation. We can
already provide doc for a variable without defining it (i.e. no defvar, no
defcustom, no setq, no let - no value):

(put 'foo 'variable-documentation "Helpful doc for `foo'.")
C-h v foo

 foo is void as a variable.

 Documentation:
 Helpful doc for `foo'.

Couldn't we use something similar as the basis for defcustom documentation,
somehow gathering all of the defcustoms for a vanilla Emacs session initially,
defining only the doc strings (not the values) for those that are not loaded?

It would of course be good if the help provided could also point to the
variable's library (automatically), but even without that info it would be
useful.