Re: customize

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

[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