[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lennart Borgman
Subject: Re: Documentation for custom-file - is not (load custom-file) needed?
Date: Fri, 10 Dec 2004 16:51:06 +0100

----- Original Message ----- 
From: "Juri Linkov" <address@hidden>

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]