Re: find-file-hook as illustration of Custom problems

[Richard Stallman]

    Actually, the situation is more complex, certainly for non-hook atoms
    (and I would guess probably also for many hooks).  Code puts things in
    variables like completion-ignored-extensions, debug-ignored-errors,
    file-coding-system-alist, help-event-list,
    minibuffer-prompt-properties, mode-line-format,
    same-window-buffer-names, same-window-regexps, and many others, that
    the user definitely might want to override.

The right thing to do may not be the same for all these variables.  We
would need to look at them one by one in order to come to conclusions
about what to do with them.

For same-window-buffer-names, we could arrange for all the values
added by Lisp packages to be part of the "standard value".
That would be a start at solving the problem.

I don't think that minibuffer-prompt-properties is a problem.  It is
simply a customizable variable whose value is set up with a setq.
Likewise for help-event-list.  If there is a problem with these, it is
only that they are built-in and handled by cus-start.el rather than
a defcustom.  We just need to give them the right standard value.

Do you want to try to do that?

It would be useful to look for other variables that are in the same
situation, and handle them.  These being localized bug fixes,
we could safely install them now.

    Maybe we could avoid that additional complexity if non-preloaded code
    strictly adhered to the conventions proposed in another message and if
    preloaded code put, for all involved list-vars, all elements of the
    involved hook, list or alist, that should be user-overridable in
    custom-list-var (instead of just in list-var).

We could say that any adding of values to these variables by Lisp code
has to be done by an autoload, so that the whole value is constructed
by loadup.el.  Then we can arrange to record it as the standard value,
and that will be a good start at solving the problems.

We could have a function custom-add-to-list which adds an element to a
list and makes it part of the standard value.

    Just _loading_ a non-preloaded file should not change any defcustomed
    variable unless "harmless" (like a hook function only used to gather
    info and without user visible consequences).

This is already the convention.  Do you know of any cases where
this case is violated?

    When changing a defcustomed variable from a function, that function
    should be interactively called by the user and either the _only_
    effect should be to implement the documented behavior of the function
    (for instance by adding a function to a hook that implements that
    behavior and does not interfere with anything else), or the fact that
    elements are going to be added to the defcustom should be clearly
    documented in the docstring and in any manual where the function is
    described.


This seems plausible.  Do you know of any specific exceptions?