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

[Richard Stallman]

      Thus
    my own config can't control the face, because customize insists on
    having the last word (and saying: suppress this face)

I don't understand what you mean, "saying: suppress this face."  Could
you explain more precisely?  This may be a very simple and localized
bug, but I can't tell, because I don't really understand the scenario.

What does (custom-set-faces '(trailing-whitespace ((t nil)))) do?
What is it supposed to do?
What settings did you specify in customize for that face?
You said "turning off the configuration option for it"; what does
"it" refer to here, and which option is that?

Re: customize

[Edward Welbourne]

> What does (custom-set-faces '(trailing-whitespace ((t nil)))) do?
> What is it supposed to do?

it is supposed to configure the trailing-whitespace face, activated by
setting show-trailing-whitespace to a non-nil value; however, it sets
the face to always have no attributes set.  This appears consistent
with what it *does*: the face is just ordinary background, making the
trailing hspace (which, for me, is actually blackspace, not
whitespace; I use reverse-video systematically) invisible despite
being `shown'.  This is perfectly correct behaviour.

I just didn't want this code in my .emacs, after the point where my
.emacs loads my .sys/elisp/init.el which configures the face using
set-face-background (and doesn't contain any dire warnings about not
editing this other than via the appropriate wizard; I can edit the
color name, evaluate the expression, see if I like it, etc. until I
like it, then byte compile the file and *know*, as opposed to hoping,
that it'll Do What I Want; which is currently grey18).

> What settings did you specify in customize for that face?
This'll have to wait until I'm not in the middle of a session with
lots of saved state: I am *not* going to play with customize except in
a session I'm happy to abort shortly afterwards (because this is what
I've *always* had to do shortly after using customize), but roughly
speaking: I went to the config section for trailing whitespace and
unchecked the check-box for the background colour specification of the
face, then saved the configuration.

The customize behaviour here is to configure the face to be invisible,
rather than to remove the configuration of that face from my .emacs
file.  If this is what customize is meant to do in this case, please
could we have a control on the GUI that says `customize back off here
and say nothing about this face' for use by those who want to do this
via our own elisp.

> You said "turning off the configuration option for it"; what does
> "it" refer to here, and which option is that?
"it" was the face, trailing-whitespace.

For details of which option that was in the GUI, see above on my
reticence about firing up customize just to find out how it described
the face.  It may be a while before I get such a break - I am busy and
emacs is generally so well behaved I don't have to exit it other than
on the rare occasions my Debian GNU/Linux box needs rebooted.  But
when I do take such a break, I'll dig through these e-mails answering
lots of questions.

		Eddy.

Re: customize

[Stefan Monnier]

> > What does (custom-set-faces '(trailing-whitespace ((t nil)))) do?
[...]
> I just didn't want this code in my .emacs, after the point where my
[...]
> The customize behaviour here is to configure the face to be invisible,
> rather than to remove the configuration of that face from my .emacs
> file.  If this is what customize is meant to do in this case, please
> could we have a control on the GUI that says `customize back off here
> and say nothing about this face' for use by those who want to do this
> via our own elisp.

I think that's what the "erase customization" option is for
(in the menu that pops up when you middle-click on `state').
Have you tried it ?


	Stefan

Re: customize

[Edward Welbourne]

> I think that's what the "erase customization" option is for
> (in the menu that pops up when you middle-click on `state').
> Have you tried it ?

aha !  The UI detail I hadn't found.
I'll look for it when I come to play with this later.
Thanks for mentioning its existence.

		Eddy.

Re: customize

[Richard Stallman]

    it is supposed to configure the trailing-whitespace face, activated by
    setting show-trailing-whitespace to a non-nil value; however, it sets
    the face to always have no attributes set.  This appears consistent
    with what it *does*: the face is just ordinary background, making the
    trailing hspace (which, for me, is actually blackspace, not
    whitespace; I use reverse-video systematically) invisible despite
    being `shown'.  This is perfectly correct behaviour.

Ok.

      If this is what customize is meant to do in this case, please
    could we have a control on the GUI that says `customize back off here
    and say nothing about this face' for use by those who want to do this
    via our own elisp.

That is the Erase Customization button.  It is supposed to put any
face or variable back in its standard settings.  However, I just tried
that and it didn't work for faces.  I fixed several bugs in that
feature.  Now it removes the info about that face in .emacs.

I also fixed it so that if the face is in its standard state, and you
do Save for Future Sessions, it saves nothing about that face.

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

[Richard Stallman]

I documented custom-face, but I don't see a reason to change the
default to use a different file.

Re: customize

[Edward Welbourne]

> I documented custom-face, but I don't see a reason to change the
> default to use a different file.

Jeff was discussing customisation of custom-file, not custom-face.
But I'm guessing that's what you meant.

Three reasons for setting custom-face to somewhere other than ~/.emacs
(only arguably reasons against using ~/.emacs as default for
custom-face):

  * Database reason: one file then contains only customize's actions,
    making it much easier to keep track of which pieces of one's
    config come from where.

  * Priority/ordering reason: customize adds things to the end of its
    file: this is sensible for it, but potentially bad for elisp which
    needs to be executed after customizations; using a separate file
    for customize lets my ~/.emacs load the customize part early, late
    or in between, at my option, rather than having it always be last.

  * Byte-compilation: putting it all in a separate .el file provides
    for the possibility of byte-compiling the customization elisp.

Having customize write to ~/.emacs leads to its works being mixed up
with the user's hand-coded elisp; it also ensures that customize's
actions over-ride everything the user sets up in elisp.

Two reasons for using ~/.emacs as the default:

  * Simplicity: ~/.emacs is being loaded anyway; if customize writes
    to any other file, ~/.emacs must load that file; users will be
    confused/upset if their customization efforts have no effect
    (because the file the customization was recorded in hasn't been
    loaded).

  * Convenience/consistency: using a byte-compiled file requires
    recompilation each time any customizations get added.

Personally, I'm with Jeff on this ... but I suspect this is the
natural bias of old hands; while newbies need convenience with
simplicity, and can't be expected to work out what to do about
problems.

Having the customization system provide a clear and prominent mention
of custom-file's role, on its front page, would probably be the wisest
approach; newbies could safely ignore it and have their customizations
work, while old hands would have the one clue we need to fix it up the
way we prefer.

		Eddy.

Re: customize

[Kai Großjohann]

Edward Welbourne <eddy@opera.no> writes:

>   * Priority/ordering reason: customize adds things to the end of its
>     file: this is sensible for it, but potentially bad for elisp which
>     needs to be executed after customizations; using a separate file
>     for customize lets my ~/.emacs load the customize part early, late
>     or in between, at my option, rather than having it always be last.

custom-set-* doesn't have to come last in ~/.emacs.  After it is
there, you can add stuff in ~/.emacs after it.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: customize

[Edward Welbourne]

> custom-set-* doesn't have to come last in ~/.emacs.
but customize always adds it at the end.

> After it is there, you can add stuff in ~/.emacs after it.
and get a layer-cake of intermingled fragments, some of one's own
construction, others added by customize (and marked with a warning
against modifying them other than via the customize UI), which will
make it harder to keep track of what's going on, what one can safely
modify, etc.; maintenance nightmare.

Meanwhile, this adds opportunities for customize (if we don't assume
it has no bugs in it) to get confused by the intermingling and, e.g.,
either fail to notice some of its earlier works or mistake some
user-elisp for customize insertions.

Having customize add everything it does to a single file, maintained
entirely via the customize UI, loaded at a well-considered moment in
one's start-up sequence, will provide for tidier source-management,
easier maintenance, better control over the start-up process, less
opportunity for any bugs in customize to manifest themselves and
probably less bugs in initialisation.

As Jeff pointed out, it also makes it easier to cope with switching
between different versions of emacs.

		Eddy.

Re: customize

[chad]

> Having customize add everything it does to a single file, maintained
> entirely via the customize UI, loaded at a well-considered moment in
> one's start-up sequence, will provide for tidier source-management,
> easier maintenance, better control over the start-up process, less
> opportunity for any bugs in customize to manifest themselves and
> probably less bugs in initialisation.

Yes, please.  At least twice I've had to track down pernicious problems
that turned out to result from customize `stuff' being at the end of
.emacs.  I would much prefer a situation where customize modified a
different file, and .emacs contained a call to
`customize-do-customizations' or somesuch.

chad

Re: customize

[Per Abrahamsen]

chad <y@mit.edu> writes:

> I would much prefer a situation where customize modified a
> different file, and .emacs contained a call to
> `customize-do-customizations' or somesuch.

Could "somesuch" be:

  (setq custom-file "~/.custom")
  (load-file custom-file)

?

Re: customize

[chad]

Yes, in fact. :-)

This was already pointed out to me privately by eddy@opera.no.  Thanks
to you both.

chad

Re: customize

[Stefan Monnier]

> > I would much prefer a situation where customize modified a
> > different file, and .emacs contained a call to
> > `customize-do-customizations' or somesuch.
> 
> Could "somesuch" be:
> 
>   (setq custom-file "~/.custom")
>   (load custom-file)

BTW. How about changing startup.el such that custom-file is loaded
(after .emacs) if it has been set and if the file hasn't been loaded yet
(such that users only need to put (setq custom-file "~/.custom") in
their .emacs file) ?


	Stefan

Re: customize

[Edward Welbourne]

> BTW. How about changing startup.el such that custom-file is loaded
> (after .emacs) if it has been set and if the file hasn't been loaded
> yet (such that users only need to put (setq custom-file "~/.custom")
> in their .emacs file) ?
sounds a neat idea, unless it raises tiresome implementation issues ...

> Byte-compiling your customizations is a complete waste of precious time.
Why ?

Note that having robots do things can make the amount of precious time
involved very small ... and byte-compiling a file after I've edited it
takes less time than writing a quick reply to an e-mail ...

	Eddy.

Re: customize

[Stefan Monnier]

> > Byte-compiling your customizations is a complete waste of precious time.
> Why ?

Since it has no benefit whatsoever, it's pretty obvious that it's a waste
of time, given that you have to spend some time byte-compiling and/or
setting up an auto-byte-compile system.


	Stefan

Re: customize, futility of byte-compiling

[Edward Welbourne]

> Since it has no benefit whatsoever,
this is the bit that needs explained.
Why does byte-compilation gain no benefit ?
Is this specific to customizations, or generally true ?

	Eddy.

Re: customize, futility of byte-compiling

[Per Abrahamsen]

Edward Welbourne <eddy@opera.no> writes:

> Why does byte-compilation gain no benefit ?
> Is this specific to customizations, or generally true ?

The "customize" information is just a single function call, all the
real work is done by the function it calls.  So you can byte-compile
the call to the function, but that doesn't make the function itself
(where the time is spend) any faster.

Re: customize, futility of byte-compiling

[Stefan Monnier]

> > Since it has no benefit whatsoever,
> this is the bit that needs explained.

No, you got it wrong: the bit that needs to be explained is what
kind of benefit do you think there is.


	Stefan

Re: customize

[Richard Stallman]

    BTW. How about changing startup.el such that custom-file is loaded
    (after .emacs) if it has been set and if the file hasn't been loaded yet
    (such that users only need to put (setq custom-file "~/.custom") in
    their .emacs file) ?

I see nothing wrong with that.  Want to do it?

Re: customize

[Stefan Monnier]

>     BTW. How about changing startup.el such that custom-file is loaded
>     (after .emacs) if it has been set and if the file hasn't been loaded yet
>     (such that users only need to put (setq custom-file "~/.custom") in
>     their .emacs file) ?
> 
> I see nothing wrong with that.  Want to do it?

I use the patch below.  If there's no objection, I'll install it.
We can then change the manual's example to just be

	(setq custom-file "~/.emacs-custom")


-- Stefan


--- startup.el	4 Aug 2002 16:18:18 -0000	1.303
+++ startup.el	13 Aug 2002 16:25:37 -0000
@@ -932,6 +935,12 @@
 			      (sit-for 1))
 			    (setq user-init-file source))))
 		      
+		      (when (and (stringp custom-file)
+				 (not (assoc custom-file load-history)))
+			;; If the .emacs file has set `custom-file' but hasn't
+			;; loaded the file yet, let's load it.
+			(load custom-file t t))
+		      
 		      (or inhibit-default-init
 			  (let ((inhibit-startup-message nil))
 			    ;; Users are supposed to be told their rights.

Re: customize

[Richard Stallman]

It looks good to me.  Can you change the manual too?

Re: customize

[Stefan Monnier]

> It looks good to me.  Can you change the manual too?

Done.


	Stefan

Re: customize

[Per Abrahamsen]

Edward Welbourne <eddy@opera.no> writes:

>> custom-set-* doesn't have to come last in ~/.emacs.
> but customize always adds it at the end.
>
>> After it is there, you can add stuff in ~/.emacs after it.
> and get a layer-cake of intermingled fragments, some of one's own
> construction, others added by customize (and marked with a warning
> against modifying them other than via the customize UI), which will
> make it harder to keep track of what's going on, what one can safely
> modify, etc.; maintenance nightmare.

Unless something has changed drastically, customize will do the
following:

1. Scan custom-file for a custom-set-variables top level form.
2. Remove it if found, otherwise go to (or stay at) the end of the file.  
3. Insert a new custom-set-variables.

The effect of this is that if you move the custom-set-variables call,
it will stay put.  And there will only be one such call on the top
level, unless you yourself add an extra, in which case all bets are
off.

Same for custom-set-faces.

Maybe you have tried to move it to a nested form?  That won't work.

Re: customize

[Edward Welbourne]

> The effect of this is that if you move the custom-set-variables
> call, it will stay put.

neat.  However, new customizations will always go at the end of the
file: if I want some elisp to be run after *everything* that customize
controls (e.g. if I want it to be the last thing my ~/.emacs does),
I'm going to have to move that elisp each time I customize anything
new ... *unless* I keep the things customize controls in a separate
file and have ~/.emacs run my elisp after loading that custom-file.
Fortunately, the variable custom-file is there to let us do this.

The only issue is ensuring that folk who're comfortable writing elisp
*do* find out about custom-file when using customize - for which it
will suffice to mention custom-file (prominently enough) on the first
page of the UI that M-x customize throws up.

The only real problem (for anyone happy to write elisp) with
configuring emacs is lack of information: until one knows the right
name to ask for help about, it can be very hard to discover any clues
... which is sort of inevitable, if somewhat frustrating at times.
Mentioning relevant names on the pages customize offers would be a
great help.

	Eddy.

Re: customize

[Kai Großjohann]

Edward Welbourne <eddy@opera.no> writes:

> neat.  However, new customizations will always go at the end of the
> file: if I want some elisp to be run after *everything* that customize
> controls (e.g. if I want it to be the last thing my ~/.emacs does),
> I'm going to have to move that elisp each time I customize anything
> new ... *unless* I keep the things customize controls in a separate
> file and have ~/.emacs run my elisp after loading that custom-file.

No.  Customize just adds two statements, custom-set-variable and
custom-set-faces.  Once they are in .emacs, they stay put.  So you
move them to the beginning of the file, and there they stay.

Or is it not working that way for you?  If this is really the case,
then something strange must be going on and you should provide a
recipe to describe what happens.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: customize

[Edward Welbourne]

> Customize just adds two statements, custom-set-variable and
> custom-set-faces.
ah, each of which sets many, like setq can ?  Nice.

OK, I'd only used customize for one thing at a time thus far,
so it'd appeared to have one statement per thing to be set ...
mistaken extrapolation on my part here, exacerbated by paranoid
reading of the comments in the custom-set-* statements, which appeared
to say I shouldn't mess with them at all (which I read as not even
moving them).

That only leaves the scary behaviour I've had out of customize to
date, which I'll report on when next I'm exiting emacs, or re-starting
after a crash or re-boot (i.e. when I next don't have lots of state
held by live buffers) ... however, the downside of reliable software
(e.g. GNU/Linux and emacs in particular) is that this isn't guaranteed
to happen several times per day ... indeed, this emacs session is now
20 days old and showing no signs of trouble.

		Eddy.

Re: customize

[Robert J. Chassell]

   ... however, the downside of reliable software
   (e.g. GNU/Linux and emacs in particular) is that this isn't guaranteed
   to happen several times per day ... indeed, this emacs session is now
   20 days old and showing no signs of trouble.

I know the problem.  For testing purposes I start a separate instance
of Emacs, one that I call a `plain vanilla' Emacs since I do not load
my normal .emacs file, but start it `-q --no-site-file'.

Using this `plain vanilla' Emacs, I can load and evaluate a test
.emacs file or the customize expressions in my .emacs file or test
other features.

Here is the expression I use in my ~bob/.twmrc file


    "Vanilla Emacs 21 under GDB"  !"xterm -T 'GDB for Vanilla Emacs' \
                                  -n 'GDB for Vanilla Emacs'         \
                                  -bg mediumblue -fg white           \
                                  -geometry 80x24+965+4              \
                                  -wf -e gdb /usr/local/bin/emacs    \
                                  -x /home/bob/.gdb-vanilla-emacs-config & "


where /home/bob/.gdb-vanilla-emacs-config 
consists of:

    run -q --no-site-file --eval '(blink-cursor-mode 0)'

    show args



-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: customize

[Eli Zaretskii]

On Mon, 29 Jul 2002, Edward Welbourne wrote:

> new customizations will always go at the end of the
> file: if I want some elisp to be run after *everything* that customize
> controls (e.g. if I want it to be the last thing my ~/.emacs does),
> I'm going to have to move that elisp each time I customize anything
> new

That's why startup.el defines a few hooks.  Code that needs to be run at 
specific moments in the initialization phase should use those hooks 
rather than depend on its place in ~/.emacs.

Re: customize

[Eli Zaretskii]

On Mon, 29 Jul 2002, Edward Welbourne wrote:

> Having customize add everything it does to a single file, maintained
> entirely via the customize UI, loaded at a well-considered moment in
> one's start-up sequence, will provide for tidier source-management,
> easier maintenance, better control over the start-up process, less
> opportunity for any bugs in customize to manifest themselves and
> probably less bugs in initialisation.

I suspect that the problem of where exactly in the startup sequence to 
load that separate file, i.e. the problem of choosing that 
``well-considered moment'' is no less complicated than the ones you 
find in the current operation of the code.

Re: customize

[Richard Stallman]

    > I documented custom-face, but I don't see a reason to change the
    > default to use a different file.

    Jeff was discussing customisation of custom-file, not custom-face.

It was custom-file that I documented.  I wrote the wrong name in the
message.

      * Database reason: one file then contains only customize's actions,
	making it much easier to keep track of which pieces of one's
	config come from where.

It is easy enough to distinguish--the stuff written by Customize
is compact, distinctive, and clearly labeled.

      * Priority/ordering reason: customize adds things to the end of its
	file: this is sensible for it, but potentially bad for elisp which
	needs to be executed after customizations; using a separate file
	for customize lets my ~/.emacs load the customize part early, late
	or in between, at my option, rather than having it always be last.

There appears to be some controversy about whether this is really true.
Part of the controversy may be that your description of the problem
is heavy on emotions and the facts are not clear.

    > After it is there, you can add stuff in ~/.emacs after it.
    and get a layer-cake of intermingled fragments, some of one's own
    construction, others added by customize

Could you show an example of this?  As far as I know, customize writes
all its definitions for variables in a single sexp, and all its specs
for faces in a single sexp, and this can't produce very many layers.

If you show me what the problem looks like, maybe I can change Customize
to edit the file in a way that is more convenient.

      * Byte-compilation: putting it all in a separate .el file provides
	for the possibility of byte-compiling the customization elisp.

You can byte-compile .emacs, so is this really an advantage?

Re: customize

[Jeff Dwork]

Here is an example of my problem with customize writing to .emacs
file.  I use 19.34 and I'm transitioning to 21.  Many things I do in
my version 19 .emacs are done differently in version 21, so I don't
want 21 to see my 19 stuff and my 19 stuff may not understand my
version 21 stuff.  So I tested the version in .emacs.

This is:
  GNU Emacs 21.1.1 (i686-pc-linux-gnu, X toolkit) of 2002-02-19 on
  go002
All invocations are:
  emacs --no-site-file

I start with this in .emacs:
********************************************
(if (< emacs-major-version 21)
    (progn
      ; here we set load-path for emacs 19
      ; this is just a dummy for test
      (setq jrd-init-var "19")
      (setq jrd-init-var2 "xx")
      )
  ; here we set load-path for emacs 21 and later
  ; this is just a dummy for test
  (setq jrd-init-var "21")
  (setq jrd-init-var2 "yy")
  )
********************************************

I start emacs 21, customize a variable and save it for the future.
I now have this:

********************************************
(if (< emacs-major-version 21)
    (progn
      ; here we set load-path for emacs 19
      ; this is just a dummy for test
      (setq jrd-init-var "19")
      (setq jrd-init-var2 "xx")
      )
  ; here we set load-path for emacs 21 and later
  ; this is just a dummy for test
  (setq jrd-init-var "21")
  (setq jrd-init-var2 "yy")
  )
(custom-set-variables
  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 '(confirm-kill-emacs (quote y-or-n-p)))
(custom-set-faces
  ;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 )
********************************************

But this won't work because the custom-set-variables is outside the
if.  I could write some code to make emacs 19 ignore this function,
but I don't want to.  So I move custom-set-* inside the if.

********************************************
(if (< emacs-major-version 21)
    (progn
      ; here we set load-path for emacs 19
      ; this is just a dummy for test
      (setq jrd-init-var "19")
      (setq jrd-init-var2 "xx")
      )
  ; here we set load-path for emacs 21 and later
  ; this is just a dummy for test
  (setq jrd-init-var "21")

  ; move custom stuff so only emacs 21 sees it

(custom-set-variables
  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 '(confirm-kill-emacs (quote y-or-n-p)))
(custom-set-faces
  ;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 )


  (setq jrd-init-var2 "yy")
  )
********************************************

I run emacs 21 again and customize another variable and I get this:

********************************************
(if (< emacs-major-version 21)
    (progn
      ; here we set load-path for emacs 19
      ; this is just a dummy for test
      (setq jrd-init-var "19")
      (setq jrd-init-var2 "xx")
      )
  ; here we set load-path for emacs 21 and later
  ; this is just a dummy for test
  (setq jrd-init-var "21")

  ; move custom stuff so only emacs 21 sees it

(custom-set-variables
  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 '(confirm-kill-emacs (quote y-or-n-p)))
(custom-set-faces
  ;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 )


  (setq jrd-init-var2 "yy")
  )
(custom-set-variables
  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 '(confirm-kill-emacs (quote y-or-n-p))
 '(partial-completion-mode t nil (complete)))
(custom-set-faces
  ;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
  ;; Your init file should contain only one such instance.
 )
********************************************

Now we have two instances of custom-set-variables, which is not good.

If I leave the custom-set stuff where emacs 21 wrote it the first
time, I can add code after it and emacs will find what it wrote and
modify it correctly, although Eddy seems to have found problems with
this.  I only did a simple test.

In any case, this is all fixed by customizing custom-file.  Then
customize modifies a file that contains only code written by customize
and I can load custom-file from my .emacs however I want.

As long as custom-file has reasonably prominent mention in the initial
customize buffer, I don't think it is necessary to change the
default. 

Thanks for all your good works,
Jeff


Richard Stallman writes:
 > To: eddy@opera.no
 > cc: jeff.dwork@amd.com, emacs-devel@gnu.org
 > Subject: Re: customize
 > Date: Mon, 29 Jul 2002 19:00:00 -0600 (MDT)
 > 
 >     > I documented custom-face, but I don't see a reason to change the
 >     > default to use a different file.
 > 
 >     Jeff was discussing customisation of custom-file, not custom-face.
 > 
 > It was custom-file that I documented.  I wrote the wrong name in the
 > message.
 > 
 >       * Database reason: one file then contains only customize's actions,
 > 	making it much easier to keep track of which pieces of one's
 > 	config come from where.
 > 
 > It is easy enough to distinguish--the stuff written by Customize
 > is compact, distinctive, and clearly labeled.
 > 
 >       * Priority/ordering reason: customize adds things to the end of its
 > 	file: this is sensible for it, but potentially bad for elisp which
 > 	needs to be executed after customizations; using a separate file
 > 	for customize lets my ~/.emacs load the customize part early, late
 > 	or in between, at my option, rather than having it always be last.
 > 
 > There appears to be some controversy about whether this is really true.
 > Part of the controversy may be that your description of the problem
 > is heavy on emotions and the facts are not clear.
 > 
 >     > After it is there, you can add stuff in ~/.emacs after it.
 >     and get a layer-cake of intermingled fragments, some of one's own
 >     construction, others added by customize
 > 
 > Could you show an example of this?  As far as I know, customize writes
 > all its definitions for variables in a single sexp, and all its specs
 > for faces in a single sexp, and this can't produce very many layers.
 > 
 > If you show me what the problem looks like, maybe I can change Customize
 > to edit the file in a way that is more convenient.
 > 
 >       * Byte-compilation: putting it all in a separate .el file provides
 > 	for the possibility of byte-compiling the customization elisp.
 > 
 > You can byte-compile .emacs, so is this really an advantage?

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

[Stefan Monnier]

>   * Byte-compilation: putting it all in a separate .el file provides
>     for the possibility of byte-compiling the customization elisp.

Byte-compiling your customizations is a complete waste of precious time.


	Stefan

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.