emacs-devel
[Top][All Lists]
Advanced

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

Re: customize


From: Edward Welbourne
Subject: Re: customize
Date: Mon, 29 Jul 2002 13:17:14 +0200

> I documented custom-face, but I don't see a reason to change the
> default to use a different file.

Jeff was discussing customisation of custom-file, not custom-face.
But I'm guessing that's what you meant.

Three reasons for setting custom-face to somewhere other than ~/.emacs
(only arguably reasons against using ~/.emacs as default for
custom-face):

  * Database reason: one file then contains only customize's actions,
    making it much easier to keep track of which pieces of one's
    config come from where.

  * Priority/ordering reason: customize adds things to the end of its
    file: this is sensible for it, but potentially bad for elisp which
    needs to be executed after customizations; using a separate file
    for customize lets my ~/.emacs load the customize part early, late
    or in between, at my option, rather than having it always be last.

  * Byte-compilation: putting it all in a separate .el file provides
    for the possibility of byte-compiling the customization elisp.

Having customize write to ~/.emacs leads to its works being mixed up
with the user's hand-coded elisp; it also ensures that customize's
actions over-ride everything the user sets up in elisp.

Two reasons for using ~/.emacs as the default:

  * Simplicity: ~/.emacs is being loaded anyway; if customize writes
    to any other file, ~/.emacs must load that file; users will be
    confused/upset if their customization efforts have no effect
    (because the file the customization was recorded in hasn't been
    loaded).

  * Convenience/consistency: using a byte-compiled file requires
    recompilation each time any customizations get added.

Personally, I'm with Jeff on this ... but I suspect this is the
natural bias of old hands; while newbies need convenience with
simplicity, and can't be expected to work out what to do about
problems.

Having the customization system provide a clear and prominent mention
of custom-file's role, on its front page, would probably be the wisest
approach; newbies could safely ignore it and have their customizations
work, while old hands would have the one clue we need to fix it up the
way we prefer.

                Eddy.



reply via email to

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