RE: In defense of Customize [was: Trying to right-align my window on startup]

[Drew Adams <drew.adams@oracle.com>]

> > I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs,
> > at least.  http://www.emacswiki.org/PerAbrahamsen
> 
> Just to put the rest of this posting into context: neither do I.
> Everybody who has written LaTeX documents knows that Per has done
> an excellent job with AucTeX - just one example...
> 
> >> > > But (IMHO) too many people ignore Customize, often because
> >> > > they've gotten the impression somehow that it is for non-
> >> > > Lispers or wimps.
> >> >
> >> > I just hate its UI.
> 
> I do not hate Customize, but I think that Customize does not solve
> the main problems many users had and have with customizing Emacs.

It certainly does not solve all customization needs.  Nor does
anyone claim otherwise.

> The UI is just a minor point.  So which were the issues most users
> had with customizing Emacs before the advent of custom.el:
> 
>  1. Exploring customization options.
> 
>     There were too many customization option to grasp (I'm not
>     against having many options!), and one could not easily
>     grasp the interdependence between different options.
> 
>  2. Doing the customization.
> 
>     Users had no problems using a `setq' in combination with an
>     boolean, integer, string value, or a enum-like use of symbols,
>     or a simple list consisting of these types.  `global-set-key'
>     was also almost ok.
> 
>     They had (and have - that is the point!) a problem with having
>     to define a function/form which contains the necessary
>     customizations and having to add this to some hook, provide it
>     to eval-after-load, or ...
> 
>  3. Re-using customization (parts) of other Emacs users (or own on
>     other machine)
> 
>     Many users re-used parts of the ~/.emacs files of others.  The
>     problem was that these settings were a mixture of personal
>     setting (e.g. user-full-name), local / system-dependent settings
>     (grep-find-command), questions of taste (face colors), etc and
>     tended to grow old.
> 
> Which issues does custom.el solve?
> 
>  1. Number of options: well, nothing has changed. People are still
>     overwhelmed by the sheer number of options.

I would consider that mainly a Customize UI problem.  Customize
does not provide the greatest preferences browser.  But the
various `customize-apropos*' commands help.  I suspect that not
enough users take advantage of these commands, or are even aware
of them.

[FWIW,  in Icicle mode, Emacs commands that let you choose an
option become essentially Customize browsers.  Each command
invocation provides access to any number of options and information
about them. You can match options using multiple patterns, each of
which can be a substring or regexp.  And you can show the doc for
any options you choose, on the fly while matching.]

>     People are also puzzled if changing some option does not have
>     any effect, because it depends on other options to be set to
>     a specific value...

That's not that common a problem, IMO, but it can be a real
problem nonetheless.

At least the doc of an option that depends on other options should,
and usually does, call this out.  That's not a real solution, but
it helps.

>     Yes, custom helps a bit with exploring these options, but
>     actually mainly on the intra-package level (which Lispers
>     could do for themselves by looking at the defvar in the el
>     file).

I agree that Customize does not help a lot wrt exploring options
(browsing, discovering).  I don't understand, however, why you say
that its limited help is mainly for options in the same package.

>     If I'm interested in the possibilities for auto-completing
>     some symbol/word, I still have to know them: abbrev-mode,
>     dabbrev-expand, complete-tag (but no corresponding imenu-...),
>     and in a wider sense: ido, ...   To be fair: this is diffucult.

Not sure what you're saying here.  Are you just saying that it is
not always enough to be able to match option (or command) _names_?

That's certainly true, given that the names of some are not ideal,
and especially given that different users can think in terms of
different words about them (e.g., "abbrev", "expand", "complete").

In that regard, for vanilla Emacs I would mention `apropos-doc',
which matches doc strings.  Not a panacea, but worth knowing about.

[Icicles multi-command `icicle-vardoc' does a better job of
matching doc strings and/or names of variables.]

Besides matching option names and doc strings, exploring can
benefit from being able to match custom _types_.  Matching here
can mean several things.

[There are several Icicles multi-commands (browsers) that let you
do this, each letting you type-match in different ways.  Each lets
you match the option name at the same time as the type:
* `icicle-describe-option-of-type' (show doc)
* `icicle-customize-apropos-options-of-type' (customize)
* `icicle-apropos-options-of-type' (list)
See http://www.emacswiki.org/emacs/Icicles_-_A_Propos_d'Apropos.]

>  2. Positive: face customizations became easier.
>     Otherwise: nothing has changed much.  Yes, there is some type
>     checking on the values now.  But to be honest, I do not see the
>     point that people do not have to use Lisp to set the value of
>     some option to some Lisp function or even sexpr.

Some type-checking?  There is a _lot_ of type-checking.

Or rather, the type-checking done corresponds to the :type defined.
If the writer of the defcustom was lazy and did not write a :type
declaration that specifies a type that is sufficiently narrow, then
the type-checking will be correspondingly loose. That is the main
problem with many option definitions, IMO: lazy typing.

And that can be due insufficient familiarity with :type sexps.

And there is not only type-checking but also other handling wrt
initializing and updating values, e.g., handling of :initialize
and :set triggers.

Of the problems I see users asking about wrt setting option values,
the vast majority have to do with them using setq either to set the
value to something that conflicts with the type or without also
doing what :set or :initialize calls for.  IOW, they do not treat
the option wrt its possibly complex definition, and handle it as
if it were a simple defvar.  And that gets them into trouble.

The fault here is sometimes inadequate doc, that in effect leads
the user down the garden path to a mistake, by not making clear
what the restrictions are on the option value etc.  But the fault
is also too often, IMO, with users who want to feel "Lispian" by
using setq rather than using something as "non-programmer" as the
Customize UI.  "Look Ma, no hands!"

>     Setting some values in specific mode (or mode groups) is
>     not possible.

It is only possible to the extent that the application provides
for it.  You are right that there is nothing about this that is
part of the UI.  But a library can certainly create an option
that is only useful in certain contexts or is only usable in
certain ways.

>     Defining key and menu bindings: nothing, let alone
>     for something like the mode-line, ...

Menus, no.  Keys, yes.  There are plenty of options that let
users specify key bindings.  See :type keyword `key-sequence',
for a start.

[I use my own widget (keyword) for this, which lets you specify
a command and a key sequence to bind to it or another command to
remap to it (for the minor mode).
http://www.emacswiki.org/Icicles_-_Key_Bindings#IciclesCustomizingKeysScreenshot]

Not sure what you mean by "let alone for something like the
mode-line".  But I guess you mean that it is not simple to
customize the mode line.  Agreed, beyond some basics.

If your point is that customizing Emacs is in many ways not
covered by Customize then I doubt that you will find anyone who
disagrees.  Certainly the structure of menus, keymaps generally,
font-lock-keywords, `mode-line-format', and even face specs is
complex.  That is the case in _Lisp_, and Customize offers
little-to-nothing to help in this regard.

But it should.  And so should the Lisp handling of these things
be made easier.  That might be your argument; dunno.  It is mine.

>  3. Positive: custom-themes could be a step in the right direction

Yes and no.  The real "customization" in that case is done by
the person defining the theme.  Applying a theme is only
"customization" in the weakest sense.  It counts as such, but
saying that really misses the point.

What is really missing wrt Customize here is help for _defining_
themes.  In particular, incremental, direct-manipulation ways of
turning knobs to get the colors, fonts, etc. that you want here
and there, and then pushing a button to save what you created as
a theme.  And ways to compare themes, blend them (WYSIWYG), and
undo their effects, all components together, and sets of
components, and components individually.

FWIW, that is the kind of thing that Do Re Mi tries to offer.
But those kinds of things could usefully be used as _plug-ins_
for the Customize UI, extending it in more useful,
direct-manipulation ways.  If, that is, Customize provided for
such easy plugging-in...

Currently, choosing a color, say, with the Customize UI is
pretty primitive.  Here too there are better color-choosing UIs,
but they are all relegated to remaining essentially outside
Customize.

That's OK, since it is possible for such a library to let you
save a choice you make as a custom value (i.e., so it is
recognized by Customize).  But few do that, perhaps out of
ignorance of the custom*.el code.

What is true wrt defining themes is also true wrt using
`font-lock-keywords', at least in any context where those
keyword entries are multiple or complex.  What's needed is
one or more UIs (e.g., commands) for tweaking and immediately
visualizing the effects.  See this recent StackOverflow question
and answers for a start in this direction:
http://stackoverflow.com/questions/21125658/how-to-test-font-lock-keywords-values-for-emacs-lisp-code/

>     Negative: sharing customization settings is now actually more
>     difficult, because auto-generated custom files lack comments
>     which explain why default values have been changed, and because
>     they are ordered alphabetically and not topic-wise. Settings
>     which work on different machines are harder to do.

Yes.  But there is also value in automatic handling of such things,
especially when they are complex structures.

Such generated code should of course be kept out of user init
files.  All users who use Customize at all should define option
`custom-file', to prevent Customize from using their init file.
(That should be required by Emacs, for Customize to save anything.
Emacs not doing that is asking for trouble and not doing users any
favor, IMO.)

> In short: custom.el made things a bit easier which were easy
> before and does little to help with the others (and unfortunately
> these two are not synonyms for "many users want to change it" and
> "should be left to advanced users")

I think you are underestimating :type, in particular.  But there,
the responsibility is on the programmer who uses defcustom.  If
s?he uses it only like defvar, then yes, Customize - at best -
just makes things a bit easier that were already easy.  And maybe
not even a bit easier.  If a programmer uses defcustom as if it
were defvar then, sure, users of that library might as well use setq.

But if your argument is that the most complex structures in Emacs
Lisp: menus and other keymaps, `font-lock-keywords',
`mode-line-format', and the like are not usefully accessible to
users via the Customize UI, well, that's obvious - a no-brainer.

And I agree that it is not the case that wanting or needing to
tweak such things maps only to "advanced users".  And you are right
to point this out as one of the biggest Emacs impedance mismatches:
to do something that nearly everyone might want to do (if it were
easy), you are confronted immediately with a monstrous recursively
defined list structure (sometimes with shared structure) and
hard-to-fathom doc.

>  - `gc-cons-threshold' is customizable (which non-Lisper should
>    change that?), but

Any of them might - why not?  But what's the point?  That it is
too easy to do that without Customize?  That it is too advanced
or too hard for non-Lispers to do that?  I don't follow, here.

>  - defining a keybinding for C programming requires to define a
>    function which has to be added to some hook...

Why?  I don't program in C anymore, but isn't there a keymap for
C mode that you can define the key in?

If you want to define a key in Emacs Lisp mode, you just use
(define-key THE-KEY emacs-lisp-mode-map).  No defining a function.
No use of any hook.  (Although I have seen users jump through such
hoops even when it was not necessary.)

Yes, sometimes the mode map does not exist up front, so you might
need to do as you say.  But that's not such a big deal, is it?

> So instead of spending time on some UI, things would IMHO improve
> by the following (doing the UI later)

No one is spending time working on the Customize UI, AFAIK.
That's one reason it is still so rudimentary or "old-fashioned".
And as I said earlier, one reason that no one works on it is that
its code is hard to work with (including debugging).

>  - Define top-level forms for customizations which many people
>    want to do - something like
>       (cus-set 'indent-tabs-mode t)
>       (cus-set 'indent-tabs-mode nil :mode prog-mode)
>       (cus-define-key "some binding" command :mode c-mode)

Go for it.

To me, that would be precisely "ma[king] things a bit easier which
were easy before and do[ing] little to help with the others."

I don't see those things as difficult or as things that are hanging
users up or binding them in knots of confusion.  But maybe I'm
missing something.

>    Currently, many (mostly minor-mode) packages define their own
>    way of offering something like that (see e.g.
>    font-lock-maximum-decoration).  Otherwise, people have to add
>    some function to some hook.
> 
>  - To handle issue 1: make less options customizable: make package
>    authors define 5 good customization options, do not propose to
>    make their 30 variables (user options) customizable.  These
>    customization option just contain "easy" values: integer,
>    string value, or a enum-like use of symbols, or a simple list
>    consisting of these types.

Sorry, I don't see that as solving any real problem, unless you
feel that some package authors make what should be internal
variables into user optinos.  I haven't noticed that much, but
I'm sure it can happen.

If you are just making a plea for fewer user options, and think
that many of them should instead be internal variables (presumably
not just a few bad 3rd-party packages but even options delivered
with Emacs?) then I would disagree.

There are lots of options, true.  But I don't see that most of
them, or even many of them, should not be options.

I don't see the number of options as a problem.  One should not
multiply things unnecessarily (Occam), but that does not mean
that blindly limiting things is smarter.

A variable whose value really _must_ be an integer, and which
you want users to know that they are invited to change - as a
user preference, is better off as a user option than as an
internal variable (defvar).

I've seen enough naive users setq a variable whose value must
be a symbol to a string value instead, and vice versa.

What you say there sounds only like an argument against the
notion of user option.  I disgree with that, in any case.

Any user can tweak any Lisp variable - and that's a good thing.
But it can help users to let them know about some variables
that have been designed specifically to allow for user fine
tuning (customization).  Guiding users to user options helps
them.  Making every variable essentially the same - just
another global variable - does a disservice to users.

>    Most of these options could actually influence the values
>    of some variables - something like custom-sub-themes
>    (defined in the package) or something like c-style.

Too vague to usefully respond to.  But IIUC, nothing wrong
with doing that.

Saying that in some cases (do you really mean "most"?) you
can imagine a better, more hierarchical disposition of
user-tweakable knobs is in no way an indictment of Customize
or of user options.  It says nothing about either.  You are
essentially just going on about some people misusing these
things.

That is no different from my saying that some programmers
do not bother defining good :type specs when they create
defcustoms.

But my argument is in defense of the constructs they misuse:
the problem is not the constructs but the poor use of them.

Your argument seems to be that because some programmer
creates more options than needed, or does not organize a
program's customization as efficiently as you might expect,
the fault is with the existence of user options, Customize,
and `defcustom'.  Too facile.

Don't get me wrong.  I agree with some of what you say.

But I do not see either the notion of user option or the
control over variable values offered by `defcustom' as the
problem.  Nor do I see the existence of a Customize UI as
the problem.  (It needs to be improved, not abandoned.)
Nor do I see programmatic control over saving and restoring
user preferences as the problem.  (It needs to be kept out
of user init files, not abandoned.)

To come back for a moment to the misuse of defcustom, which
I'm guessing is too often due to laziness and ignorance:
I think of that pretty much the way I think of the relative
lack of menu support provided by 3rd-party packages:

These are not the first things one writes, when coming up
with a new package.  They are typically among the last things.
You might even add documentation to that list, although
nowadays more programmers take doc more seriously, if only
because they sometimes have to.

These things are not the core of a package.  And they too
often get short shrift.  As a result of their relative lack
of attention to these things, some programmers do not bother
to learn much about building good Emacs menus or defining
good defcustoms.

The same would even be true of keymaps and font-lock-keywords,
except that features closer to the core often involve them.
They tend to be, let's say, second-class, whereas well
designed menus and user options tend to be third-class.