Re: customize

[Edward Welbourne <eddy@opera.no>]

(I've calmed down now.)

> Can you tell us precisely how to reproduce this?  With that
> information, we could fix the problem.

I'll exit session in a bit and devote a session, with a trivial
.emacs, to doing nothing *but* a bout of customize; then I'll be able
to separate the mess from the context.  For now, answers to some
sensible questions you asked:

>>    turning off the configuration option for it merely leaves a
>>    (custom-set-faces '(trailing-whitespace ((t nil)))) in my .emacs
>>    rather than removing the entire reference;

> Is this a problem?  Does anything bad happen as a result of this?
Yes.

All customize-cruft is appended to ~/.emacs, while my own config is
accessed via a line early in the file (which loads it from some
byte-compiled elisp in a conveniently out-of-the-way directory).  Thus
my own config can't control the face, because customize insists on
having the last word (and saying: suppress this face) despite my best
efforts to get the fancy GUI to understand that I no longer want
customize to have anything to do with the setting of this face.

[Aside: the line of my .emacs which loads my own elisp has to be
preceded by one which modifies my load-path.  Ideally, I'd skip this
by using the environment variable EMACSLOADPATH; however, setting that
causes load-path to *not* include the many things in my load-path by
default ... unless I put them in my EMACSLOADPATH, which would require
me to change my .bash_profile when the system default changes.  In the
TEX* packages, the corresponding environment variables provide for
ending in : to mean `and all the stuff that would be here by default'.
IWBNI the same happened with EMACSLOADPATH.  But I digress.]

>>   I'm clearly going to have to exit from emacs and vi my .emacs.

> This seems to assume that if you restart Emacs the new session will
> have some sort of problems, but you did not report having actually
> done so and observed such problems.  Is this an observation or a
> guess?

Had I restarted my emacs without editing .emacs in between, I'd have
been left with the unwanted consequences of ((t nil)) above.
Technically we can call this a guess, as I didn't do the experiment;
but I can read a .emacs file and predict what it'll do based on what
it's specified to do.  So I needed to remove the offending customize
lines from my .emacs before next session, since I wanted the face to
be as specified in my own elisp (which I can, for instance, edit
during sessions, re-run when I like, keep in some other file than
.emacs, under source management if I want, oh, you know, it's *mine*
that way, not controlled `for me' by something I neither understand
nor trust).

Since the customize section (i.e. all but the first two lines) of my
.emacs is interspersed with repeated comments about not editing these
lines by hand or etc., the only way I can get rid of them is by using
*some other editor* while no emacs session is alive.  This, naturally,
is taking it on faith that a fresh emacs session only knows about any
prior sessions via their effects in .emacs, so I can get away with
editing .emacs by hand as long as no emacs is running.  It may be that
I can, in fact, get away with editing these lines using emacs;
however, I tend to take `do not' advice at face value ...

Later, I'll get round to taking `do this' instructions at face value,
and produce a rather more cogent bug report.  However, it remains that
*every* time I've used customize I've ended up getting these perverse
messages about the elisp stack ... and refusal to do things I ask
emacs to do.  The ensuing red mist is rather bad for cogency.

Meantime, back to processing the information just gleaned via the kind
offices of M-x grep-find (which I only met recently, having previously
used M-x compile and a messy command-line) and rejoicing in the
benefits of -print0 and -0, previously unfamiliar but *very* useful.
Thanks for tools that (mostly) do what I want,

	Eddy.