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

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

I don't disagree with most of what you write, Christoph.

I do disagree that there needs to be a wall separating options
that someone can change in the Customize UI and options that
one cannot.  If someone finds the UI or Lisp to be better to
use in some case, s?he should be able to use either.

IIUC, you propose such a categorization (UI-able (and Lispable)
options vs only-Lispable options) in order to help users deal
with the large number of options.

I think that the problem of an abundance of options should
be handled otherwise, by better organizing/categorizing
(and better design) of options, and by better discovery/exploration/navigation tools.

Wrt organizing/categorizing, currently we have pretty much
only custom groups.  Hierarchies that express some of the
dependencies you pointed out (e.g. mega-options, sub-options)
could help.  Tools to make clean use of those would also
help.

> >>  (cus-set 'indent-tabs-mode t)
> >>  (cus-set 'indent-tabs-mode nil :mode prog-mode)
>
> show me the easy code for setting indent-tabs-mode to t in
> general and to nil in all programming modes.

I'm probably missing your point, but doesn't something like
this do that?

(setq-default indent-tabs-mode t)
(add-hook 'prog-mode-hook
          (lambda () (setq indent-tabs-mode nil)))

I don't disagree that functions such as you describe would
be simpler, more flexible, and probably less error-prone to
use than hooks.  My point was that they make something that
is already pretty easy a bit easier.  It's only a minor point,
however, and I may be missing something in your point.

In general, I think we pretty much agree.  I certainly do not
defend Customize (the UI or the underlying functionality)
against possible _improvements_ of it.

Quite the contrary. I've wanted to see improvement for quite
a while, and have done some fiddling of my own in that regard.
(http://www.emacswiki.org/emacs/CustomizingAndSaving)
Improve it or replace it, yes; ignore it or abandon it, no.

My point in defending Customize is that I feel that people
too often do not take enough advantage of what it does have
to offer.  I've seen some pretty silly ~/.emacs code that
jumps around and through extra hoops in fragile, error-prone
ways, where the user could have just used `customize-option'
or `customize-face' to make their changes in a solid,
uncomplicated way.

And too often, I think, this happens because people are
unfamiliar with the (admittedly clunky) UI, or they think
that `setq' is always enough, or they think that using Lisp
is more fun (which it is) or less clueless, or they don't
know about `custom-file' and they worry about mixing
generated code with hand-coded code.

There are good reasons to use Lisp for many customizations.
It does not follow that there are no reasons to use Customize.

Personally, it took me a long time to start using Customize.
I did everything I needed only in Lisp.  Now I use both.
I am glad to let Customize handle the stuff it is good at.

And I think that others too can often benefit from what
Customize has to offer.  That said, if someone prefers to
customize an option like the one I pointed to, whose
default value is a large alist of key bindings, using only
setq in ~/.emacs, well, that's certainly possible.