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: doc of defining minor modes Date: Fri, 19 May 2006 10:43:16 -0700 Message-ID: References: <87zmhej7c8.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1148060629 17051 80.91.229.2 (19 May 2006 17:43:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 May 2006 17:43:49 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 19 19:43:46 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fh90m-0003ly-4B for ged-emacs-devel@m.gmane.org; Fri, 19 May 2006 19:43:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fh90l-0006Ah-JG for ged-emacs-devel@m.gmane.org; Fri, 19 May 2006 13:43:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fh90b-00069q-1a for emacs-devel@gnu.org; Fri, 19 May 2006 13:43:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fh90Z-00068L-As for emacs-devel@gnu.org; Fri, 19 May 2006 13:43:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fh90Z-00068E-5c for emacs-devel@gnu.org; Fri, 19 May 2006 13:43:27 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1Fh93u-0005t0-3G for emacs-devel@gnu.org; Fri, 19 May 2006 13:46:55 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4JHhNoi016839 for ; Fri, 19 May 2006 12:43:24 -0500 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-66-197.vpn.oracle.com [141.144.66.197]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k4JHhMmp025348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 19 May 2006 11:43:23 -0600 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87zmhej7c8.fsf-monnier+emacs@gnu.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:54823 Archived-At: > It's not obvious to readers of the doc why we provide an :init-value > possibility and yet we warn people not to use it (except in a > rare case). There needs to be a good explanation of this uncommon > coupling. The explanation needs to indicate how the problem that the > admonition hopes to prevent could arise, that is, _how_ a library > might get loaded without being loaded directly by the user. > That is not obvious. I don't think it's worth the trouble to write a long explanation. It's perfectly OK to have arguments and features marked as "don't ever use this unless you really know what you're doing". It's more like "don't use this if you _know_ what you're doing and your library is exceptional" (large, complex, coupled with other libraries, preloaded,...). The typical, simple case of a standalone external library will not be preloaded or required by another library, it will not have autoload cookies, and it would never be loaded behind the user's back. I think it's worth pointing out what the potential but uncommon problem is. The problem is that we can't integrate such a package into Emacs without first fixing this behavior. So of course we don't encourage that. Changing :init-value t to :init-value nil would be the least of your integration worries. I really don't see that concern as justification for such a blanket admonition. It makes sense, in any case and _especially_ if the admonition is kept as general as it is, to explain the problem, so programmers know what they're doing and why.