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: Thu, 18 May 2006 10:55:23 -0700 Message-ID: References: <85iro3gt32.fsf@lola.goethe.zz> 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 1147975112 5020 80.91.229.2 (18 May 2006 17:58:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 May 2006 17:58:32 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 18 19:58:29 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 1FgmlB-00031p-1J for ged-emacs-devel@m.gmane.org; Thu, 18 May 2006 19:58:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FgmlA-0004Eu-Is for ged-emacs-devel@m.gmane.org; Thu, 18 May 2006 13:58:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fgmik-0002Oa-Fn for emacs-devel@gnu.org; Thu, 18 May 2006 13:55:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fgmii-0002MS-DI for emacs-devel@gnu.org; Thu, 18 May 2006 13:55:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fgmii-0002MB-7R for emacs-devel@gnu.org; Thu, 18 May 2006 13:55:32 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1Fgmlq-00048H-GZ for emacs-devel@gnu.org; Thu, 18 May 2006 13:58:46 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k4IHtTXX008416 for ; Thu, 18 May 2006 11:55:29 -0600 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k4IHtTiI030130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 18 May 2006 11:55:29 -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: <85iro3gt32.fsf@lola.goethe.zz> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 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:54714 Archived-At: Customize might load a file just because a variable has been customized from it. And? > Third, I don't see why we are stating this guideline / > recommendation / prescription. Users can always set the mode value > to nil in their init files, which, for a mode that always toggles > based on changes to this variable (which is the normal, recommended > case) will inhibit mode enabling upon load. Uh what? Why should that happen? Why shouldn't it? It works for me. (setq my-mode nil) ; Inhibit turning on when loaded. By "enabling upon load" I don't mean turning the mode on systematically when the file is loaded; I mean setting the variable value to non-nil unless it is already defined. That's the way it works for me, at least: if the variable is already defined, then loading the library does not set it. IOW, I'm speaking only of the :init-value for define-minor-mode - the _default_ value if the user specifies none. I interpreted the doc passage quoted as essentially saying that libraries should not use ":init-value t". If I misinterpreted the passage, then what was the real message? > That was the spin used previously in this doc, I believe, and I > think it is the correct recommendation. We should say something like > this (the idea, if not the wording): > > Unless the mode automatically toggles upon changes to the mode > variable, do not enable the mode upon load. Why? Because users > have no way to inhibit enabling in that case. How do you suppose to inhibit enabling when the mode "automatically toggles upon changes" in this case? By "automatically..." I mean the usual and recommended case of a minor mode turning on and off when its variable's value changes. Inhibit default enabling with this in your .emacs: (setq my-mode nil) Am I missing something here? > That is the only case where it is important not to enable the mode > upon load, AFAIK. The part about modes that don't respect their > variable is missing in the current guideline - it speaks of > "painless" and "harmless", but nowhere does it explain what the pain > or harm is. Files may even get autoloaded when going through a menu. And? That a file gets loaded via customize of through a menu or via cosmic ray is not the point/problem, AFAICT. The point is what that library does. If a particular library would cause harm by enabling a minor mode by default upon loading, then it should not do that. Otherwise, where's the beef? The problem is not that libraries can be loaded in various under-the-covers ways at any unforeseen time. The problem is for each library writer to determine if enabling the mode by default upon load is appropriate. If not, don't do that. It would be helpful to add guidelines with examples of things that libraries might do that would make it inappropriate to enable their mode by default upon load. IOW, specifics please. > I personally think that perhaps most normal (respectful) minor modes > should be enabled upon load, but I wouldn't go so far as to proclaim > that in the doc. Enabling the mode by default upon load > (i.e. enabling unless the variable is nil) is "harmless", unless I'm > missing something. If I am missing something, then maybe that > something needs to be added to the doc. Stuff connected with autoloads and customization groups triggers at unusual moments. Too vague for me. Please formulate any specific problems that should be added to the doc, in place of a blanket "Don't do that".