user preferences (was RE: toolbar conventions)

[Drew Adams]

        I think "option" and "face" are good terms for what they stand
        for currently.
    
    The discussion of Custom has to mention them both together so much
    that we need some word for the two together.
    
    I'm not going to write "option and face" over and over.  I'm going
    to use a single term, even if it has to be "foobar".


1. "Foobar" is good... ;-)

Seriously - if we _must_ decide this now, then how about this:

 - We keep "option" as a short way to say "user variable", the latter
   being clearer and preferable in discussions of variables of all
   kinds. That is, we do not extend "option" to include "face".

 - We make it clear (this has already been done, IIUC) that "option"
   (= user variable) includes all variables that are user-variable-p,
   not just those that are customizable.

 - We use "preference" for options and faces, stating this clearly
   somewhere. An alternative is "setting" - we could choose either
   "preference" or "setting", or we could choose to use them both,
   interchangeably. At this level of abstraction, the terminology need
   not be so formal, precisely because we're not making much of a
   distinction.

 - We decide to intend to use "preference" in the future, in
   preference to "customizable" and "customization" in the Customize
   UI and in discussions of Customize, when referring to modifying
   anything intended to be modified by a user. (This includes
   non-customizable user-variable-p variables.) We don't bother to
   make doc and UI changes along these lines now, but we choose now
   "preference" as the preferred way to refer to things intended to be
   changed by users.

 - As long as there are non-customizable user-variable-p variables, we
   use "customizable" to mean changeable and savable in the Customize
   UI. This would be the only place where we would use the common root
   "custom" to refer to the Customize UI - that is, we would not, in
   future, use "customize" or "customized" to refer only to the
   Customize UI. We should, in general, avoid using any "custom"-root
   words, because of the potential for confusion. (A shame, for a
   self-advertised extensible and customizable editor, but
   unavoidable, I think.) Again, we don't bother to make any changes
   along these lines now, but we agree to this direction for the
   future.


2. Open question: What to do about non-customizable user-variable-p
variables? Should we try to eliminate these - not only in vanilla
Emacs, but eliminate also their possibility? That is, should we
eliminate `set-variable's sensitivity to `*' in doc strings? It would
certainly simplify the terminology. All user variables would then be
"customizable". But see also #3, below.


3. As I stated long ago, I would like to see Customize move in the
direction of being better integrated with the rest of Emacs. By that,
I mean that users could change preferences in ways other than using
the Customize UI directly, but Customize would nevertheless recognize
(i.e. could be made to recognize) those changes, and would treat them
the same as changes made inside Customize.

This would, in effect, extend Customize so that some of its
functionality could be used outside a Customize buffer.

Examples:

a. `set-variable' (better called `set-option', IMO) could be used as a
   quick replacement for `customize-option' to change the value (but
   not to save, browse, or do other things that you can do in
   Customize). To understand what I mean, don't think in terms of
   non-customizable user variables here; think in terms of
   customizable options. The point is that a command could be used to
   customize something, without the user ever entering the Customize
   UI.

b. (just an illustration; not intended as a proposal for inclusion)
   Command `doremi-face-fg' (in my library doremi-frm.el) lets you
   modify a face's foreground color incrementally (using the arrow
   keys). You never enter the Customize UI. You can directly
   manipulate the color easily until you get what you want. The
   command also tells Customize that the face foreground has been
   modified, so that Customize thinks the modification was done inside
   Customize. The user can then save the setting in Customize. There
   is no inside/outside Customize here: if the user does `M-x
   customize-customized' after the change, then the face state shows
   as "you have set this face, but not saved it...", NOT as "changed
   outside...". Why? Because that reflects just what the user did.

You might say, "That's great functionality, but why not just
incorporate an incremental face-changer like that into the Customize
UI?" The answer is that we might want to do that in some such cases,
but certainly not all. The Customize UI is complex enough. It can't be
expected to deal with all of the possible ways we might want to let
users modify preferences. There might be several different ways that a
user would want to change a face foreground; would we want to
integrate all of them into the Customize UI? Better that we should let
library writers create new interfaces and have those play well with
Customize.

This approach doesn't take away from Customize; it extends it and
makes it more useful, by integrating it better with the rest of
Emacs. Customize would be the central place to make all customization
changes, and it would notice all changes made outside it. The reason
it does not really play that central customization role today is that
it does not play well with changes made outside it.

We should look for more, and better, ways to let users modify their
Emacs experience - we should shoot for ways that involve _direct
manipulation_ more, for instance. We should not try to make Customize
encompass all such modifications. We should instead make Customize
recognize them and play along with them.

Luc and others have pointed out that there are many problematic
aspects to trying to integrate Customize with changes made outside
it. I don't mean to suggest that there are no problems. But we can try
to solve the problems (as Luc has already done, to a great degree),
and we can try to move a little more in the direction of a Customize
that plays well with Emacs.

I would prefer that we discuss this after the release. I mention it
(again) now, because Richard has decided to decide on the terminology
now, and I feel that possible changes to Customize may affect the
terminology discussion (and vice versa).