help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

In defense of Customize [was: Trying to right-align my window on start


From: Drew Adams
Subject: In defense of Customize [was: Trying to right-align my window on startup]
Date: Tue, 14 Jan 2014 09:37:34 -0800 (PST)

> > > 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.
> 
> If a first year student of mine cannot distinguish data and code
> (s)he'd get an F grade.  customize does that.

No, it is Emacs that does that, by not requiring (or even
encouraging) the use of `custom-file', and by telling Customize to
put code in your init file by default.  That is a not-so-wise design
decision about how Emacs uses Customize.  It is not the fault of
Customize if Emacs tells it to write to your init file.

> Proof of that is that it throws random crud at my init file when
> I am not looking.

If you can find a recipe where it throws random crud at your init
file, when you are looking or not, then you will help Emacs and its
users by reporting that as a bug: `M-x report-emacs-bug'.

FWIW, I have never seen Customize "throw random crud".  And you
should avoid letting *any* generated code near your init file.  In
the case of Customize, just use `custom-file'.  Problem solved.  And
there would be no problem in the first place if you were required to
have a separate `custom-file' to use Customize.

Emacs does not by default store your bookmarks, or your elpa info,
or your thumbnail files, or your eshell info, or or any other
generated Lisp code in your init file.  Why does it still store
Customize-generated code in your init file by default?  Ask Emacs Dev.
To me, this is unwise design.

But it is certainly not Customize's fault.  If Emacs Dev decided to
store your bookmarks in your init file, you would get the same kind
of mess that you can get from Emacs mixing Customize code in with
your hand-coded init-file stuff.  It should be a no-brainer to
separate generated or automatically maintained code from user,
hand-written code.  (But whaddo I know?)

And wrt your code/data characterization: all such code is data to
the Lisp interpreter, whether you wrote it or a program wrote it,
and whether that program is Customize or the Elisp byte-compiler.

> Mostly I get away by keeping the custom file as its very exclusive
> garbage dump.  But with all my care it still occasionally stomps
> my (ie my init's) toes.

Again, report a bug.  I have never seen that.  If your `custom-file'
value points to an accessible, writable file, then I don't know of
any scenario where Emacs would write Customize stuff to your init file.

In sum, instead of vague trash-talk, please submit a bug report,
specifying just what you think happened to you.  The devil (and
understanding) is in the details.  Chicken-Little talk to scare
people away does not really help anyone.

> So no customize is not written for wimps, its written by wimps

I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs,
at least.  http://www.emacswiki.org/PerAbrahamsen

Of course, everything is relative - perhaps you are even less of
a programming wimp than Per, so you can judge him from on high.
That's certainly not my case.

The Customize code, and the `widget' code generally, is not easy
to read, IMO - that's a fair criticism.  And that is a big problem
in terms of improving Customize (e.g., the UI).  It is likely one
reason that the UI has been left behind to some extent.

> Of course if Drew is saying that customize is good for
> *exploring* options, I agree.

No, Customize is actually *not* so good for exploring faces and
options, IMHO.

It is good for ensuring that you change options and faces correctly,
e.g. type-correctly and wrt setting and initialization triggers
that should be applied.  It can also help to some extent wrt
choosing values (e.g. completion), even beyond ensuring their proper
types.

To tell you the truth, I never thought I'd be an apologist for
Customize.  I too used to avoid it and use only hand-coded Lisp
for all of my customizations.  And I too am no big fan of the UI
(and I have proposed and implemented some UI enhancements).  I have
probably criticized it (in concrete terms, including bug reports)
as much as anyone.

But I think that lots of people are, out of ignorance of what
Customize really is and can do, throwing the baby out with the
bathwater. You do not need to love the Customize UI to make good
use of Customize.

One place to start is to (really) learn `defcustom', in particular
:type.  IMO, too much Elisp code that uses `defcustom' does not
make good use of :type - meaning pretty much lazy and
less-than-useful typing.  (And that has included, and probably
still includes, some code that is distributed with Emacs.)

The more complex the structure of a variable's value, the more
Customize can help, regardless of whether you use its UI.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]