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

[Christoph Wedler]

Drew Adams <drew.adams@oracle.com> writes:
[...sequence of citation does not match sequence in cited article...]

> 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.  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.  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...

    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).

    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.

 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.

    Setting some values in specific mode (or mode groups) is not
    possible.  Defining key and menu bindings: nothing, let alone for
    something like the mode-line, ...

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

    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.

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")

 - `gc-cons-threshold' is customizable (which non-Lisper should change
   that?), but
 - defining a keybinding for C programming requires to define a function
   which has to be added to some hook...


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

 - 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)

   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.

   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.  Advanced users could easily define their
   own custom-sub-themes / styles - "custom" and stand Elisp co-exist
   nicely.

 Regards,
 Christoph