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.