all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>,
	"Lennart Borgman \(gmail\)" <lennart.borgman@gmail.com>
Cc: Emacs-Devel <emacs-devel@gnu.org>
Subject: RE: always put Customizations in `custom-file', never in `user-init-file'
Date: Mon, 10 Dec 2007 14:08:23 -0800	[thread overview]
Message-ID: <BNELLINCGFJLDJIKDGACOELLCFAA.drew.adams@oracle.com> (raw)
In-Reply-To: <873auadz8l.fsf@uwakimon.sk.tsukuba.ac.jp>

> Be very careful.  In particular, the natural idea of migrating by
> loading the init file and using Custom to save its internal state to a
> custom-file caused no end of pain to users when it was implemented in
> XEmacs.  If there is any error in the init file, you can lose all
> customizations.

Why? And in what circumstance?

Do you mean an error that pre-exists in the init file or one that is
introduced during migration?

If the former, then why would anything be different after the migration?

If there is not already an error in the init file, then I guess you mean
that an error is introduced by substituting (load-file custom-file) for the
custom-set-* sexps in the init file. What kinds of errors were there? There
could be a disk write error, for instance, but I'm curious what kinds of
errors you are speaking of.

A copy should be made of the original init file, of course, so that in case
of error on next startup, the user can recuperate.

Another possibility would be to copy the Customization code from
`user-init-file' to `custom-file' and then comment-out that code in
`user-init-file' (instead of removing it altogether).

>  > Great. And I guess custom-file should be run after .emacs, since that
>  > makes it possible to chose another custom-file.

I am against that - see my separate response to Lennart.

> Experience in XEmacs showed that users often want to use information
> in the custom-file in their init files.  There were issues (maybe
> XEmacs-specific) with initial values for faces, too.  After the init
> file was run was too late.  It's easy enough to load the custom-file
> late for those users for whom that matters: don't use the default
> name.  Something like
>
> (defvar custom-file "custom.el")
> (defvar default-custom-file-loaded-p nil)
> (progn
>   (do-emacs-early-initializations)
>   (when (file-readable-p custom-file)
>     (load custom-file))
>   (load user-init-file)
>   (when (and (not default-custom-file-loaded-p)
>              (file-readable-p custom-file))
>     (load custom-file)))

Where is such code? I assume it's not in `user-init-file', since this code
loads `user-init-file'.

In any case, IIUYC, users should be able to do whatever they like in the new
situation also, because it would only load `custom-file' upon explicit
request, never automatically.

Users need to be able to control when Customizations get loaded. I, for
example, load `custom-file' last, at the end of my .emacs. Others load it
first. Still others load it somewhere in the middle. There should be no
automatic loading of `custom-file'.

  parent reply	other threads:[~2007-12-10 22:08 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-10 19:02 always put Customizations in `custom-file', never in `user-init-file' Drew Adams
2007-12-10 19:21 ` Eric Hanchrow
2007-12-10 20:30 ` Lennart Borgman (gmail)
2007-12-10 21:19   ` Stephen J. Turnbull
2007-12-10 21:25     ` Lennart Borgman (gmail)
2007-12-10 22:12       ` Drew Adams
2007-12-10 22:35         ` Lennart Borgman (gmail)
2007-12-10 23:09           ` Drew Adams
2007-12-10 23:19             ` Lennart Borgman (gmail)
2007-12-10 23:44               ` Drew Adams
2007-12-11  0:05                 ` Jason Rumney
2007-12-11  0:16                 ` Lennart Borgman (gmail)
2007-12-10 22:56       ` Stephen J. Turnbull
2007-12-10 23:06         ` David Kastrup
2007-12-11  0:07           ` Stephen J. Turnbull
2007-12-10 23:08         ` Drew Adams
2007-12-11  0:31           ` Stephen J. Turnbull
2007-12-10 22:08     ` Drew Adams [this message]
2007-12-10 23:45       ` Stephen J. Turnbull
2007-12-11  0:14         ` Lennart Borgman (gmail)
2007-12-11  1:04           ` Stephen J. Turnbull
2007-12-11  6:05           ` Drew Adams
2007-12-11  0:47         ` Drew Adams
2007-12-11  2:20           ` Stephen J. Turnbull
2007-12-11  6:15             ` Drew Adams
2007-12-11  9:53               ` Stephen J. Turnbull
2007-12-11 16:57                 ` Drew Adams
2007-12-12 10:00                   ` Stephen J. Turnbull
2007-12-12 16:31                     ` Drew Adams
2007-12-11 19:01           ` Richard Stallman
2007-12-11 19:12             ` Drew Adams
2007-12-10 21:58   ` Drew Adams
2007-12-11  4:00     ` Stefan Monnier
2007-12-11  6:04       ` Drew Adams
2007-12-11 14:52         ` Stefan Monnier
2007-12-11 16:58           ` Drew Adams
2007-12-11 22:12             ` David Kastrup
2007-12-10 22:07 ` Jason Rumney
2007-12-10 23:08   ` Drew Adams
2007-12-11  3:02 ` Robert J. Chassell
2007-12-11  6:06   ` Drew Adams
2007-12-11 11:39     ` Robert J. Chassell
2007-12-11 16:58       ` Drew Adams
2007-12-11 19:00 ` Richard Stallman

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

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

  git send-email \
    --in-reply-to=BNELLINCGFJLDJIKDGACOELLCFAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    --cc=stephen@xemacs.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.