From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: autoload cookies for defcustoms Date: Mon, 25 Jan 2010 10:31:51 -0500 Message-ID: References: <2DC911234A9B4A6ABD34459FB8C26C1C@us.oracle.com> <380EF0C7255E4FBC86DB13B434D13582@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264433530 23602 80.91.229.12 (25 Jan 2010 15:32:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2010 15:32:10 +0000 (UTC) Cc: 'Emacs-Devel devel' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 25 16:32:02 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NZQv4-0000yV-HP for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2010 16:32:02 +0100 Original-Received: from localhost ([127.0.0.1]:47061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZQv5-0003c7-N5 for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2010 10:32:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZQv0-0003bj-6M for emacs-devel@gnu.org; Mon, 25 Jan 2010 10:31:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZQuv-0003Xk-I1 for emacs-devel@gnu.org; Mon, 25 Jan 2010 10:31:57 -0500 Original-Received: from [199.232.76.173] (port=40368 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZQuv-0003XW-5l for emacs-devel@gnu.org; Mon, 25 Jan 2010 10:31:53 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:33081 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZQuu-0004KG-Sp for emacs-devel@gnu.org; Mon, 25 Jan 2010 10:31:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFALdIXUvO+LMp/2dsb2JhbACBRdkJhDsEik4 X-IronPort-AV: E=Sophos;i="4.49,339,1262581200"; d="scan'208";a="54503777" Original-Received: from 206-248-179-41.dsl.teksavvy.com (HELO pastel.home) ([206.248.179.41]) by ironport2-out.pppoe.ca with ESMTP; 25 Jan 2010 10:31:52 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id D10B381D6; Mon, 25 Jan 2010 10:31:51 -0500 (EST) In-Reply-To: <380EF0C7255E4FBC86DB13B434D13582@us.oracle.com> (Drew Adams's message of "Sun, 24 Jan 2010 21:13:12 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:120375 Archived-At: >> > Just curious. Is there a policy, for the Lisp code distributed with >> > Emacs, about using autoload cookies for defcustoms? If so, >> > what is it? >> AFAIK the policy is: "don't do it". >> It all too often introduces all kinds of nasty problems. >> More to the point, I welcome patches that remove tham. > OK. > And what about those that use `purecopy'? AFAIK, `purecopy' has nothing to do with it, except that *if* a defcustom is preloaded (either because it's in a preloaded file or because it has an autoload cookie), then it may be desirable to purecopy parts of its default value. But it should never be a reason to decide whether to autoload or not. > That's very implementation-centric, as opposed to privileging options > that are somehow considered "important" for users to know about. Autoloading of some defcustoms should not be used just because some option is "important". It should only be used when it's *necessary* for technical reasons. > Of course, if users can at least see all option names (all from the > distributed libraries) as completion candidates, that will go a long > way toward making them known to users before loading. That will be > a welcome improvement. Yes, that's an improvement that's planned to address the problem that is sometimes solved by abusing autoloading. Stefan