Re: Documentation for custom-file - is not (load custom-file) needed?

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

I read the various messages about custom-file, and this
is what I think we should do.

1. We should eliminate custom-file as a defcustom.

2. We should eliminate loading custom-file on startup.
   We should tell users that .emacs should load the appropriate file
   where custom values are stored.

3. Calling custom-set-variables in a file should add that file
   to a list of files that have done so.

4. Evaluating a custom-set-variables call in a buffer should not do
   any such thing.

5. When saving custom variables, if custom-file is set, save in that file.
   Otherwise, if they have only been loaded from one file, save in that
   file.  Otherwise, if they have been loaded from more than one file,
   save in the most recently loaded such file.

6. If the user wants to specify which file to save in,
   he can set custom-file or else just load that file.

7. Eventually, in the future, we might figure out some clean UI for
   specifying which custom files to use and load under which
   conditions, and for moving definitions between them, but that is
   something for later.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: <emacs-devel@gnu.org>
Sent: Monday, December 13, 2004 8:51 PM
Subject: Re: Documentation for custom-file - is not (load custom-file)
needed?


> I read the various messages about custom-file, and this
> is what I think we should do.
>
> 1. We should eliminate custom-file as a defcustom.

Yes. But I believe we also should try to eleminate it from the
(custom-set-variables ...) where it currently could be. Could that be done
by avoiding defvar too and using boundp later for the checks?


> 2. We should eliminate loading custom-file on startup.
>    We should tell users that .emacs should load the appropriate file
>    where custom values are stored.

Yes. But maybe we could reuse Stefans idea of loading "custom file" after
.emacs in another way. I would like to get (custom-set-variables ...) out of
.emacs by default, because I believe most users do not want it to be edited
automatically. Why not use another file name as default for
(custom-set-variables ...), say .emacs-custom? This file could be loaded by
startup.el if not loaded before, the way Stefan has suggested for "custom
file".


> 3. Calling custom-set-variables in a file should add that file
>    to a list of files that have done so.
>
> 4. Evaluating a custom-set-variables call in a buffer should not do
>    any such thing.

Why not?


> 5. When saving custom variables, if custom-file is set, save in that
file....
> 6. If the user wants to specify which file to save in,...
> 7. Eventually, in the future, we might figure out some clean UI for ...

I agree.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    Yes. But I believe we also should try to eleminate it from the
    (custom-set-variables ...) where it currently could be.

That seems risky to me, so I don't want to try it.

    Yes. But maybe we could reuse Stefans idea of loading "custom file" after
    .emacs in another way. I would like to get (custom-set-variables ...) out of
    .emacs by default, because I believe most users do not want it to be edited
    automatically.

Sorry, I don't want to go in that direction.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

I still do not see any benefit in all this complexity.

What is wrong with:

(setq custom-file ...)
(load ...)

in .emacs? This is what worked in the past and still works now.

The only thing wrong with it that has been pointed out to me are
problems caused by the automatic loading of `custom-file' after
.emacs.  You plan to eliminate that feature (something I agree with),
thereby solving those problems.  The second problem with the current
situation is that customizing through Custom might mislead some users.
You plan to eliminate the defcustom, which solves that problem.  Which
problems are left?

The proposed solution could cause non-trivial trouble for unsuspecting
users, who are in danger of having several files clobbered behind
their back before they notice or understand the problem (see below).

Details:

   2. We should eliminate loading custom-file on startup.
      We should tell users that .emacs should load the appropriate file
      where custom values are stored.

I completely agree that it is better to revert the automatic loading
of custom-file after the loading of .emacs.  This simplifies things
and restores backward compatibility with prior released versions.
Indeed, setting custom-file means only one thing: that the user wants
Custom to write into that file.  If the user wants in addition to load
that file, he can do so.

   1. We should eliminate custom-file as a defcustom.

I do not really disagree with removing the defcustom.  It breaks
backward compatibility to a degree, but on the other hand. it
simplifies things.  It is relatively easy for the user who (like me)
used Custom in the past to adapt.

   3. Calling custom-set-variables in a file should add that file
      to a list of files that have done so.

   4. Evaluating a custom-set-variables call in a buffer should not do
      any such thing.

   5. When saving custom variables, if custom-file is set, save in that file.
      Otherwise, if they have only been loaded from one file, save in that
      file.  Otherwise, if they have been loaded from more than one file,
      save in the most recently loaded such file.

There are (at least) four things wrong with 2-5 above.  Firstly, it
adds complexity for no good reason.  Secondly it breaks backward
compatibility.  Thirdly, it introduces a shaky temporary solution to
something that is currently not really broken and for which we plan to
implement a more solid alternative later on anyway (by 7.). 

Fourthly, and importantly, I believe it is wrong to clobber a user's
file unless the user explicitly asked for Custom to write into that
file by setting custom-file.  People who use outside packages like
initsplit may be in for quite a surprise and a lot of unexpected
trouble with all their customization files getting clobbered one by
one, before they notice the problem.  This is way more serious than
adding a trailing newline.

   6. If the user wants to specify which file to save in,
      he can set custom-file or else just load that file.

These are two different things.  If the user wants to specify which
file to save in, he can set custom-file.  If he wants to load that
file, he can load that file.

   7. Eventually, in the future, we might figure out some clean UI for
      specifying which custom files to use and load under which
      conditions, and for moving definitions between them, but that is
      something for later.

That would require a very careful rewrite of Custom.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    There are (at least) four things wrong with 2-5 above.  Firstly, it
    adds complexity for no good reason.

It is for a very good reason: to enable custom to edit the right file,
the one that was loaded.  That's well worth this small amount of
complexity.

					 Secondly it breaks backward
    compatibility.

I don't see any significant incompatibility.  The file edited in this
way will usually be the same one.  Only the reason for choosing it
will be different.  A small amount of incompatibility in something
unusual and advanced like this is no big deal.

    Thirdly, it introduces a shaky temporary solution to
    something that is currently not really broken and for which we plan to
    implement a more solid alternative later on anyway (by 7.). 

#7 is not a plan to implement anything.  It just recognizes the
possibility that someday we might go further.  For the present, the
only plan is what I've stated in points 1-6.

Would someone like to implement some or all of this plan?

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:
   
   A small amount of incompatibility in something unusual and advanced
   like this is no big deal.

If I understand your proposal correctly, if the user has a non-nil
custom file, nothing changes compared to 21.3.  The file will no
longer be automatically loaded after .emacs as in current CVS, but
that did not happen in 21.3 anyway.

So the only problem concerns the case where custom-file is nil.

If custom-file is nil, the user currently expects Custom to write
exclusively into .emacs.  All current packages the user is using
expect that.

Here is a very concrete example where your proposed change could cause
trouble.  From initsplit.el (not included with the Emacs distribution
but used by some people):

;; Note that that you *must* load each file that contains your various
;; customizations from your .emacs.  Otherwise, the variables won't
;; all be set, and the next time you use the customize interface, it
;; will delete the settings in those other files.

You are going to save in the last of those files, which are written in
some random order.  If I understand correctly, with custom-file being
nil, initsplit is watching .emacs for customizations being written in
there, to delete them from .emacs and put them in the correct
(according to the user) files.

Even if by some miracle your proposed changes would not break initsplit,
they are likely to break other similar packages.

Second scenario where your changes could cause trouble:

The user may load several files with `custom-set-variables' forms to
add a set of customizations to his .emacs.  Then he just nominally
saves some option using Custom to make Custom write all the stuff into
.emacs.  So you save everything in the last file he loaded.  I hope he
notices before he deletes that file.  I also hope that he does not use
that file for other purposes.

I understand the reasons for no longer automatically loading
custom-file after .emacs.  I understand the reasons for removing the
defcustom.  I do not understand what problems would remain after that.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    You are going to save in the last of those files, which are written in
    some random order.  If I understand correctly, with custom-file being
    nil, initsplit is watching .emacs for customizations being written in
    there, to delete them from .emacs and put them in the correct
    (according to the user) files.

initsplit may need to be changed to cope with the new behavior of
Emacs.  That is normal: something that overrides part of Emacs
probably will need to be changed when that part of Emacs changes.

This is not a reason to avoid making useful changes in Emacs.

    The user may load several files with `custom-set-variables' forms to
    add a set of customizations to his .emacs.  Then he just nominally
    saves some option using Custom to make Custom write all the stuff into
    .emacs.  So you save everything in the last file he loaded.

What Emacs would do at present is write all of them into .emacs, which
is probably also not what he wants.  The new behavior won't be any
worse for him than the current behavior.  Therefore, there is no
argument here against the change.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:

   initsplit may need to be changed to cope with the new behavior of
   Emacs.  That is normal: something that overrides part of Emacs
   probably will need to be changed when that part of Emacs changes.

All initsplit has to do is:

(unless custom-file (setq custom-file user-initfile))

(If I understood correctly, setting `custom-file' non-nil will
ensure this is the file that is going to be written into.)

However, somebody who upgrades Emacs to 21.4 will usually not upgrade
initsplit at the same time.  Such a person is in for some surprise.
All he has to do is `(setq custom-file "~/.emacs")', except that the
user will not be aware of anything.  (Unless he was able to find it
buried in NEWS, which has grown huge, and understood the implications
for initsplit.)

It looks like I am not going to be able to convince you that this is a
very bad idea.  However, I hope that, if `custom-file' is not set, you
are at least going to _ask_ the user before writing into any file he
did not ask you to write into.  Some people got very upset about Emacs
adding a final newline behind their backs.  Clobbering
`custom-set-variables' forms behind the user's back would be
substantially worse.

By the way, what do you plan to do if Emacs is started with `emacs -q'?

       The user may load several files with `custom-set-variables' forms to
       add a set of customizations to his .emacs.  Then he just nominally
       saves some option using Custom to make Custom write all the stuff into
       .emacs.  So you save everything in the last file he loaded.

   What Emacs would do at present is write all of them into .emacs, which
   is probably also not what he wants.

But that is why he loaded them.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

>From my previous message:

   All initsplit has to do is:

   (unless custom-file (setq custom-file user-initfile))

I meant user-init-file, obviously.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

In general, issues of what would happen when advanced users do obscure
and unusual things do not carry a lot of weight.  Even if something
mildly unfortunate happens in these scenarios, it is not a strong argument
against a change.  The users who do this will just have to cope.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:

   In general, issues of what would happen when advanced users do obscure
   and unusual things do not carry a lot of weight.  Even if something
   mildly unfortunate happens in these scenarios, it is not a strong argument
   against a change.  The users who do this will just have to cope.

I believe that nearly every user of Emacs has some specialized
(i.e. obscure and unusual) needs of one form or the other.  The more
unexpected things happen in such situations, the less reliable Emacs
becomes and reliability is, to me, one of the most important aspects
of the quality of a program.

I really do not want to go on forever about this, but I still want to
point out one last time how easy the alternative is:

(1)  Disable automatic loading of custom-file after .emacs.

(2)  Make the defcustom into a defvar.  Even better (but this is a
     minor issue): leave the defcustom, but put in a not to be missed
     warning in the Custom buffer.  The latter provides full 100%
     backward compatibility and helps people who use Custom as a
     browser (which means most people).

(3) Tell people who want to customize `custom-file' to put:
   
    (setq custom-file "~/mycustom.el")
    (load custom-file)

    in their .emacs (or something more complex for version specific
    customization).

End of problem.  In case of the latter version of (2), there is 100%
backward compatibility and zero chance of confusing or inconveniencing
people.  With the former version of (2), it is pretty close: only
people who used Custom before (like me) have to watch out and do
something.

I do not know what problem you are trying to solve that is worth the
trouble that your more complex solution would create: (1) solves the
repeated loading problem, (2) solves the Custom problem and I am
unaware of any other problems that have been reported.

Is the problem that the user has to write two lines into .emacs
instead of one?  Given that this only has to be done either once or
for every new Emacs version, this seems completely insignificant.

Is the remaining problem is that a beginning user might load a file
with a `custom-set-variables' form that is not his custom-file,
without fully know what he is doing?  If so, we could treat that more
or less like a disabled command.  Warn and provide a variable to
eliminate the warning.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Richard Stallman wrote:
>
> I really do not want to go on forever about this, but I still want to
> point out one last time how easy the alternative is:
>
> (2)  ... Even better (but this is a
>      minor issue): leave the defcustom, but put in a not to be missed
>      warning in the Custom buffer.  The latter provides full 100%
>      backward compatibility and helps people who use Custom as a
>      browser (which means most people).


IMHO, this is a perfect solution for 21.4 -- it doesn't change any
functionality which isn't more broken now than it was before.

And for me it has worked just fine for years, so IMO it's not broken
at all.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    I believe that nearly every user of Emacs has some specialized
    (i.e. obscure and unusual) needs of one form or the other.

I don't think so, but even if it were true, the relevant question is
what fraction have done made some sort of peculiar customization
*in this very spot*.  The number who have done so *anywhere in Emacs*
is not relevant.

    (3) Tell people who want to customize `custom-file' to put:

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

	in their .emacs (or something more complex for version specific
	customization).

Ok, I am convinced on this point.  This is not much extra work for the
user, and the added reliability is worth imposing the small extra work.

Would you like to implement these changes?

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:

       (3) Tell people who want to customize `custom-file' to put:

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

	   in their .emacs (or something more complex for version specific
	   customization).

   Ok, I am convinced on this point.  This is not much extra work for the
   user, and the added reliability is worth imposing the small extra work.

   Would you like to implement these changes?

Yes, I will implement them.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Here are my suggested changes for `custom-file'.  Most of them are
documentation changes.

The patches keep the defcustom.  However, the user wanting to
customize it through Custom gets an emphatic warning in the Custom
buffer, that is nearly impossible to overlook, when he chooses "File"
from the "Value Menu".

Reasons for keeping the defcustom are:
 
1. Some people may be used to it, and even in its present form, it
   has some conveniences.
2. Custom is also an option _browser_, and even people who
   never use Custom to set options use it as a browser.
3. After the release we might try to implement ways of making 
   customizing `custom-file' through Custom even more convenient and
   less confusing.

There are two code changes.  The first is that `custom-file' will no
longer be automatically loaded after .emacs.  This means that the
behavior will stay as it was in the last released version, 21.3.  This
prevents problems with double loading, as well as potential confusion
when a user occasionally would use versions of Emacs earlier than 21.4.

The second code change is that the _function_ `custom-file' would do
exactly what its docstring says, namely:

	Return the file name for saving customizations.

It would no longer set the variable custom-file to that file name.
That is, if the variable custom-file is nil, the function would still
return "/home/USERNAME/.emacs", or such, but the variable custom-file
would remain nil instead of being set to "/home/USERNAME/.emacs".
There is no need for the function to set the variable.  It is only
used to pass the correct file name to `find-file-noselect'.  Setting the
variable confuses Custom when one customizes the variable and then
changes one's mind and chooses "Erase Customization".  Instead of
resetting it to nil: "Your Emacs init file", it resets it to
"File: /home/USERNAME/.emacs" and claims it was customized outside
Custom.  A _second_ "Erase Customization" then really gets back to:
"Your Emacs init file".  It is all very confusing.  The patch to
cus-edit.el below fixes the problem.

===File ~/startup.el-diff===================================
*** startup.el	30 Nov 2004 16:54:10 -0600	1.335
--- startup.el	21 Dec 2004 19:39:02 -0600	
***************
*** 863,874 ****
  			      (sit-for 1))
  			    (setq user-init-file source))))
  
- 		      (when (stringp custom-file)
-                         (unless (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)))
- 
  		      (unless inhibit-default-init
                          (let ((inhibit-startup-message nil))
                            ;; Users are supposed to be told their rights.
--- 863,868 ----
============================================================

===File ~/cus-edit.el-diff==================================
*** cus-edit.el	14 Dec 2004 07:57:19 -0600	1.203
--- cus-edit.el	22 Dec 2004 17:42:42 -0600	
***************
*** 3699,3733 ****
  as specified by `user-init-file'.  If the value is not nil,
  it should be an absolute file name.
  
! To make this feature work, you'll need to put something in your
! init file to specify the value of `custom-file'.  Just
! customizing the variable won't suffice, because Emacs won't know
! which file to load unless the init file sets `custom-file'.
! 
! When you change this variable, look in the previous custom file
! \(usually your init file) for the forms `(custom-set-variables ...)'
! and `(custom-set-faces ...)', and copy them (whichever ones you find)
! to the new custom file.  This will preserve your existing customizations."
!   :type '(choice (const :tag "Your Emacs init file" nil) file)
    :group 'customize)
  
  (defun custom-file ()
    "Return the file name for saving customizations."
!   (setq custom-file
! 	(or custom-file
! 	    (let ((user-init-file user-init-file)
! 		  (default-init-file
! 		    (if (eq system-type 'ms-dos) "~/_emacs" "~/.emacs")))
! 	      (when (null user-init-file)
! 		(if (or (file-exists-p default-init-file)
! 			(and (eq system-type 'windows-nt)
! 			     (file-exists-p "~/_emacs")))
! 		    ;; Started with -q, i.e. the file containing
! 		    ;; Custom settings hasn't been read.  Saving
! 		    ;; settings there would overwrite other settings.
! 		    (error "Saving settings from \"emacs -q\" would overwrite existing customizations"))
! 		(setq user-init-file default-init-file))
! 	      user-init-file))))
  
  (defun custom-save-delete (symbol)
    "Visit `custom-file' and delete all calls to SYMBOL from it.
--- 3699,3755 ----
  as specified by `user-init-file'.  If the value is not nil,
  it should be an absolute file name.
  
! You can set this option through Custom, if you carefully read the
! last paragraph below.  However, usually it is simpler to write
! something like the following in your init file:
! 
! \(setq custom-file \"~/.emacs-custom.el\")
! \(load custom-file)
! 
! Note that both lines are necessary: the first line tells Custom to
! save all customizations in this file, but does not load it.
! 
! When you change this variable outside Custom, look in the
! previous custom file \(usually your init file) for the
! forms `(custom-set-variables ...)'  and `(custom-set-faces ...)',
! and copy them (whichever ones you find) to the new custom file.
! This will preserve your existing customizations.
! 
! If you save this option using Custom, Custom will write all
! currently saved customizations, including the new one for this
! option itself, into the file you specify, overwriting any
! `custom-set-variables' and `custom-set-faces' forms already
! present in that file.  It will not delete any customizations from
! the old custom file.  You should do that manually if that is what you
! want.  You also have to put something like `\(load \"CUSTOM-FILE\")
! in your init file, where CUSTOM-FILE is the actual name of the
! file.  Otherwise, Emacs will not load the file when it starts up,
! and hence will not set `custom-file' to that file either."
!   :type '(choice (const :tag "Your Emacs init file" nil)
! 		 (file :format "%t:%v%d"
! 		       :doc
! 		       "Please read entire docstring below before setting \
! this through Custom.
! Click om \"More\" \(or position point there and press RETURN)
! if only the first line of the docstring is shown."))
    :group 'customize)
  
  (defun custom-file ()
    "Return the file name for saving customizations."
!   (or custom-file
!       (let ((user-init-file user-init-file)
! 	    (default-init-file
! 	      (if (eq system-type 'ms-dos) "~/_emacs" "~/.emacs")))
! 	(when (null user-init-file)
! 	  (if (or (file-exists-p default-init-file)
! 		  (and (eq system-type 'windows-nt)
! 		       (file-exists-p "~/_emacs")))
! 	      ;; Started with -q, i.e. the file containing
! 	      ;; Custom settings hasn't been read.  Saving
! 	      ;; settings there would overwrite other settings.
! 	      (error "Saving settings from \"emacs -q\" would overwrite existing customizations"))
! 	  (setq user-init-file default-init-file))
! 	user-init-file)))
  
  (defun custom-save-delete (symbol)
    "Visit `custom-file' and delete all calls to SYMBOL from it.
============================================================

===File ~/custom.texi-diff==================================
*** custom.texi	08 Dec 2004 17:34:48 -0600	1.71
--- custom.texi	21 Dec 2004 20:13:09 -0600	
***************
*** 487,507 ****
    The customization buffer normally saves customizations in
  @file{~/.emacs}.  If you wish, you can save customizations in another
  file instead.  To make this work, your @file{~/.emacs} should set
! @code{custom-file} to the name of that file.  If you are using Emacs
! version 21.4 or later, Emacs loads the file right after your
! @file{.emacs} if you did not load it already.  In earlier versions,
! you have to load the file in your @file{~/emacs}.  If you customize
! @code{custom-file} through the @samp{Customize} interface, you still
! need to load it in your @file{.emacs}, but there is no need to set
! it.  For example:
  
  @example
! ;; @r{if not set through the @samp{Customize} interface:}
! (setq custom-file "~/.emacs-custom")
! 
! ;; @r{in Emacs versions before 21.4 or if set through}
! ;; @r{the @samp{Customize} interface.}
! (load "~/.emacs-custom")
  @end example
  
    You can also use @code{custom-file} to specify different
--- 487,497 ----
    The customization buffer normally saves customizations in
  @file{~/.emacs}.  If you wish, you can save customizations in another
  file instead.  To make this work, your @file{~/.emacs} should set
! @code{custom-file} to the name of that file and load it.  For example:
  
  @example
! (setq custom-file "~/.emacs-custom.el")
! (load custom-file)
  @end example
  
    You can also use @code{custom-file} to specify different
============================================================

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

I think your changes are good.  But please wait another week to see
if any new critiques are made.  Some people may be slow to respond
now due to vacation.

  There is probably also something
in etc/NEWS that needs to be removed.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stalman wrote:

     There is probably also something in etc/NEWS that needs to be removed.

I could not find anything.  `C-s custom-file', `C-s RET C-w custom file'
and the like, even `C-s custom', gave nothing.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

>From my previous reply:

      7. Eventually, in the future, we might figure out some clean UI for
	 specifying which custom files to use and load under which
	 conditions, and for moving definitions between them, but that is
	 something for later.

   That would require a very careful rewrite of Custom.

I might have misunderstood here.  Safely switching between multiple
custom files and multiple `custom-set-variables' forms in one single
Emacs session, without them clobbering each other, is tricky and would,
I believe, correspond to a rewrite of Custom.  It is not impossible,
because, for instance, initsplit does it.  On the other hand. using
different custom files for different Emacs versions or for different
Emacs sessions is not tricky at all.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[LENNART BORGMAN]

----- Original Message -----
From: Luc Teirlinck <teirllm@dms.auburn.edu>

> Here are my suggested changes for `custom-file'.  Most of them are
> documentation changes.
> 
> The patches keep the defcustom.  However, the user wanting to
> customize it through Custom gets an emphatic warning in the Custom
> buffer, that is nearly impossible to overlook, when he chooses "File"
> from the "Value Menu".

This is fine except for two smaller points:

1) I think that custom-file should not be saved to "the custom file" because of the problems we discussed before when renaming or copying this file. Is there any reason to save custom-file? Could it not just be removed before the actual saving?

2) I believe some "prompt screen" should be shown when custom-file is removed as above.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Lennart Borgman wrote:

   I think that custom-file should not be saved to "the custom file"
   because of the problems we discussed before when renaming or
   copying this file.

If you rename the file, you will have to have to make some additional
changes, whether you customized it through Custom or not.  Obviously,
the easiest thing to do is not to rename the file.  I do not
understand the problems when copying the file (to have a backup
presumably).  I have done so several times.  Actually, I have
backup-by-copying set to true, so my custom-files get copied every
time a backup is made.  I never noticed a problem.

   Is there any reason to save custom-file? Could it not just be
   removed before the actual saving?

If we would do that, it would be a lot better just to turn the
defcustom into a defvar.

The latter _is_ an obvious alternative to the patches I proposed.
_If_ we pretty much decide that we are happy with the situation that
would result after such a removal and that we do not plan to re-add
the defcustom with some fancy interface later, that might make sense.
There would be a one-time problem for people who customized it with
Custom before.  They would have to set `custom-file' in their .emacs
and manually remove the line from their `custom-set-variables' form.
We would have to point that out in the NEWS (and hope that people
actually read it).

However, if there is a non-negligible probability that we might want to
make additional changes later, it is better to leave everything as it
is right now (with just doc and bug fixes), as my patch does.  Every
final solution we come up with has to be compatible with the way
things worked in earlier versions.  Having intervening versions with
different rules will tie our hands badly.

Keeping the defcustom essentially means that we do not break anything
that was not broken before.  The defcustom for `custom-file' has
apparently existed for as long as Custom itself has.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>


> Lennart Borgman wrote:
>
>    I think that custom-file should not be saved to "the custom file"
>    because of the problems we discussed before when renaming or
>    copying this file.
>
> If you rename the file, you will have to have to make some additional
> changes, whether you customized it through Custom or not.  Obviously,
> the easiest thing to do is not to rename the file.  I do not
> understand the problems when copying the file (to have a backup
> presumably).  I have done so several times.  Actually, I have
> backup-by-copying set to true, so my custom-files get copied every
> time a backup is made.  I never noticed a problem.
>
>    Is there any reason to save custom-file? Could it not just be
>    removed before the actual saving?
>
> If we would do that, it would be a lot better just to turn the
> defcustom into a defvar.

I have been hesitating to answer to this because of our long discussion. My
main points are:

1) Having "custom-file" saved to custom-set-variables means I can not copy
"custom file" to a new location or computer without editing it. Easy to
forget since it may be a bit unexpected that you save the file name into the
file. Saving a little bit of time for potentially many users is a good
thing. That is why I suggest that "custom-file" should not be saved to "the
custom file".

2) A GUI interface should be very helpful since most users will not try to
read much of the help texts when using it. I think Emacs "custom" is such an
interface. That is why I think the user should be noted clearly when (and
if) "custom-file" is not saved.

As you have pointed out earlier there are advantages with having something
like defcustom for changing "custom-file". However it is also clear that the
current defcustom is not really what we want. I think that the problems are
exactly at the point when "custom-file" is saved and this is probably what
we will discuss later. My suggestions are a workaround for the saving
problem.

Having said this I will try to shut up on this until after release.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Lennart Borgman wrote:

   1) Having "custom-file" saved to custom-set-variables means I can not copy
   "custom file" to a new location or computer without editing it.

You do not have to edit it.  Just customize it again through Custom.
If you set custom-file in your .emacs, you have to edit .emacs anyway.
You have to do _something_, no matter what.  You can not possibly
rename or copy a file and expect Emacs to know that you did this
without telling it anything.

   Saving a little bit of time for potentially many users is a good
   thing.

It will _not_ be many users.  If you try to customize this through
Custom, and choose "File", you immediately get warned not do this
without reading the docstring carefully.

You then get provided with two lines that you can kill and yank into
.emacs and the docstring recommends that you just do that instead of
customizing through Custom.

   2) A GUI interface should be very helpful since most users will not try to
   read much of the help texts when using it.

There are many defcustoms that are much more dangerous to customize
blindly than this one.  In this case you get clearly warned and even
told that you probably want to set this in .emacs instead.

   I think that the problems are exactly at the point when
   "custom-file" is saved and this is probably what we will discuss
   later.

I have no problem with rediscussing anything after the release.  But
unless we would decide to go for the ultimate and final solution right
now, I believe that it is better to leave everything essentially like
it is, but with better, more emphatic and more difficult to overlook
documentation, as my patch does.

Once more, the defcustom is kept for three reasons:

1.  For people who are used to customize custom-file that way.  Many
    of them do not consider the current brehavior broken or buggish at
    all.  A change in behavior could potentially be confusing to them.

2.  For people who use Custom as a browser.  They get told to read the
    docstring, which provides two lines that can be killed and yanked
    into .emacs.

3.  Not to have one or two Emacs versions with very exceptional
    implementations that we would need to be compatible with should we
    want to change this again.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    There are many defcustoms that are much more dangerous to customize
    blindly than this one.

If you suggest specific ones, we could do something to warn users
who customize them.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

>From my previous message:

   If you rename the file, you will have to have to make some additional
   changes, whether you customized it through Custom or not.  Obviously,
   the easiest thing to do is not to rename the file.

Actually, if you have backup-by-copying set to nil, custom-file _will_
be renamed when a back-up file is made.  But I do not believe that
yields any problems.  The correct file will still be loaded and
written to (and not the backup).

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[LENNART BORGMAN]

----- Original Message -----
From: storm@cua.dk (Kim F. Storm)

> > I really do not want to go on forever about this, but I still 
> want to
> > point out one last time how easy the alternative is:
> >
> > (2)  ... Even better (but this is a
> >      minor issue): leave the defcustom, but put in a not to be 
> missed>      warning in the Custom buffer.  The latter provides 
> full 100%
> >      backward compatibility and helps people who use Custom as a
> >      browser (which means most people).
> 
> 
> IMHO, this is a perfect solution for 21.4 -- it doesn't change any
> functionality which isn't more broken now than it was before.

If this is the way we are going then please put that warning so it can not be missed. In my opinion it should then be when custom-file is saved. At that moment a check should be made if the variable `custom-file' is among those that are beeing saved. It should then be removed from the list of variables that are going to be saved and a warning screen about this should be shown, telling the user how to instead save that variable (for example by editing .emacs).

I previously suggested that it would be in the GUI part, but that is not a very good place. 

- Lennart

Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

I believe that (load custom-file) is needed in .emacs to get it to work, but
the documentation does not say so.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>


> I believe that (load custom-file) is needed in .emacs to get it to work,
but
> the documentation does not say so.

I got no replies yet and I think I should fill in some misses pieces I
noticed after posting this.

The doc string for custom-file says "If you specify some other file, you
need to explicitly load that file for the settings to take effect". Info
however says "Emacs loads the file right after your `.emacs' if you did not
load it already". One of these must be wrong.

I see another problem here too of course, with the double documentation.

- Lennart

PS: And I hope that I this time sends the reply to the list instead of
myself ;-)

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    The doc string for custom-file says "If you specify some other file, you
    need to explicitly load that file for the settings to take effect". Info
    however says "Emacs loads the file right after your `.emacs' if you did not
    load it already". One of these must be wrong.

I just looked at the code, and the latter is correct.
So my previous doc change is not right.  I will fix it.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:

       The doc string for custom-file says "If you specify some other
       file, you
       need to explicitly load that file for the settings to take
       effect". Info
       however says "Emacs loads the file right after your `.emacs' if
       you did \not
       load it already". One of these must be wrong.

   I just looked at the code, and the latter is correct.
   So my previous doc change is not right.  I will fix it.

Unless I am completely missing something, it would appear that, unless
some other (doc or code) fixes are made, problems remains for people
trying to set `custom-file' through Custom, as Lennart pointed out
before.

Present docstring:

  (defcustom custom-file nil
    "File used for storing customization information.
  The default is nil, which means to use your init file
  as specified by `user-init-file'.

  When you change this variable, look in the previous custom file
  \(usually your init file) for the forms `(custom-set-variables ...)'
  and `(custom-set-faces ...)', and copy them (whichever ones you find)
  to the new custom file.  This will preserve your existing customizations."

Problems:

1.  Fails to point out that saving this through Custom without taking
    additional steps will not work, because Custom will store
    `custom-file' in `custom-file' as Lennart pointed out.  Emacs will
    _not_ load custom-file after .emacs, because `custom-file' will
    still be nil.

2.  Maybe the docstring should warn the user to use an absolute file
    name.  (This may not be obvious at all to a beginning user.)  Very
    confusing things can happen if a relative file name is used when
    setting this through Custom with a bad default-directory.

3.  The last paragraph fails to point out that if you set `custom-file'
    through Custom, Custom will automatically copy your
    `custom-set-variables' and `custom-set-faces' forms to
    `custom-file'.  (But it will not erase them from .emacs or the old
    `custom-file'.)

I could propose an alternate docstring, as well as maybe some changes
to `(emacs)Saving Customizations', if we decide to leave the code
unchanged.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    2.  Maybe the docstring should warn the user to use an absolute file
	name.  (This may not be obvious at all to a beginning user.)  Very
	confusing things can happen if a relative file name is used when
	setting this through Custom with a bad default-directory.

I will explain that in the doc string.

    3.  The last paragraph fails to point out that if you set `custom-file'
	through Custom, Custom will automatically copy your
	`custom-set-variables' and `custom-set-faces' forms to
	`custom-file'.  (But it will not erase them from .emacs or the old
	`custom-file'.)

If it is smart enough to do this, it could also delete them from
the old custom file.  Would you like to implement that?

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:
   
   If it is smart enough to do this, it could also delete them from
   the old custom file.  Would you like to implement that?

Deleting them from the old custom file is definitely not always going
to be desirable.  It usually will be if the old file is .emacs, but
not if the old custom file is .emacs-21.3 and the new one .emacs-21.4.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    Deleting them from the old custom file is definitely not always going
    to be desirable.  It usually will be if the old file is .emacs, but
    not if the old custom file is .emacs-21.3 and the new one .emacs-21.4.

Perhaps it would be ok to the user whether to delete them. 
Otherwise we just have to warn the user about the issue, as
I think you recently proposed.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

When I previously replied, I had not seen your latest version.
That version takes care of one of the problems I mentioned.  The
version in the patch below takes care of the two others. It also fixes
some other things:

1.  It says when the file is loaded if you do not do it yourself.
    There are situations where that can matter.

2.  The current docstring does not make clear that you do not need to
    set `custom-file' in your init file, if you set it through Custom
    and explicitly load it in your init file, which to me seems
    somewhat cleaner anyway, if you set it with a defcustom elsewhere.

3.  It explains why it is _not_ outright silly to set it through Custom,
    even though you have to edit .emacs anyway.

I can install if desired.

===File ~/cus-edit.el-diff==================================
*** cus-edit.el	05 Dec 2004 19:05:44 -0600	1.200
--- cus-edit.el	05 Dec 2004 20:33:52 -0600	
***************
*** 3677,3693 ****
  ;;;###autoload
  (defcustom custom-file nil
    "File used for storing customization information.
! The default is nil, which means to use your init file
! as specified by `user-init-file'.  To make this feature work,
! you'll need to put something in your init file to specify
! the value of `custom-file'.  Just customizing the variable
! won't suffice, because Emacs won't know which file to load
! unless the init file sets `custom-file'.
  
  When you change this variable, look in the previous custom file
  \(usually your init file) for the forms `(custom-set-variables ...)'
  and `(custom-set-faces ...)', and copy them (whichever ones you find)
! to the new custom file.  This will preserve your existing customizations."
    :type '(choice (const :tag "Your Emacs init file" nil) file)
    :group 'customize)
  
--- 3677,3701 ----
  ;;;###autoload
  (defcustom custom-file nil
    "File used for storing customization information.
! The default is nil, which means to use your init file as specified by
! `user-init-file'.  If non-nil, use an absolute file name.
! 
! If you set this variable in your init file, Emacs automatically
! loads the file after your init file, if you did not load it earlier.
! If you set this variable through Custom, you have to put
! `(load \"CUSTOM-FILENAME\") in your init file.  Certain features of
! Custom work better if you set all your user options through
! Custom.  Thus, setting this variable through Custom makes sense,
! even though you still have to edit your init file.
  
  When you change this variable, look in the previous custom file
  \(usually your init file) for the forms `(custom-set-variables ...)'
  and `(custom-set-faces ...)', and copy them (whichever ones you find)
! to the new custom file.  This will preserve your existing customizations.
! If you set this option through Custom, while your old custom file is
! loaded, Custom copies the forms for you, but also leaves them
! in the old file.  You might want to delete them from the old file
! after checking that they got copied correctly."
    :type '(choice (const :tag "Your Emacs init file" nil) file)
    :group 'customize)
  
============================================================

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    2.  The current docstring does not make clear that you do not need to
	set `custom-file' in your init file, if you set it through Custom
	and explicitly load it in your init file, which to me seems
	somewhat cleaner anyway, if you set it with a defcustom elsewhere.

    3.  It explains why it is _not_ outright silly to set it through Custom,
	even though you have to edit .emacs anyway.

We're still considering whether to change this, so let's finish
that before we work further on documenting such details.

Re: Documentation for custom-file - is not (load custom-file) needed?

[John Paul Wallington]

> I believe that (load custom-file) is needed in .emacs to get it to work, but
> the documentation does not say so.

I don't think so.  Have you tested whether that is the case?

AFAICT, Stefan added some code to startup.el on 2002-08-14 to load
custom-file if it hasn't been done in .emacs.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "John Paul Wallington" <jpw@gnu.org>


> > I believe that (load custom-file) is needed in .emacs to get it to work,
but
> > the documentation does not say so.
>
> I don't think so.  Have you tested whether that is the case?
>
> AFAICT, Stefan added some code to startup.el on 2002-08-14 to load
> custom-file if it hasn't been done in .emacs.

Sorry, yes, you are right. custom-file is loaded after .emacs if not done
before in CVS Emacs but not in the current release version. I missed that.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Lennart Borgman wrote:

   ----- Original Message ----- 
   From: "John Paul Wallington" <jpw@gnu.org>


   > > I believe that (load custom-file) is needed in .emacs to get it to work,
   but
   > > the documentation does not say so.
   >
   > I don't think so.  Have you tested whether that is the case?
   >
   > AFAICT, Stefan added some code to startup.el on 2002-08-14 to load
   > custom-file if it hasn't been done in .emacs.

   Sorry, yes, you are right. custom-file is loaded after .emacs if not done
   before in CVS Emacs but not in the current release version. I missed that.

Yes, but how does it work?  As you pointed out in an earlier
posting, if you put all your customizations in CUSTOM-FILE, then
custom-file is customized in CUSTOM-FILE.  How can Stefan's code,
referred to above, figure out the value of custom-file?

So either you have to put:

(load CUSTOM-FILE)

or

(setq custom-file CUSTOM-FILE)

in your .emacs.  I do not immmediately see why the latter would be
easier or better.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> So either you have to put:
>
> (load CUSTOM-FILE)
>
> or
>
> (setq custom-file CUSTOM-FILE)
>
> in your .emacs.  I do not immmediately see why the latter would be
> easier or better.

The setq version could have an advantage if you could arrange so that
custom-file was just stored in this expression, not in the custom-file. Then
the value of custom-file would just be in one place. That would perhaps be
possible by changing the :set and :get functions in defcustom for
custom-file.

I would prefer this.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Lennart Borgman wrote:

   The setq version could have an advantage if you could arrange so that
   custom-file was just stored in this expression, not in the custom-file. Then
   the value of custom-file would just be in one place. That would perhaps be
   possible by changing the :set and :get functions in defcustom for
   custom-file.

   I would prefer this.

Except that `custom-set-variables' does various stuff that `setq' does
not.  As a result, certain of the more subtle advantages of saving a
variable through Custom would be lost.

Of course, the first thing to decide is whether we want to change the
code or the documentation.  Your code seems complex and there are
potential pitfalls.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> Except that `custom-set-variables' does various stuff that `setq' does
> not.  As a result, certain of the more subtle advantages of saving a
> variable through Custom would be lost.

I meant that perhaps this things would not matter with proper functions for
:set and :get for custom-file.

> Of course, the first thing to decide is whether we want to change the
> code or the documentation.  Your code seems complex and there are
> potential pitfalls.

I agree.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Lennart Borgman wrote:

   I meant that perhaps this things would not matter with proper
   functions for :set and :get for custom-file.

If you just set `custom-file' with a setq in the user's init file, the
:set and :get functions will not be called when the user's init file
is loaded.  So you will have to insert calls to named functions in the
user's init file that can be updated whenever Custom changes, without
need to update the user's init file.

It seems a _lot_ cleaner to just put in a call to "load" in the user's
init file and let `custom-set-variables' do all the work.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Stefan]

> If you just set `custom-file' with a setq in the user's init file, the
> :set and :get functions will not be called when the user's init file
> is loaded.  So you will have to insert calls to named functions in the
> user's init file that can be updated whenever Custom changes, without
> need to update the user's init file.

> It seems a _lot_ cleaner to just put in a call to "load" in the user's
> init file and let `custom-set-variables' do all the work.

You might be right.  It does seem however that the :get and :set functions
don't need to do anything special.  And that's the problem: we need to do
something special (like move the big custom-set-variables block) when we
move the custom settings from one place (like .emacs) to another, not when
we set the custom-file variable.  The first happens extremely rarely, the
second would happen at every Emacs startup.


        Stefan

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Stefan Monnier wrote:

   You might be right.  It does seem however that the :get and :set functions
   don't need to do anything special.

The problem with setting the variable with setq instead of through
`custom-set-variables' is that various standard things like:

(put 'custom-file 'saved-value '("~/mycustomfile"))

and

(custom-push-theme 'theme-value 'custom-file 'user 'set '("~/mycustomfile"))

would not get done, unless you write them in .emacs.  But the things
you have to write into .emacs may change over time, because Custom may
change over time.  So you need a function that you have to update,
when needed.  There may be other problems we would have to think very
carefully about.  Why bother when `custom-set-variables' does
everything correctly for you?

The person using Custom to set an option should be able to rely on all
the features that customizing through Custom usually implies.  It is
OK if the user sets `custom-file' using setq in his .emacs, if the
user does not care about these features.  Those features are not
necessary (it would be a bug if they were), but they can be a
convenience.  I am talking about various things, customize-saved,
customize-customized, a correct "State" message in Custom buffers, as
well other things I can not immediately think of and possibly future
features.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Stefan Monnier]

>    You might be right.  It does seem however that the :get and :set functions
>    don't need to do anything special.

> The problem with setting the variable with setq instead of through
> `custom-set-variables' is that various standard things like:

> (put 'custom-file 'saved-value '("~/mycustomfile"))

> and

> (custom-push-theme 'theme-value 'custom-file 'user 'set '("~/mycustomfile"))

Sure.  I wasn't arguing against using `load', just pointing out that it
might not be as important as it seems.  After all, AFAICT changing
custom-file via Custom itself currently just plain doesn't work and it's not
clear at all how to make it work.

This said, it's indeed probably better to tell people to `load' the custom
file rather than to `setq' the `custom-file' variable (among other things
because it involves much less magic, and works with Emacs-21.3).


        Stefan

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>
To: "Luc Teirlinck" <teirllm@dms.auburn.edu>


> >    You might be right.  It does seem however that the :get and :set
functions
> >    don't need to do anything special.
>
> > The problem with setting the variable with setq instead of through
> > `custom-set-variables' is that various standard things like:
>
> > (put 'custom-file 'saved-value '("~/mycustomfile"))
...
> Sure.  I wasn't arguing against using `load', just pointing out that it
> might not be as important as it seems.  After all, AFAICT changing
> custom-file via Custom itself currently just plain doesn't work and it's
not
> clear at all how to make it work.
>
> This said, it's indeed probably better to tell people to `load' the custom
> file rather than to `setq' the `custom-file' variable (among other things
> because it involves much less magic, and works with Emacs-21.3).

I have another opinion here. I do not believe that custom-file should be
handled like other defcustom variables:

a) I do not think it is good to store it in (custom-set-variables ...) since
that would make it much harder to rename that file because
custom-set-variables would read the old file name.

b) That said custom-file must be set somehow because otherwise saving the
settings will go to .emacs. Then I think (setq custom-file ...) is a good
and simple way.

Along these lines I have written a simple example below where I have renamed
custom-file to custox-file so you can test it without trouble. This simple
example can be expanded to query the user for automatic updating of .emacs
(like I did in the code I proposed below).

If it is scary to do automatic updating of .emacs even when the user is
prompted to accept it I instead propose something like the example below.
There are drawbacks with both methods and if automated update is not used I
believe the prompt screen below must be very clear about that the user needs
to edit .emacs. (I believe it should stand out in some way so the user do
not miss the message.)

Concerning the magic it could be explained in the prompt screen below,
together with instruction to edit .emacs.

- Lennart


(defvar custox-file nil)

(defcustom custox-file nil "docstring"
  :type 'string
  :initialize (lambda (sym val) )
  :get (lambda (sym) (if custox-file custox-file ""))
  :set (lambda (sym val)
  ;; Delete values from .emacs if custox-file is nil
  (when (boundp 'custox-file)
    (unless custox-file
      (message "(custom-save-delete) should be done in this state...")
      (sleep-for 2)))
  (setq custox-file val)
  ;; Show an explanation
  (save-window-excursion
    (save-excursion
      (with-temp-buffer
        (delete-other-windows)
        (princ
  (concat "Some explanation here...\n\n"
   "and maybe run some code to edit .emacs after this ...")
        (current-buffer))
        (switch-to-buffer (current-buffer))
        (read-from-minibuffer "Press any key to continue: " nil
         '(keymap (t . exit-minibuffer)))
        )))
  ;; Avoid storing custox-file since it would interfere with
  ;; the file actually used. If the custox-file is renamed this
  ;; would otherwise cause problems.
  (put 'custox-file 'saved-value nil)
  ))

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

On second thought, I start doubting the utility of the feature you are
proposing.  One of the main reasons to have a custom file is to have
different custom files for different versions of Emacs.  Those
versions share .emacs.  So Custom should not write anything into
.emacs of the type you are proposing, since the custom file usually is
version dependent and .emacs is version independent.

If Custom is to write anything in .emacs, it should allow the user to
specify different custom files for different ranges of Emacs versions
and write a `cond' form into .emacs of the type below.  That might be
useful, but I believe we should wait with that until after the release.

(cond ((< emacs-major-version 21)
       (load "~/.custom-20.el"))
      ((< emacs-minor-version 4)
       (load "~/.custom-21.el"))
      (t
       (load "~/.custom-21.4.el")))

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> If Custom is to write anything in .emacs, it should allow the user to
> specify different custom files for different ranges of Emacs versions
> and write a `cond' form into .emacs of the type below.  That might be
> useful, but I believe we should wait with that until after the release.
>
> (cond ((< emacs-major-version 21)
>        (load "~/.custom-20.el"))
>       ((< emacs-minor-version 4)
>        (load "~/.custom-21.el"))
>       (t
>        (load "~/.custom-21.4.el")))
>

FWIW, this is exactly how I use custom-file.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Lennart Borgman wrote:

   a) I do not think it is good to store it in (custom-set-variables ...) since
   that would make it much harder to rename that file because
   custom-set-variables would read the old file name.

Renaming your custom file behind Emacs' back is about as advisable as
renaming your .emacs file.  The only valid reason would appear to be
to temporarily disable it.  Moreover, you get the same problem with
the `setq', unless you edit your .emacs.

Note that when you rename your custom file during an Emacs session and
then change `custom-file' using Custom, then this poses no problem
whatsoever.  Custom writes into the new custom-file all options with a
non-nil `saved-value' property.  It does _not_ read from the old custom
file.  But unless you renamed your old custom file or played games
with `saved-value' properties that you should not be playing, the
result will be equivalent with reading from the old file.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Stefan Monnier wrote:

   This said, it's indeed probably better to tell people to `load' the custom
   file rather than to `setq' the `custom-file' variable (among other things
   because it involves much less magic, and works with Emacs-21.3).

I forgot about the latter.  This means that the way that
`(emacs)Saving Customizations' explains how to have different
customization files for different versions of Emacs is wrong.

I propose the following changes to man/custom.texi, which I can
install if desired.  The `cond' form in the example might look
intimidating to the non-Elisp user, but so does the present `if' form,
certainly with the (necessary) `progn' in the "else" part added.
People may want custom files for more than two versions.   People
essentially can copy the `cond' more or less verbatim with other
version numbers.  The example now shows how to deal with minor
versions.

===File ~/custom.texi-diff==================================
*** custom.texi	05 Dec 2004 09:07:23 -0600	1.70
--- custom.texi	06 Dec 2004 19:45:16 -0600	
***************
*** 1,5 ****
  @c This is part of the Emacs manual.
! @c Copyright (C) 1985,86,87,93,94,95,97,2000,2001,2002
  @c  Free Software Foundation, Inc.
  @c See file emacs.texi for copying conditions.
  @node Customization, Quitting, Amusements, Top
--- 1,5 ----
  @c This is part of the Emacs manual.
! @c Copyright (C) 1985,86,87,93,94,95,97,2000,2001,2002,2004
  @c  Free Software Foundation, Inc.
  @c See file emacs.texi for copying conditions.
  @node Customization, Quitting, Amusements, Top
***************
*** 487,509 ****
    The customization buffer normally saves customizations in
  @file{~/.emacs}.  If you wish, you can save customizations in another
  file instead.  To make this work, your @file{~/.emacs} should set
! @code{custom-file} to the name of that file.  Emacs loads the file
! right after your @file{.emacs} if you did not load it already.  For
! example:
  
  @example
  (setq custom-file "~/.emacs-custom")
  @end example
  
    The variable @code{custom-file} is useful if you want to have
  different customizations for different Emacs versions:
  
  @example
! (if (< emacs-major-version 21)
!     ;; @r{Emacs 20 customization.}
!     (setq custom-file "~/.custom-20.el")
!   ;; @r{Emacs 21 customization.}
!   (setq custom-file "~/.custom-21.el"))
  @end example
  
    If Emacs was invoked with the @option{-q} or @option{--no-init-file}
--- 487,527 ----
    The customization buffer normally saves customizations in
  @file{~/.emacs}.  If you wish, you can save customizations in another
  file instead.  To make this work, your @file{~/.emacs} should set
! @code{custom-file} to the name of that file.  If you are using Emacs
! version 21.4 or later, Emacs loads the file right after your
! @file{.emacs} if you did not load it already.  In earlier versions,
! you have to load the file in your @file{~/emacs}.  If you customize
! @code{custom-file} through the @samp{Customize} interface, you still
! need to load it in your @file{.emacs}, but there is no need to set
! it.  For example:
  
  @example
+ ;; @r{if not set through the @samp{Customize} interface:}
  (setq custom-file "~/.emacs-custom")
+ 
+ ;; @r{in Emacs versions before 21.4 or if set through}
+ ;; @r{the @samp{Customize} interface.}
+ (load "~/.emacs-custom")
  @end example
  
    The variable @code{custom-file} is useful if you want to have
  different customizations for different Emacs versions:
  
  @example
! (cond ((< emacs-major-version 21)
!        ;; @r{Emacs 20 customization.}
!        (setq custom-file "~/.custom-20.el")
!        (load "~/.custom-20.el"))
!       ((< emacs-minor-version 4)
!        ;; @r{Emacs 21 customization, before version 21.4.}
!        (setq custom-file "~/.custom-21.el")
!        (load "~/.custom-21.el"))
!       (t
!        ;; @r{Emacs version 21.4 or later.} 
!        (setq custom-file "~/.custom-21.4.el")
!        ;; @r{not strictly necessary, but load all custom files}
!        ;; @r{at the same place.}
!        (load "~/.custom-21.4.el")))
  @end example
  
    If Emacs was invoked with the @option{-q} or @option{--no-init-file}
============================================================

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    I propose the following changes to man/custom.texi, which I can
    install if desired.  The `cond' form in the example might look
    intimidating to the non-Elisp user, but so does the present `if' form,
    certainly with the (necessary) `progn' in the "else" part added.
    People may want custom files for more than two versions.

Please install your patch.  Also please replace these two lines

	The variable @code{custom-file} is useful if you want to have
      different customizations for different Emacs versions:

with this:

        You can also use @code{custom-file} to specify different
      customization files for different Emacs versions, like this:

The old text of these lines is written in a way that implies
introduction of a new topic, which is wrong because the topic is not
new at that point.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

I now believe that the following code for the example is better than
what I sent before.  Contrarily to what I said before, no `progn'
would be needed for the original `if' form.  So we could use a
corrected version of the old code of the example.  But it would not
show people how to handle more than two different Emacs versions, nor
how to handle minor versions.

===File ~/custom.texi-diff-2================================
*** custom.texi	05 Dec 2004 09:07:23 -0600	1.70
--- custom.texi	06 Dec 2004 21:30:53 -0600	
***************
*** 1,5 ****
  @c This is part of the Emacs manual.
! @c Copyright (C) 1985,86,87,93,94,95,97,2000,2001,2002
  @c  Free Software Foundation, Inc.
  @c See file emacs.texi for copying conditions.
  @node Customization, Quitting, Amusements, Top
--- 1,5 ----
  @c This is part of the Emacs manual.
! @c Copyright (C) 1985,86,87,93,94,95,97,2000,2001,2002,2004
  @c  Free Software Foundation, Inc.
  @c See file emacs.texi for copying conditions.
  @node Customization, Quitting, Amusements, Top
***************
*** 487,509 ****
    The customization buffer normally saves customizations in
  @file{~/.emacs}.  If you wish, you can save customizations in another
  file instead.  To make this work, your @file{~/.emacs} should set
! @code{custom-file} to the name of that file.  Emacs loads the file
! right after your @file{.emacs} if you did not load it already.  For
! example:
  
  @example
  (setq custom-file "~/.emacs-custom")
  @end example
  
    The variable @code{custom-file} is useful if you want to have
  different customizations for different Emacs versions:
  
  @example
! (if (< emacs-major-version 21)
!     ;; @r{Emacs 20 customization.}
!     (setq custom-file "~/.custom-20.el")
!   ;; @r{Emacs 21 customization.}
!   (setq custom-file "~/.custom-21.el"))
  @end example
  
    If Emacs was invoked with the @option{-q} or @option{--no-init-file}
--- 487,524 ----
    The customization buffer normally saves customizations in
  @file{~/.emacs}.  If you wish, you can save customizations in another
  file instead.  To make this work, your @file{~/.emacs} should set
! @code{custom-file} to the name of that file.  If you are using Emacs
! version 21.4 or later, Emacs loads the file right after your
! @file{.emacs} if you did not load it already.  In earlier versions,
! you have to load the file in your @file{~/emacs}.  If you customize
! @code{custom-file} through the @samp{Customize} interface, you still
! need to load it in your @file{.emacs}, but there is no need to set
! it.  For example:
  
  @example
+ ;; @r{if not set through the @samp{Customize} interface:}
  (setq custom-file "~/.emacs-custom")
+ 
+ ;; @r{in Emacs versions before 21.4 or if set through}
+ ;; @r{the @samp{Customize} interface.}
+ (load "~/.emacs-custom")
  @end example
  
    The variable @code{custom-file} is useful if you want to have
  different customizations for different Emacs versions:
  
  @example
! (cond ((< emacs-major-version 21)
!        ;; @r{Emacs 20 customization.}
!        (setq custom-file "~/.custom-20.el"))
!       ((< emacs-minor-version 4)
!        ;; @r{Emacs 21 customization, before version 21.4.}
!        (setq custom-file "~/.custom-21.el"))
!       (t
!        ;; @r{Emacs version 21.4 or later.} 
!        (setq custom-file "~/.custom-21.4.el")))
! 
! (load custom-file)
  @end example
  
    If Emacs was invoked with the @option{-q} or @option{--no-init-file}
============================================================

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    If you just set `custom-file' with a setq in the user's init file, the
    :set and :get functions will not be called when the user's init file
    is loaded.  So you will have to insert calls to named functions in the
    user's init file that can be updated whenever Custom changes, without
    need to update the user's init file.

I do not follow you here.  What calls do you mean?  Which functions
do you mean?  What do you mean by "whenever Custom changes"?

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:

       If you just set `custom-file' with a setq in the user's init file, the
       :set and :get functions will not be called when the user's init file
       is loaded.  So you will have to insert calls to named functions in the
       user's init file that can be updated whenever Custom changes, without
       need to update the user's init file.

   I do not follow you here.  What calls do you mean?  Which functions
   do you mean?  What do you mean by "whenever Custom changes"?

The situation would be a much bigger mess than I thought when I wrote
the quote you are responding too.  The user _did_ customize
`custom-file' through Custom.  But we actually just wrote a setq form
into .emacs.  Should we now _consider_ `custom-file' to be customized
through Custom?  Since the user customized it through Custom, he
probably would believe that things that normally work when setting
things through Custom work for custom-file too.  But then you have to
set various properties like custom-saved and others.  (That would be
done by these named functions I referred to, which could be newly
written named functions.  If Custom started adding new properties to
the symbol-plist, which has happened in the past and may happen in the
future, these functions would need to be updated.)  But the situation
is worse than that.  If you do not set these properties, you get into
various anomalies, like the "State" message in a Custom buffer saying
that `custom-file' was changed outside Custom, which could confuse the
user.  If you do set them, you get other anomalies, because then
Custom believes that `custom-file' is defined in the custom file,
whereas it is not.  It is a mess and there is no need whatsoever to
get into that mess.

But I believe all of this is really a moot point, because I do not
believe that Custom should write anything into .emacs, unless it
actually allowed the user to specify different custom files for
different Emacs versions (because that is the main reason that the
custom file feature exists in the first place) and wrote a `cond' form
into .emacs.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> The situation would be a much bigger mess than I thought when I wrote
> the quote you are responding too.  The user _did_ customize
> `custom-file' through Custom.  But we actually just wrote a setq form
> into .emacs.  Should we now _consider_ `custom-file' to be customized
> through Custom?  Since the user customized it through Custom, he
> probably would believe that things that normally work when setting
> things through Custom work for custom-file too.  But then you have to
> set various properties like custom-saved and others.  (That would be
> done by these named functions I referred to, which could be newly
> written named functions.  If Custom started adding new properties to
> the symbol-plist, which has happened in the past and may happen in the
> future, these functions would need to be updated.)  But the situation
> is worse than that.  If you do not set these properties, you get into
> various anomalies, like the "State" message in a Custom buffer saying
> that `custom-file' was changed outside Custom, which could confuse the
> user.  If you do set them, you get other anomalies, because then
> Custom believes that `custom-file' is defined in the custom file,
> whereas it is not.  It is a mess and there is no need whatsoever to
> get into that mess.

Hi Luc,

I cannot follow all your arguments here, but I see you have an important
point about anomalies. Maybe some of the arguments you have could be removed
if the normal functions used in defcustom were still called AND some other
needed actions where taken for custom-file? (Am I clear enough here?)


Due to your argument about anomalies I have tried to rethink my view. The
code I have written and sent to the list before could perhaps be used, but
some more things must be done. I will try to summarize how I see this to get
it a bit further:

a) custom-file is a special variable and can not be treated only as a normal
"defcustom variable".

b) It is currently treated as a normal "defcustom variable". This should be
changed.


There are various ways to cure this:

1) Just do not make custom-file a "defcustom variable". This is the easiest
and does not fool the user. But it is perhaps not very nice.

2) Keep custom-file a "defcustom variable" and cure the problems.

Way 2 is more job, but maybe not very much. It depends a bit on how far we
want to go on this way. Writing automatically into .emacs is a bit more job
(I have done part of that but it must be tested since it is critical).
However an alternative is telling the user this must be done and how it
should/could look.


What I believe have to be done if way 2 is choosen is

A) Write a new version of custom-buffer-create for just custom-file, say
custom-buffer-custom-file-create. This does not seem to hard to do. (A bit
more minor issue here is whether custom-file should be saved to
custom-set-variables and as I said I do not think it should.)

B) Catch custom-file at various places so it will be customized just through
the new function custom-buffer-file-create. Maybe it should be a new type of
its own instead of custom-variable, but I do not understand the details
there now. This point seems more difficult to me.

Regards,
Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

It does not appear to me that your reply addresses the following
argument I made previously:

   On second thought, I start doubting the utility of the feature you are
   proposing.  One of the main reasons to have a custom file is to have
   different custom files for different versions of Emacs.  Those
   versions share .emacs.  So Custom should not write anything into
   .emacs of the type you are proposing, since the custom file usually is
   version dependent and .emacs is version independent.

   If Custom is to write anything in .emacs, it should allow the user to
   specify different custom files for different ranges of Emacs versions
   and write a `cond' form into .emacs of the type below.  That might be
   useful, but I believe we should wait with that until after the release.

   (cond ((< emacs-major-version 21)
	  (load "~/.custom-20.el"))
	 ((< emacs-minor-version 4)
	  (load "~/.custom-21.el"))
	 (t
	  (load "~/.custom-21.4.el")))

Note that when the user would choose the special option to set
`custom-file' according to the Emacs version (maybe using an alist),
then he would imply with that choice that he wanted Custom to edit his
.emacs, so we would not have to ask any questions, which simplifies
things.  If the user wanted only one Custom file , he could still use
the feature by using an alist with only one element (".custom" . t),
or whatever.

Concretely, I was thinking of adding a third element to the current choice:

:type '(choice (const :tag "Your Emacs init file" nil) file)

That third element might be of type alist and mean the above.

The details need to be thought out carefully.  It might be better to
wait till after the release, unless it would turn out to be easy,
which maybe it could be.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>


> It does not appear to me that your reply addresses the following
> argument I made previously:

Hi Luc,

Sorry, I might have missed this. I do think in the same lines as you below.
I answered to Juris proposal in another message. There I said that things
like this could come after release. I see no problem with that if we use
Juri's approach.

- Lennart

>    On second thought, I start doubting the utility of the feature you are
>    proposing.  One of the main reasons to have a custom file is to have
>    different custom files for different versions of Emacs.  Those
>    versions share .emacs.  So Custom should not write anything into
>    .emacs of the type you are proposing, since the custom file usually is
>    version dependent and .emacs is version independent.
>
>    If Custom is to write anything in .emacs, it should allow the user to
>    specify different custom files for different ranges of Emacs versions
>    and write a `cond' form into .emacs of the type below.  That might be
>    useful, but I believe we should wait with that until after the release.
...
> `custom-file' according to the Emacs version (maybe using an alist),

Re: Documentation for custom-file - is not (load custom-file) needed?

[Juri Linkov]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:
> a) custom-file is a special variable and can not be treated only as
> a normal "defcustom variable".
>
> b) It is currently treated as a normal "defcustom variable".
> This should be changed.

Trying to sync custom-file with the location of its own list where
it is defined is like trying to lift yourself off the ground by pulling
on your hair.  The maximum you can achieve is to remove your hair ;-)

> There are various ways to cure this:
>
> 1) Just do not make custom-file a "defcustom variable". This is the
> easiest and does not fool the user. But it is perhaps not very nice.

It's too late to make any changes in custom-file (changing its type,
etc.) since users might already rely on its current state.

> 2) Keep custom-file a "defcustom variable" and cure the problems.

The only problem with custom-file is its existence.  It is completely
redundant.  The location of the list of customized variables is just
the file name from which it is loaded.  There is no need to duplicate
this information in a special variable.

What users need is just to put in .emacs something like

(load "custom-21.4.el")

and nothing more.  The location of the custom file is defined.

Moving the customization list between different files can be done with
normal Emacs editing commands.  There is no need to do this automatically.

To get this done `custom-set-variables' should save the name of the
file from which it was loaded, and use it later in the `custom-file'
function to return the file name.

In this function `custom-file-loaded' should be placed after the
`custom-file' to make it backward compatible since users might have
already `custom-file' variable defined in .emacs.

Index: lisp/custom.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/custom.el,v
retrieving revision 1.76
diff -u -r1.76 custom.el
--- lisp/custom.el	29 Jul 2004 01:47:01 -0000	1.76
+++ lisp/custom.el	8 Dec 2004 04:03:19 -0000
@@ -722,6 +722,7 @@
 
 REQUEST is a list of features we must 'require for SYMBOL.
 COMMENT is a comment string about SYMBOL."
+  (if load-in-progress (setq custom-file-loaded load-file-name))
   (apply 'custom-theme-set-variables 'user args))
 
 (defun custom-theme-set-variables (theme &rest args)

Index: lisp/cus-edit.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.201
diff -u -r1.201 cus-edit.el
--- lisp/cus-edit.el	6 Dec 2004 14:01:19 -0000	1.201
+++ lisp/cus-edit.el	8 Dec 2004 03:57:07 -0000
@@ -3673,7 +3673,12 @@
       (widget-put widget :custom-state found)))
   (custom-magic-reset widget))
 
 ;;; The `custom-save-all' Function.
+
+(defvar custom-file-loaded nil
+  "Full name of last file from which `custom-set-variables' was loaded.")
+
 ;;;###autoload
 (defcustom custom-file nil
   "File used for storing customization information.
@@ -3697,6 +3702,7 @@
   "Return the file name for saving customizations."
   (setq custom-file
 	(or custom-file
+	    custom-file-loaded
 	    (let ((user-init-file user-init-file)
 		  (default-init-file
 		    (if (eq system-type 'ms-dos) "~/_emacs" "~/.emacs")))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Documentation for custom-file - is not (load custom-file) needed?

[Juri Linkov]

I wrote:
> It's too late to make any changes in custom-file (changing its type,
> etc.) since users might already rely on its current state.

But maybe it is safe to change the type of custom-file from defcustom
to defvar.  I am only concerned about backward compatibility.
What happens if some users already have customized `custom-file' in
`custom-set-variables' and it will be removed from this list?
Perhaps, nothing bad.  Moreover, the situation where `custom-file'
in `custom-set-variables' points to some file other than the file
where `custom-set-variables' is located, is invalid.  It will cause
duplication of `custom-set-variables' list when Emacs saves customized
variables next time.  So, not adding `custom-file' to the set of
variables in `custom-set-variables' is the right thing.  `custom-file'
should be purely an internal variable (which is achieved with the
previous patch).

However, there is one situation when users have to deal with the
`custom-file' variable.  When the user moves `custom-set-variables'
to a new location in another file, it's needed to tell Emacs about
this location, so the next invocation of `Custom-save' could write
customization to the new place.  To inform users about that, the next
3 lines could be added to the comments of `custom-set-variables':

 (custom-set-variables
   ;; custom-set-variables was added by Custom.
   ;; If you edit it by hand, you could mess it up, so be careful.
   ;; Your init file should contain only one such instance.
   ;; If there is more than one, they won't work right.
+  ;; When you move it to another init file, to tell Emacs about
+  ;; its new location for the current Emacs session, type C-x C-e
+  ;; at the end of this line: (setq custom-file buffer-file-name)
+  ;; For further Emacs sessions just put in your init file
+  ;; (load "custom-file.el").  There is no need to set `custom-file'
+  ;; explicitly in your init files since Emacs can automatically set
+  ;; it to the file name where your customizations were loaded from.
   ...

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Juri Linkov" <juri@jurta.org>

> I wrote:
> > It's too late to make any changes in custom-file (changing its type,
> > etc.) since users might already rely on its current state.
>
> But maybe it is safe to change the type of custom-file from defcustom
> to defvar.  I am only concerned about backward compatibility.
> What happens if some users already have customized `custom-file' in
> `custom-set-variables' and it will be removed from this list?
> Perhaps, nothing bad.  Moreover, the situation where `custom-file'
> in `custom-set-variables' points to some file other than the file
> where `custom-set-variables' is located, is invalid.  It will cause
> duplication of `custom-set-variables' list when Emacs saves customized
> variables next time.  So, not adding `custom-file' to the set of
> variables in `custom-set-variables' is the right thing.  `custom-file'
> should be purely an internal variable (which is achieved with the
> previous patch).

Hi Juri,

Reading your previous message where you pointed out that a variable
custom-file-loaded could be set by custom-set-variables (a nice idea that
makes things much cleaner) I got maybe a further idea that could make
backward compatibility easier. It is not totally safe, but maybe
sufficiently safe:

The idea is simply to remove custom-file and add a new defvar
custom-file-in-use that is used instead. This way we do not have to care
about if custom-set-variable finds a custom-file setting. It is simply not
used. (Or, rather I cannot find any reasonable situation where the user uses
custom-file if it is not defined by a setq before. Can you?)

Maybe this is just what you intended? I was not sure. I prefer the name
custom-file-in-use instead of custom-file-loaded.


> However, there is one situation when users have to deal with the
> `custom-file' variable.  When the user moves `custom-set-variables'
> to a new location in another file, it's needed to tell Emacs about
> this location, so the next invocation of `Custom-save' could write
> customization to the new place.  To inform users about that, the next
> 3 lines could be added to the comments of `custom-set-variables':
>
>  (custom-set-variables
>    ;; custom-set-variables was added by Custom.
>    ;; If you edit it by hand, you could mess it up, so be careful.
>    ;; Your init file should contain only one such instance.
>    ;; If there is more than one, they won't work right.
> +  ;; When you move it to another init file, to tell Emacs about
> +  ;; its new location for the current Emacs session, type C-x C-e
> +  ;; at the end of this line: (setq custom-file buffer-file-name)
> +  ;; For further Emacs sessions just put in your init file
> +  ;; (load "custom-file.el").  There is no need to set `custom-file'
> +  ;; explicitly in your init files since Emacs can automatically set
> +  ;; it to the file name where your customizations were loaded from.

I like the ideas though I would change the text used a bit.

Doing it this way we still leave possibilites for someone who later wants to
make a "customization page" (along what I started with perhaps) for
custom-file-in-use. However custom-file-in-use should never be made a
defcustom variable. I just mean a page that looks similar. Such a feature
could be tested after release of the new Emacs.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Stefan Monnier]

How 'bout something like the following:

1 - remove custom-file

2 - custom-set-variables does internally:

    (push load-file-name custom-files)

3 - when saving, if custom-files is nil, use .emacs, if it has length 1, use
    (car custom-files), otherwise query the user to know where to save
    the settings and whether to remove the settings in the other files.

Of course, there can be many variations around this idea.  For one, we don't
actually have to remove custom-file.  Instead Custom could (when saving)
compare custom-file to custom-files in order to detect unexpected situations
and query the user about what he really wants to do.


        Stefan

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>

> How 'bout something like the following:
>
> 1 - remove custom-file

Yes.

> 2 - custom-set-variables does internally:
>
>     (push load-file-name custom-files)

Could load-file-name be exchanged with (buffer-file-name) if the user is
doing an interactive eval-buffer?

> 3 - when saving, if custom-files is nil, use .emacs, if it has length 1,
use
>     (car custom-files), otherwise query the user to know where to save
>     the settings and whether to remove the settings in the other files.

I believe this is a useful idea for cleaning up if the user loads several
"custom-files". Maybe this check should be done in custom-set-variable
instead of when saving? Or in both places? The reason for doing the check
when writing could perhaps be that this might make it easier to write
functions later for helping when changing "custom-file".

BTW is every occurence of custom-set-variables in "custom-file" deleted
before writing the custom-set-variables entry?

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Stefan Monnier]

>> 2 - custom-set-variables does internally:
>> (push load-file-name custom-files)
> Could load-file-name be exchanged with (buffer-file-name) if the user is
> doing an interactive eval-buffer?

The sky is the limit.  Seriously, tho, I don't think we should.
If the user evaluates a custom-set-variables via M-C-x or somesuch, I can't
think of a reason why we should care.

We only really care about "THE" custom-set-variables, i.e. the one
managed by custom (i.e. the one that's automatically rewritten upon save).
This one should be in one of the files loaded at startup, not in some buffer
where the user does M-C-x.


        Stefan

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>


> >> 2 - custom-set-variables does internally:
> >> (push load-file-name custom-files)
> > Could load-file-name be exchanged with (buffer-file-name) if the user is
> > doing an interactive eval-buffer?
>
> The sky is the limit.  Seriously, tho, I don't think we should.
> If the user evaluates a custom-set-variables via M-C-x or somesuch, I
can't
> think of a reason why we should care.

I was thinking of the situation when a user is creating a new "custom-file".
If the user knows that custom-set-variables remember which file it was in it
may be natural to assume that this also happens during eval-defun. I see no
reason why it should not.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

      Should we now _consider_ `custom-file' to be customized
    through Custom?

Sorry, I am not sure what that even means.  We seem to be considering
already the question of what happens when people customize
custom-file.  You are asking whether we should consider some question,
but I can't tell what the question is.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Richard Stallman wrote:

	 Should we now _consider_ `custom-file' to be customized
       through Custom?

   Sorry, I am not sure what that even means.  We seem to be considering
   already the question of what happens when people customize
   custom-file.  You are asking whether we should consider some question,
   but I can't tell what the question is.

I should have said "saved" through Custom, not "customized" through
Custom.  If the user saves the value of `custom-file' through Custom
and all we do is write a setq into .emacs, should we set `saved-value'
to the new value and set all the other properties that Custom sets
when the user saves a value for an option through Custom.  That was my
question.  As I pointed out earlier, I believe that both answers to
that question are unsatisfactory.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

>From my previous message:

   I should have said "saved" through Custom, not "customized" through
   Custom.  If the user saves the value of `custom-file' through Custom
   and all we do is write a setq into .emacs, should we set `saved-value'
   to the new value and set all the other properties that Custom sets
   when the user saves a value for an option through Custom.  That was my
   question.  As I pointed out earlier, I believe that both answers to
   that question are unsatisfactory.

But I do not believe that this question is still relevant.  The
discussion seems to have taken a completely different turn.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Richard Stallman]

    I should have said "saved" through Custom, not "customized" through
    Custom.  If the user saves the value of `custom-file' through Custom
    and all we do is write a setq into .emacs, should we set `saved-value'
    to the new value and set all the other properties that Custom sets
    when the user saves a value for an option through Custom.  That was my
    question.

The amount of mail on this has been so large that I can't afford to
read it all.  (To read these messages and understand them is not quick
work.)

If the rest of you arrive at some sort of partial agreement, I'd like
one of you who can explain the most clearly to explain them to me, and
then I will think about what to do.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> If the rest of you arrive at some sort of partial agreement, I'd like
> one of you who can explain the most clearly to explain them to me, and
> then I will think about what to do.

Even though there is no full agreement, I want to make the following
points with more arguments for further discussion:

1. The type of `custom-file' should be changed from defcustom to defvar
since its customization causes self-reference problems.  But its
existence should be preserved for backward compatibility for users who
have only (setq custom-file "...") without (load "...") in .emacs and
expect that it is loaded by startup.el.  However, after the changes
there will be no more need to set `custom-file' in .emacs.  It will be
possible to define the location of the customization file by loading it
with (load "...").

2. `custom-set-variables' (a function call with saved customized
values in its argument which is stored in one of the user init files)
will record the names of the files where it was loaded from, when it
is called during loading.  It will read the value of the variable
`load-file-name' during its loading.

3. `Custom-save' will use a list of file names where `custom-set-variables'
was loaded from.  When this list has multiple elements, it will ask
the user where to save `custom-set-variables'.

4. Users can move the `custom-set-variables' customization list to
another init file.  In this case there is a need to tell Emacs about
its new location.  The user has to call either (setq custom-file
(buffer-file-name)), or (push (buffer-file-name) custom-files), or
a special function on a new file buffer.  In any case, the comments in
`custom-set-variables' should contain instructions for users what to
do when `custom-set-variables' is moved manually.  Or maybe just allow
users to do `M-C-x' on `custom-set-variables'. But this might have
bad effects of overwriting the values of variables that were changed
outside of customize interface.

5. All these changes should be made before the next release to be able
to fix a problem in startup.el.  The problem is the following:

When `custom-file' (which has an absolute file name) is not literally
equal to the name of the loaded customization file, e.g. in the
following configuration:

(setq custom-file "~/emacs/lisp/custom-21.4.el")
(load "custom-21.4.el")

then custom-21.4.el is loaded twice.  startup.el fails to see that
it is already loaded, since it expects exactly the same absolute
file name in `load-history' which is not the case.  Instead of that,
it should check the value of a new variable which is set to
`load-file-name' during loading of the file with `custom-file-loaded'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Juri Linkov" <juri@jurta.org>

> Even though there is no full agreement, I want to make the following
> points with more arguments for further discussion:

Good, thanks for a constructive summary.

> 1. The type of `custom-file' should be changed from defcustom to defvar
> since its customization causes self-reference problems.  But its
> existence should be preserved for backward compatibility for users who
> have only (setq custom-file "...") without (load "...") in .emacs and
> expect that it is loaded by startup.el.  However, after the changes
> there will be no more need to set `custom-file' in .emacs.  It will be
> possible to define the location of the customization file by loading it
> with (load "...").

`custom-file' is only loaded by startup.el in CVS Emacs so I think we can
drop the variable entirely.

> 2. `custom-set-variables' (a function call with saved customized
> values in its argument which is stored in one of the user init files)
> will record the names of the files where it was loaded from, when it
> is called during loading.  It will read the value of the variable
> `load-file-name' during its loading.

Agree, but: As I pointed out earlier I think that if an eval is beeing done
then (buffer-file-name) should be used instead. This gives the same file
name as load-file-name would have given during load. The reason is that I
think this makes it easier to change "custom file".

> 3. `Custom-save' will use a list of file names where
`custom-set-variables'
> was loaded from.  When this list has multiple elements, it will ask
> the user where to save `custom-set-variables'.

Agreed.

> 4. Users can move the `custom-set-variables' customization list to
> another init file.  In this case there is a need to tell Emacs about
> its new location.  The user has to call either (setq custom-file
> (buffer-file-name)), or (push (buffer-file-name) custom-files), or
> a special function on a new file buffer.  In any case, the comments in
> `custom-set-variables' should contain instructions for users what to
> do when `custom-set-variables' is moved manually.  Or maybe just allow
> users to do `M-C-x' on `custom-set-variables'. But this might have
> bad effects of overwriting the values of variables that were changed
> outside of customize interface.

Yes, this can be done in different ways. I would prefer to recommend the
eval, since that seems easy to understand and remember. But of course we
then have to tell that this would change the settings.

> 5. All these changes should be made before the next release to be able
> to fix a problem in startup.el.  The problem is the following:
>
> When `custom-file' (which has an absolute file name) is not literally
> equal to the name of the loaded customization file, e.g. in the
> following configuration:
>
> (setq custom-file "~/emacs/lisp/custom-21.4.el")
> (load "custom-21.4.el")
>
> then custom-21.4.el is loaded twice.  startup.el fails to see that
> it is already loaded, since it expects exactly the same absolute
> file name in `load-history' which is not the case.  Instead of that,
> it should check the value of a new variable which is set to
> `load-file-name' during loading of the file with `custom-file-loaded'.

Another good reason to do it before release is to get rid of the defcustom
for custom-file. I guess this kind of problems disappear when load-file-name
or (buffer-file-name) is used?

I am not sure whether we must drop all thoughts of "easy customization" of
the "custom file" location completely now in this new scenario. It could be
rather easy if we change some things.

What I am thinking of is where to set "custom file" (by calling
custom-set-variables as above). Should we do that in .emacs or should it be
done in a separate file to make automatic editing more easy? It could be
something like this:

** In startup.el check if custom-set-variables was called from .emacs. If
not then look for .emacs-custom-location. If found load it. (This file is th
en of course supposed to call custom-set-variables. If it does not I think
an error should be raised.)

The file .emacs-custom-location should then be more or less reserved for
automatic editing.

I can see no big trouble implementing such an approach, but I do see
benefits. That is why I am taking it up now.

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Stefan Monnier]

W.r.t removing custom-file: some users may set custom-file in their .emacs
and expect it to do something, so we may as well keep it.

>> 2. `custom-set-variables' (a function call with saved customized
>> values in its argument which is stored in one of the user init files)
>> will record the names of the files where it was loaded from, when it
>> is called during loading.  It will read the value of the variable
>> `load-file-name' during its loading.

> Agree, but: As I pointed out earlier I think that if an eval is beeing done
> then (buffer-file-name) should be used instead. This gives the same file
> name as load-file-name would have given during load. The reason is that I
> think this makes it easier to change "custom file".

I'd rather not try to be too clever.
After all, when moving the custom file, you need to tell future Emacsen
where it'll be, so you need to change your .emacs to either
(setq custom-file "newfile") or (load "newfile").  Just M-C-x won't cut it.

I suggest we do this slowly and progressively.  E.g. we can start by making
custom-file a defvar (the current defcustom is just misleading since you
can't really customize it meaningfully).  Then we can introduce the
custom-files thingy that uses load-file-name to keep track of where things
are saved.  This would at first only be used to detect strange situations
and warn the user about it.  After that, we can start thinking again what it
is exactly that we want and how to get it.


        Stefan

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>

> W.r.t removing custom-file: some users may set custom-file in their .emacs
> and expect it to do something, so we may as well keep it.

Sorry, I disagree on this. The only thing I really can think of where
custom-file is used to do something is in CVS Emacs where custom-file is
loaded by startup.el if it was not loaded before. I do not think it is any
big problem if this does not work any more since it is only in CVS. That is
not to say I do not like the feature, it is just that I believe it would be
good to get rid of the name custom-file since it could be in
(custom-set-variables ...) right now and that could cause problems as we
have seen earlier in this discussion.


> > Agree, but: As I pointed out earlier I think that if an eval is beeing
done
> > then (buffer-file-name) should be used instead. This gives the same file
> > name as load-file-name would have given during load. The reason is that
I
> > think this makes it easier to change "custom file".
>
> I'd rather not try to be too clever.
> After all, when moving the custom file, you need to tell future Emacsen
> where it'll be, so you need to change your .emacs to either
> (setq custom-file "newfile") or (load "newfile").  Just M-C-x won't cut
it.

I am not sure about this, but I can see situations where it would be good if
eval set the "custom file". It is however tricky anyway if we do not reach a
state where "custom file" could be changed by "easy customization".

> I suggest we do this slowly and progressively.  E.g. we can start by
making
> custom-file a defvar (the current defcustom is just misleading since you
> can't really customize it meaningfully).  Then we can introduce the
> custom-files thingy that uses load-file-name to keep track of where things
> are saved.  This would at first only be used to detect strange situations
> and warn the user about it.  After that, we can start thinking again what
it
> is exactly that we want and how to get it.

Agree, except that I believe we should immidieately also change the name of
custom-file to something else, perhaps custom-file-in-use (since it is going
to be set by custom-set-variables).

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Stefan Monnier]

>> W.r.t removing custom-file: some users may set custom-file in their .emacs
>> and expect it to do something, so we may as well keep it.

> Sorry, I disagree on this. The only thing I really can think of where
> custom-file is used to do something is in CVS Emacs where custom-file is
> loaded by startup.el if it was not loaded before. I do not think it is any
> big problem if this does not work any more since it is only in CVS. That is
> not to say I do not like the feature, it is just that I believe it would be
> good to get rid of the name custom-file since it could be in
> (custom-set-variables ...) right now and that could cause problems as we
> have seen earlier in this discussion.

I just don't see the benefit in removing it.  If someone set it via
defcustom he's already screwed and none of the changes we plan on making are
going to make things worse for him, AFAICT.

>> After all, when moving the custom file, you need to tell future Emacsen
>> where it'll be, so you need to change your .emacs to either
>> (setq custom-file "newfile") or (load "newfile").  Just M-C-x won't cut it.

> I am not sure about this,

What are you not sure about?  About the need to add/change the `load' or
`setq' statement?  How else do you intend to make future Emacsen aware of
the new location?

> but I can see situations where it would be good if eval set the "custom
> file".

No, I think this would be very wrong.  THE custom file should only be set
by a very explicit user action.  Not just by eval'ing some random expression
that might contain a custom-set-variables.

> Agree, except that I believe we should immidieately also change the name of
> custom-file to something else, perhaps custom-file-in-use (since it is going
> to be set by custom-set-variables).

No: custom-file should not be set by custom-set-variables.  It should only
be set/changed explicitly by a user action.  custom-set-variables should
only record which files call custom-set-variables, to later on help decide
which custom file to use.

Again my sugestion is to (for now) only introduce custom-files and only use
it to double-check the value of custom-file.
In a subsequent step we can change custom-file so that when it is nil, it
means "use the file found in custom-files" (in which case
custom-set-variables would indeed indirectly set the custom file, tho
setting custom-file explicitly would still take precedence, or at least
cause some prompting to occur).

`custom-file' is a user variable and should thus never be changed behind the
user's back.


        Stefan

Re: Documentation for custom-file - is not (load custom-file) needed?

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>

> >> After all, when moving the custom file, you need to tell future Emacsen
> >> where it'll be, so you need to change your .emacs to either
> >> (setq custom-file "newfile") or (load "newfile").  Just M-C-x won't cut
it.
>
> > I am not sure about this,
> > but I can see situations where it would be good if eval set the "custom
> > file".
>
> No, I think this would be very wrong.  THE custom file should only be set
> by a very explicit user action.  Not just by eval'ing some random
expression
> that might contain a custom-set-variables.

One benefit of setting "custom file" on eval would be that the user may
proceed and use the new "custom file" without having to restart Emacs. (As
you say more things have to be done to use it in the next session.) This
could be of use if you want to save different collections of options states
in different "custom files". But I did not mean THE custom file here, I
meant "push it on custom-files". (What I was not sure about was the value of
this benefit.)


> Again my sugestion is to (for now) only introduce custom-files and only
use
> it to double-check the value of custom-file.
> In a subsequent step we can change custom-file so that when it is nil, it
> means "use the file found in custom-files" (in which case
> custom-set-variables would indeed indirectly set the custom file, tho
> setting custom-file explicitly would still take precedence, or at least
> cause some prompting to occur).
>
> `custom-file' is a user variable and should thus never be changed behind
the
> user's back.

It is a good suggestion. Maybe we can combine this with "cleaning"
custom-file from the property that makes it beeing saved by custom?

- Lennart

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Stefan Monnier wrote (talking about custom-file):

   If someone set it via defcustom he's already screwed

Quite to the contrary.  The user sets `custom-file' through Custom to
tell Custom to write to that file.  Custom copies the old
`custom-set-variables' form into that file.  (Not quite, but it does
something equivalent that works even if the old custom file got
renamed or deleted in the meantime.)  It will also continue to write
in that file for the remainder of the session or until custom-file
gets changed again.  If the user wants to save the value of
`custom-file' for future sessions, he has to load that file in his
.emacs so that Custom can find it, as used to be clearly pointed out in
the docstring.  Note that `custom-file' can be set on a "for this
session only" basis.

I myself too am starting to find it hard to keep up with every detail
of what gets written back and forth in this thread.  But I wonder if
things are not needlessly getting too complicated and especially, too
backward incompatible.

People and packages have used the variable `custom-file' for various
more sophisticated purposes.  I hope that you are not in the process
of breaking such uses and such third party packages.  I myself do not
use them (and hence can provide no nitty-gritty details), but other
people use them.

There are only two problems.

First, the user who customizes through Custom has to realize that he
has to load the file in his .emacs, if he wants to save his
customization.  That was clearly pointed out in the docstring, but
that is changed now.  We can easily change it again so that it gets
even pointed out even more clearly than before.  At the limit, we
could (for people who have philosophical objections against reading
docstrings) provide a warning if the user saves the file for future
sessions (kind of like when the user uses a disabled command).

The second, more difficult problem is that to use custom-file for the
sort of thing it is most useful for, you have to write an Elisp form
which is trivial for Elisp programmers, but may be intimidating for
non-Elisp programmers.  The current solution is that a non-Elisp
programmer can copy the example I wrote for the Emacs manual with
different version numbers.

Basically one way to deal with the problem is to simply add a couple
of lines to the docstring of custom-file, as I proposed earlier.
I myself see no reason to do anything more complex than that.


Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

>From my previous message:

   If the user wants to save the value of `custom-file' for future
   sessions, he has to load that file in his .emacs so that Custom can
   find it, as used to be clearly pointed out in the docstring.

and:

   First, the user who customizes through Custom has to realize that he
   has to load the file in his .emacs, if he wants to save his
   customization.  That was clearly pointed out in the docstring, but
   that is changed now.  We can easily change it again so that it gets
   even pointed out even more clearly than before.

Actually, I got confused there.  It still is pointed out in the
docstring, although there are reasons why we might want to change the
exact wording.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

>From my previous message:

   At the limit, we could (for people who have philosophical
   objections against reading docstrings) provide a warning if the
   user saves the file for future sessions

I meant:

"if the user saves the value of `custom-file'".

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

As I already said, the proposed solutions for custom-file seemed to be
getting too complex.  I believe the best solution is to leave
custom-file (essentially) unchanged with some documentation changes.
Note that the main use of custom-file is to have different custom
files for different versions of Emacs.  If we implement a completely
new way of doing things, then we make things more complicated for the
user, who will have to learn both methods, as well as how to make them
coexist.

I would recommend that most users customize custom-file with a setq in
their .emacs.  Customizing through Custom has several pitfalls, _even_
if only done only for the current session, but can be handy for
certain types of uses of `custom-file' if the user is willing to read
some documentation.  We should clearly warn the user if the user
selects `File' in the Custom buffer, and there are various relatively
easy ways (built into Custom) to do so.  With proper warning and
documentation, there is no need to eliminate the possibility of
customizing through Custom.

I have various concrete ideas in mind, but it would be easier to
implement them than to explain the details without implementation.  I
would have to experiment a little bit to see how things really look in
practice in a real customization buffer.  Basically, the docstring
would be slightly expanded and changed and the appearance of the
Custom buffer would change, if `File' is selected, with a warning
appearing, saying: maybe you would rather customize this through
.emacs.  If you really want to do it through Custom, read the docs.

The only (small) non-documentation change needed would be connected
with the following pointed out by Juri:

   5. All these changes should be made before the next release to be able
   to fix a problem in startup.el.  The problem is the following:

   When `custom-file' (which has an absolute file name) is not literally
   equal to the name of the loaded customization file, e.g. in the
   following configuration:

   (setq custom-file "~/emacs/lisp/custom-21.4.el")
   (load "custom-21.4.el")

   then custom-21.4.el is loaded twice.  startup.el fails to see that
   it is already loaded, since it expects exactly the same absolute
   file name in `load-history' which is not the case.  Instead of that,
   it should check the value of a new variable which is set to
   `load-file-name' during loading of the file with `custom-file-loaded'.

One solution might be to tell the user who customizes in .emacs and
for some reason needs to load the file in .emacs instead of after
it, to do:

(setq custom-file "~/emacs/lisp/custom-21.4.el")
(load custom-file)

and _not_ do what is done in the quote above.

For the user customizing through Custom, Stefan's code could check for
a saved-value property on `custom-file'.  If there is such a property,
`custom-file' has been loaded, even if it appears not to be (for the
reason given in the above quote).  This would be the only (very minor)
code change.

I could submit a concrete implementation within the next week or so,
if people would agree that the above is worth a try.

Sincerely,

Luc.

Re: Documentation for custom-file - is not (load custom-file) needed?

[Juri Linkov]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> One solution might be to tell the user who customizes in .emacs and
> for some reason needs to load the file in .emacs instead of after
> it, to do:
>
> (setq custom-file "~/emacs/lisp/custom-21.4.el")
> (load custom-file)

There are situations where this is meaningless.  For example,
the user might have a file, only small part of which is the
`custom-set-variables' list:

    (setq custom-file "~/emacs/lisp/.emacs-21.4.el")

    (add-to-list 'load-path "~/emacs/lisp/")
    (load ".emacs-21.4.el")

For the user there are two separate issues here: setting the file name
where customize will save customized variables, and loading a file
with user settings (i.e. an init file like ~/.emacs, but in another
location).

`(load custom-file)' would not make sense here.  Moreover, when the user
will change the value of (setq custom-file ...) the file with other
settings will not be loaded anymore.

There should be a reliable way to detect if the file with
`custom-set-variables' was really loaded, and not to load it twice.
With `custom-files' set inside `custom-set-variables' to `load-file-name'
this is easy: (member custom-file custom-files) means it was loaded.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Documentation for custom-file - is not (load custom-file) needed?

[Luc Teirlinck]

Juri Linkov wrote:

   For the user there are two separate issues here: setting the file name
   where customize will save customized variables, and loading a file
   with user settings (i.e. an init file like ~/.emacs, but in another
   location).

If you want to load a file and not make it the custom file, there is
no problem.  I _was_ wondering whether there might be any situations
where one might want Custom to write, by default, to a file, which one
does not always want loaded.

I believe it should be possible to disable automatic loading of the
custom file.  So we need a variable `custom-file-loaded', which can be
defined with a defvar.

The user would do:

(setq custom-file ...)
(load ...)
(setq custom-file-loaded t)

This would only be necessary for a small minority of users.

Should Stefan's feature cause too much problems, then it could still
be reversed.  It is not part of any released version and if the user
is editing his .emacs, then typing an extra `(load ...)' is not that
much extra work, especially since this normally only needs to be done
with a new Emacs release.

Sincerely,

Luc.