unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
Cc: teirllm@dms.auburn.edu, emacs-devel@gnu.org
Subject: Re: Documentation for custom-file - is not (load custom-file) needed?
Date: Fri, 10 Dec 2004 16:51:06 +0100	[thread overview]
Message-ID: <00d101c4ded0$37cad4e0$0200a8c0@sedrcw11488> (raw)
In-Reply-To: 874qiusno3.fsf@jurta.org

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

  reply	other threads:[~2004-12-10 15:51 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-04  1:53 Documentation for custom-file - is not (load custom-file) needed? Lennart Borgman
2004-12-04 23:35 ` Lennart Borgman
2004-12-05 21:52   ` Richard Stallman
2004-12-06  0:24     ` Luc Teirlinck
2004-12-06 14:10       ` Richard Stallman
2004-12-07  2:40         ` Luc Teirlinck
2004-12-08  4:40           ` Richard Stallman
2004-12-06  2:56     ` Luc Teirlinck
2004-12-07  4:23       ` Richard Stallman
2004-12-05 15:50 ` John Paul Wallington
2004-12-05 17:07   ` Lennart Borgman
2004-12-05 17:33     ` Luc Teirlinck
2004-12-05 22:07       ` Lennart Borgman
2004-12-06  0:46         ` Luc Teirlinck
2004-12-06  1:21           ` Lennart Borgman
2004-12-06  4:02             ` Luc Teirlinck
2004-12-06 13:04               ` Stefan
2004-12-06 18:34                 ` Luc Teirlinck
2004-12-06 18:54                   ` Stefan Monnier
2004-12-06 21:53                     ` Lennart Borgman
2004-12-07  2:34                       ` Luc Teirlinck
2004-12-07  9:39                         ` Kim F. Storm
2004-12-07  3:27                       ` Luc Teirlinck
2004-12-07  2:56                     ` Luc Teirlinck
2004-12-08  4:40                       ` Richard Stallman
2004-12-07  3:50                     ` Luc Teirlinck
2004-12-07  4:23               ` Richard Stallman
2004-12-07  5:39                 ` Luc Teirlinck
2004-12-08  0:44                   ` Lennart Borgman
2004-12-08  4:35                     ` Luc Teirlinck
2004-12-08 17:52                       ` Lennart Borgman
2004-12-08  4:42                     ` Juri Linkov
2004-12-08 13:27                       ` Juri Linkov
2004-12-08 17:52                         ` Lennart Borgman
2004-12-08 18:04                           ` Stefan Monnier
2004-12-08 19:56                             ` Lennart Borgman
2004-12-08 20:20                               ` Stefan Monnier
2004-12-08 22:16                                 ` Lennart Borgman
2004-12-08  4:40                   ` Richard Stallman
2004-12-09  2:20                     ` Luc Teirlinck
2004-12-09  2:24                       ` Luc Teirlinck
2004-12-09 22:06                       ` Richard Stallman
2004-12-10  5:54                         ` Juri Linkov
2004-12-10 15:51                           ` Lennart Borgman [this message]
2004-12-10 17:05                             ` Stefan Monnier
2004-12-10 18:36                               ` Lennart Borgman
2004-12-10 20:40                                 ` Stefan Monnier
2004-12-11  1:00                                   ` Lennart Borgman
2004-12-11  3:38                                   ` Luc Teirlinck
2004-12-11  3:56                                   ` Luc Teirlinck
2004-12-11  4:11                                   ` Luc Teirlinck
2004-12-13  3:49                                   ` Luc Teirlinck
2004-12-13  9:01                                     ` Juri Linkov
2004-12-13 15:55                                       ` Luc Teirlinck
  -- strict thread matches above, loose matches on Subject: below --
2004-12-13 19:51 Richard Stallman
2004-12-14  0:34 ` Lennart Borgman
2004-12-14 23:20   ` Richard Stallman
2004-12-14  1:50 ` Luc Teirlinck
2004-12-14 23:20   ` Richard Stallman
2004-12-15  2:51     ` Luc Teirlinck
2004-12-15 23:20       ` Richard Stallman
2004-12-16  0:48         ` Luc Teirlinck
2004-12-16  4:51           ` Luc Teirlinck
2004-12-17  0:54           ` Richard Stallman
2004-12-17  5:41             ` Luc Teirlinck
2004-12-17 13:20               ` Kim F. Storm
2004-12-20 10:56               ` Richard Stallman
2004-12-21  0:48                 ` Luc Teirlinck
2004-12-23  0:53                 ` Luc Teirlinck
2004-12-25 15:13                   ` Richard Stallman
2004-12-26  2:31                     ` Luc Teirlinck
2004-12-14  4:14 ` Luc Teirlinck
2004-12-17 15:31 LENNART BORGMAN
2004-12-23 14:07 LENNART BORGMAN
2004-12-23 18:05 ` Luc Teirlinck
2004-12-28  1:06   ` Lennart Borgman
2004-12-28  4:28     ` Luc Teirlinck
2004-12-28 17:25       ` Richard Stallman
2004-12-23 18:34 ` Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00d101c4ded0$37cad4e0$0200a8c0@sedrcw11488' \
    --to=lennart.borgman.073@student.lu.se \
    --cc=emacs-devel@gnu.org \
    --cc=teirllm@dms.auburn.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).