unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Edward Welbourne <eddy@opera.no>
Cc: jeff.dwork@amd.com, emacs-devel@gnu.org
Subject: Re: customize
Date: Mon, 29 Jul 2002 13:17:14 +0200	[thread overview]
Message-ID: <E17Z8WY-0008Tw-00@whorl.intern.opera.no> (raw)
In-Reply-To: <200207271853.g6RIrdt10834@aztec.santafe.edu> (message from Richard Stallman on Sat, 27 Jul 2002 12:53:39 -0600 (MDT))

> 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	other threads:[~2002-07-29 11:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E17SKgH-00005W-00@whorl.intern.opera.no>
     [not found] ` <200207111201.g6BC1OM16938@aztec.santafe.edu>
     [not found]   ` <E17SgpB-0003rO-00@whorl.intern.opera.no>
2002-07-14 15:22     ` customize Richard Stallman
2002-07-15  9:18       ` customize Edward Welbourne
2002-07-15 14:08         ` customize Stefan Monnier
2002-07-15 15:36           ` customize Edward Welbourne
2002-07-16 13:28         ` customize Richard Stallman
     [not found]     ` <15680.26449.937153.817907@localhost.localdomain>
2002-07-27 18:53       ` customize Richard Stallman
2002-07-29 11:17         ` Edward Welbourne [this message]
2002-07-29 12:49           ` customize Kai Großjohann
2002-07-29 13:50             ` customize Edward Welbourne
2002-07-29 15:22               ` customize chad
2002-08-05 17:47                 ` customize Per Abrahamsen
2002-08-06 16:53                   ` customize chad
2002-08-09  6:52                   ` customize Stefan Monnier
2002-08-09  8:32                     ` customize Edward Welbourne
2002-08-10 12:30                       ` customize Stefan Monnier
2002-08-12  8:00                         ` customize, futility of byte-compiling Edward Welbourne
2002-08-12 10:01                           ` Per Abrahamsen
2002-08-12 16:14                           ` Stefan Monnier
2002-08-10 17:16                     ` customize Richard Stallman
2002-08-13 16:28                       ` customize Stefan Monnier
2002-08-14  5:15                         ` customize Richard Stallman
2002-08-14 21:51                           ` customize Stefan Monnier
2002-07-29 16:15               ` customize Per Abrahamsen
2002-07-29 18:15                 ` customize Edward Welbourne
2002-07-29 19:42                   ` customize Kai Großjohann
2002-07-30  8:32                     ` customize Edward Welbourne
2002-07-30 11:32                       ` customize Robert J. Chassell
2002-07-30  5:16                   ` customize Eli Zaretskii
2002-07-30  5:14               ` customize Eli Zaretskii
2002-07-30  1:00           ` customize Richard Stallman
2002-08-03  0:46             ` customize Jeff Dwork
2002-08-09  7:33           ` customize Stefan Monnier

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=E17Z8WY-0008Tw-00@whorl.intern.opera.no \
    --to=eddy@opera.no \
    --cc=emacs-devel@gnu.org \
    --cc=jeff.dwork@amd.com \
    /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).