unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: bruce.connor.am@gmail.com
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: RE: Demoting `custom-file' to a defvar
Date: Sun, 8 Nov 2015 10:15:03 -0800 (PST)	[thread overview]
Message-ID: <d4dfec5a-0cfb-4daa-9655-23ee7405d420@default> (raw)
In-Reply-To: <CABYf3Cg94D4bbHYWufUR99f3ZzKDm0ZxRGnJPgVp+QR2-eNZYg@mail.gmail.com>

> > Please read the doc string of option `custom-file' carefully.
> > IMO, users should be able to take advantage of Customize when
> > defining the value.
> 
> Thanks for the pointer, here's the relevant doc part.

Actually, the first sentence is arguably the most important part:

   Please read entire docstring below before setting this through
   Custom.

["Custom" should be "Customize" here and elsewhere in the doc
string, IMO.]

All of the doc string is "relevant" in this discussion, not
just the "relevant part" you quoted.

Here is another important part, for example:

   You can set this option through Custom, if you carefully
   read the last paragraph below.  However, usually it is
   simpler to write something like the following in your init
   file:

IOW, this is an option so that you can take advantage of
Customize, but it is generally simpler to set it in your
init file.  (Taking advantage of Customize includes
type-checking.)

The "last paragraph" is what you quoted:

> > If you save this option using Custom, Custom will write all
> > currently saved customizations, [...] into the file you
> > specify [...].  It will not delete any customizations from
> > the old custom file.  You should do that manually if that
> > is what you want.  You also have to put something like
> > ‘(load "CUSTOM-FILE") in your init file, where CUSTOM-FILE
> > is the actual name of the file.
> 
> So it looks like saving it through customize spares the user the
> trouble of copying over the 2 sexps to the new file. They still have
> to load the new file from their init file, and delete the old sexps.

No, they typically do not need to delete any old sexps.

That was mentioned as a possibility.  Few users will ever do
that, IMO.  This is about copying customizations from one
file (wherever they are currently saved) to another (the
new value of `custom-file').  It's just saying that if the
target file has (like many init files) some non-custom
settings, then it is up to you to do what you want with
those - IOW, using `custom-file' has no bearing on them.

Essentially, this text tries to deal with users who are
used to init files, which can contain anything and
everything, and its message is this: Customize does
nothing with your `custom-file' except manage the Customize
parts of it.  Anything else you might have in there is left
as is.  This is the _same_ message about Customize without
`custom-file': it is how it deals with your init file.

Any text in this doc string about "the old custom file"
could just be removed, IMO, or relegated to the manual.
Especially if we promote the use of `custom-file', so that
user init files are not polluted with Customize stuff
from the outset.

Best practices are for: (1) Customize not to put its stuff
into a file where users have hand-written code and (2) for
users not to add hand-written code to the file where
Customize writes its stuff.

If we get across that message in those terms, then all
mention of "the old custom file" can be removed.

> Sounds like a misfeature, IMO, so I'm still in favor of demoting it
> (though not quite as eagerly as before).

What's the misfeature?  Be specific, please.

> > What's missing is up-front mention of this in the manual,
> > at the place where we explain the init file (node Init File).
> >
> > The general recommendation should be to use `custom-file',
> > and in node Init File' we should present a simple init-file
> > example that shows how to do this.  That's all.
> 
> Agreed.



      reply	other threads:[~2015-11-08 18:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-08 11:14 Demoting `custom-file' to a defvar Artur Malabarba
2015-11-08 13:06 ` Nicolas Petton
2015-11-08 16:31 ` Drew Adams
2015-11-08 17:15   ` bruce.connor.am
2015-11-08 18:15     ` Drew Adams [this message]

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=d4dfec5a-0cfb-4daa-9655-23ee7405d420@default \
    --to=drew.adams@oracle.com \
    --cc=bruce.connor.am@gmail.com \
    --cc=emacs-devel@gnu.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 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).