customize

customize

[Edward Welbourne]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-03-22 on raven, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I used customize.  When I was done, I clicked Finished on the pages.
Then I did C-x C-b and deleted them from the *Buffer List* window.
Now I can't save files.  I get told: max-lisp-eval-depth exceeded.
Every time I use customize, this happens.

Furthermore, I can't turn *off* having the wretched customize system
interfere with my configuration: I told it not to mess with the
trailing whitespace face now that I've remembered how to configure
that from elisp (of course, customize doesn't take the trouble to help
me there so I had to remember set-face-background's name; before I did
so, I rashly used customize to configure that background): 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; I'm clearly going to have to exit from emacs
(now that customize has managed to leave me unable to do stupidly
necessary things like save files) and vi my .emacs.

Meanwhile, would any kind soul like to tell me what to put in some
elisp *other* than (custom-set-variables '(show-trailing-whitespace
t)) to achieve the only other thing I'm letting customize mess with in
my config ?

Having a nice clever gui interface to customizing emacs is a lovely
idea - however, as it stands: customize manages to leave my emacs
session in a broken state from which I don't know how to recover; and
finding the right part of the hierarchy to look in to control anything
*still* depends on knowing how the thing to be configured is
described, so it might as well depend on knowing the name of the
relevant function/variable/... like configuring via my own elisp does.

Give me better indexing of the help system, so I can *find* which
thing to ask for help about so that I can configure it, I'd far sooner
use that than a painful failed attempt at a customization gui.  Using
elisp isn't really very hard: using customize breaks things.  It
doesn't actually help, but it *really* annoys those who would be
perfectly happy to carry on doing things the old way.

Yes, I'll probably calm down in a while.

Recent input:
C-M-S-b _ C-S-e _ SPC & & SPC ! _ S I _ F A X _ C-a 
C-p C-p C-p C-p C-p C-p C-p C-n C-x C-t C-p C-f C-f 
C-f C-f 0 SPC / / <backspace> <backspace> & & SPC <backspace> 
<backspace> <backspace> / / SPC C-n C-a C-k C-n C-n 
C-n C-n C-k C-x C-s C-p C-b C-n C-a M-{ M-} C-M-b C-M-f 
C-M-b C-n C-n C-n C-x o d o w n <return> k i l l <return> 
y <return> q u i t <return> C-x k <return> M-x r e 
p o r <tab> <return>

Recent messages:
History item: 1
Saving file /usr/local/home/eddy/qt-embed/doc/logtree/htm_ldoc.cpp...
file-readable-p: Lisp nesting exceeds max-lisp-eval-depth
Saving file /usr/local/home/eddy/qt-embed/doc/logtree/htm_ldoc.cpp...
vc-cvs-registered: Lisp nesting exceeds max-lisp-eval-depth
Mark saved where search started
Mark set [4 times]
when: Lisp nesting exceeds max-lisp-eval-depth
Auto-saving...done
Loading emacsbug...done

Re: customize

[Richard Stallman]

    I used customize.  When I was done, I clicked Finished on the pages.
    Then I did C-x C-b and deleted them from the *Buffer List* window.
    Now I can't save files.  I get told: max-lisp-eval-depth exceeded.

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

If you do M-x toggle-debug-on-error and then try to save a file, do
you get a backtrace?  If you email us that backtrace, we might figure
out from it what is wrong.

    Furthermore, I can't turn *off* having the wretched customize system
    interfere with my configuration:

Alas, that is such a general statement that I can't deduce any
specific practical conclusions from it.  I don't know whether this is
a bug or pilot error; the words could fit either one.

Please read the Bugs section in the Emacs manual, which provides
guidelines on how to write a bug report to give us the necessary
information so we can fix the bug.  Instead of saying "I can't do X",
please say "I typed precisely ABC, hoping it would do X, but it did
precisely XYZ instead."  With that sort of information, we can tell
what it means.

    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?

    I'm clearly going to have to exit from emacs
    (now that customize has managed to leave me unable to do stupidly
    necessary things like save files) 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?  What exactly happens when you start a new Emacs?  If it fails
again, could you please describe the failure, and send us your .emacs
file so we can try to investigate it?

Re: customize

[Edward Welbourne]

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

Re: customize

[Jeff Dwork]

Customizing custom-file will fix this:

 M-x customize-option RET custom-file RET

I changed mine to ~/.emacs-customize and have 
  (load (expand-file-name "~/.emacs-customize"))
in my ~/.emacs where I want it, so I can run both 19.34 and 21.1
without confusing 19.34.

IMHO, custom-file should have a prominent mention in the manual and
the top level customize group.  I found it by reading cus-edit.el.

IMVHO, the default behavior of customize should be to save to a file
different from user-init-file.  When saving, customize would scan
user-init-file looking for (load (expand-file-name "custom-file")).
If it is not found, customize offers to modify user-init-file, with
allowable responses of "yes", "no" and "no and do not ask again" (the
last being saved as a customization).  I believe this will make life
easier for both novices and experts new to emacs >19.

Jeff

Edward Welbourne writes:
 > To: rms@gnu.org
 > cc: bug-gnu-emacs@gnu.org
 > Subject: Re: customize
 > Date: Thu, 11 Jul 2002 18:29:49 +0200
 > 
...
 > 
 > 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.
 > 
...
 > 
 > 	Eddy.
 > 
 > _______________________________________________
 > Bug-gnu-emacs mailing list
 > Bug-gnu-emacs@gnu.org
 > http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

-- 
Jeff Dwork                      |           jeff.dwork@amd.com
Advanced Micro Devices, M/S 45  | 408-749-5216 (voice) 408-774-8448 (fax)
PO Box 3453                     |----------------------------------------
Sunnyvale, Ca 94088-3453        | 

Re: customize

[Edward Welbourne]

Finally, emacs died on me (it must have overheard remarks about how
robust it is) so I was forced to start a new session, so set about
reproducing my original problem with customize, namely exceeding
max-lisp-eval-depth whenever I tried opening a file after using
customize.  However, in a nice clean fresh session, the problem didn't
manifest itself: customize worked fine.

> Can you tell us precisely how to reproduce this?
evidently not.  It's only ever happened in sessions many days old.
Eris alone knows what complications of session history may be involved.

> With that information, we could fix the problem.
aye, and without it's in no danger of being caught.
Bugs that know when to hide have better survival chances.

If it happens again, I'll try the toggle-debug-on-error and similar
tricks that you suggested, see if I can glean any further information.

At least in the ensuing discussion I've met plenty of useful pointers
on the care and feeding of customize :-)

	Eddy.