unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
Cc: jeff.dwork@amd.com, emacs-devel@gnu.org
Subject: Re: customize
Date: Mon, 29 Jul 2002 19:00:00 -0600 (MDT)	[thread overview]
Message-ID: <200207300100.g6U100I14581@aztec.santafe.edu> (raw)
In-Reply-To: <E17Z8WY-0008Tw-00@whorl.intern.opera.no> (message from Edward Welbourne on 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.

It was custom-file that I documented.  I wrote the wrong name in the
message.

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

It is easy enough to distinguish--the stuff written by Customize
is compact, distinctive, and clearly labeled.

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

There appears to be some controversy about whether this is really true.
Part of the controversy may be that your description of the problem
is heavy on emotions and the facts are not clear.

    > After it is there, you can add stuff in ~/.emacs after it.
    and get a layer-cake of intermingled fragments, some of one's own
    construction, others added by customize

Could you show an example of this?  As far as I know, customize writes
all its definitions for variables in a single sexp, and all its specs
for faces in a single sexp, and this can't produce very many layers.

If you show me what the problem looks like, maybe I can change Customize
to edit the file in a way that is more convenient.

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

You can byte-compile .emacs, so is this really an advantage?

  parent reply	other threads:[~2002-07-30  1:00 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         ` customize Edward Welbourne
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           ` Richard Stallman [this message]
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=200207300100.g6U100I14581@aztec.santafe.edu \
    --to=rms@gnu.org \
    --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).