From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Demoting `custom-file' to a defvar Date: Sun, 8 Nov 2015 10:15:03 -0800 (PST) Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447006538 17433 80.91.229.3 (8 Nov 2015 18:15:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 18:15:38 +0000 (UTC) Cc: Emacs developers To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 19:15:24 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZvUUs-00022D-MV for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 19:15:22 +0100 Original-Received: from localhost ([::1]:48404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvUUs-0006s4-4a for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 13:15:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvUUe-0006qR-Ui for emacs-devel@gnu.org; Sun, 08 Nov 2015 13:15:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvUUb-0006ri-Ng for emacs-devel@gnu.org; Sun, 08 Nov 2015 13:15:08 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:51851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvUUb-0006r9-IN for emacs-devel@gnu.org; Sun, 08 Nov 2015 13:15:05 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA8IF3Qx013030 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Nov 2015 18:15:04 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA8IF3aE020657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2015 18:15:03 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA8IF2nd005236; Sun, 8 Nov 2015 18:15:03 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193632 Archived-At: > > Please read the doc string of option `custom-file' carefully. > > IMO, users should be able to take advantage of Customize when > > defining the value. >=20 > 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 > > =E2=80=98(load "CUSTOM-FILE") in your init file, where CUSTOM-FILE > > is the actual name of the file. >=20 > 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. >=20 > Agreed.