From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11106: 24.0.94; enhancement request: have autoload treat faces like it does options Date: Wed, 28 Mar 2012 10:08:26 -0700 Message-ID: <08A31323DD6D4526AE56E760D45A623F@us.oracle.com> References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com><54253A206B4248F99B4AD830266E374C@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1332954590 30019 80.91.229.3 (28 Mar 2012 17:09:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2012 17:09:50 +0000 (UTC) Cc: 11106@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 28 19:09:49 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1SCwNX-0003hP-IE for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Mar 2012 19:09:47 +0200 Original-Received: from localhost ([::1]:52682 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCwNW-0001cg-P9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Mar 2012 13:09:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCwNT-0001cZ-Mc for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 13:09:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCwNR-0006wY-4S for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 13:09:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCwNR-0006wS-0a for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 13:09:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SCwrm-0005rl-NB for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 13:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Mar 2012 17:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11106 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11106-submit@debbugs.gnu.org id=B11106.133295642822498 (code B ref 11106); Wed, 28 Mar 2012 17:41:02 +0000 Original-Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 17:40:28 +0000 Original-Received: from localhost ([127.0.0.1]:43589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCwrD-0005qn-Vp for submit@debbugs.gnu.org; Wed, 28 Mar 2012 13:40:28 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:30427) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCwqg-0005pQ-Tr for 11106@debbugs.gnu.org; Wed, 28 Mar 2012 13:40:10 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2SH8Upi030193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Mar 2012 17:08:31 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2SH8T6R003308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2012 17:08:29 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2SH8SeU027497; Wed, 28 Mar 2012 12:08:28 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Mar 2012 10:08:27 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac0M+o7Bp6mIJ+faQamy33cmA1TubAAAmmTw X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090208.4F73458F.0153,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:58249 Archived-At: > > For #1: Make an autoload cookie before a defface do something > > analogous to what it does before a defcustom. I'm no expert on the > > latter, so yes, this is vague. IIUC, an autoload cookie handles an > > option definition by setting the option value at autoload > > time, but it does not simply copy the defcustom to the autoloads file. > > ;;;###autoload on a defcustom pretty much copies the defcustom, tho it > addmittedly tries to strip away things that won't be needed until the > file is actually loaded. > > But I don't know what that would mean for defface. IOW what is the > concrete problem you see with ;;;###autoload on a defface that you'd > like to see fixed? No special problem for #1. It's not completely clear to me how an option is handled, but clearly the defcustom is not simply copied to the autoloads file. I took a look at autoload.el and custom.el, as well as the C code for `autoload', but the entire purpose behind the treatment of defcustom is not clear to me. If you think the cookie-handling code does nothing special for options then you can ignore request #1. It is request #2 that I am particularly interested in, as I said. > > Assume you want to provide autoloading for the faces, > > I can't assume it, since you're trying to explain to me why that would > be useful. No, I was not trying to explain why autoloading faces can be useful in general. Yes, I do assume that it can be. What I explained was a use case for having function `autoload' handle options and faces - the scenario you asked for. If you look at that use case perhaps you will understand more specifically why (real) autoloading can be helpful, and how different it would be from simply predefining faces completely at autoload file generation time. As to the assumption of usefulness in general, since that is apparently a stumbling block for you: Why, in your opinion, can (real) autoloading be useful for a command but not for an option or a face? The same utility you see for a command I see also for an option or face. IOW, why do we have function `autoload' for functions? Why not just use autoload cookies and have them simply copy a function's defun to the autoloads file (i.e., not handle functions specially)? The same reason applies to options and functions: real autoloading has a use, independent of the use of predefinition. Imagine handicapping autoload cookies by removing their special handling of defuns - have them just copy the defun to the autoloads file, and you will see how their handling of options and faces is handicapped. > > to let users get to their doc. > > That's it? So you only want it for describe-face's purpose? No, not only the doc. I want it for the same reasons that any (real) autoloading is wanted. I want function `autoload' to do for options and faces the same kind of thing it does for functions. Think in terms of function autoloading as the model. Why provide autoloading of functions (e.g. commands, keymaps)? Those same reasons apply to options and faces, IMO. It is about doc, sure, but not only doc. When you do `M-x foo TAB', you see `foobar' as a candidate, if it is autoloaded. Similarly, if you do `M-x customize-face RET foo TAB' you would see `fooface' as a candidate, if it were autoloaded. And just as in the case of a command, the face would not be predefined, just in order to be autoloadable. The point of this request is to provide real autoloading for options and faces, as opposed to simply predefinition/pre-evaluation (which is what autoload cookies do for an arbitrary sexp). The face would be undefined until you tried to access it, and then its defining file would be loaded and its defface would kick in (at load time) to provide the definition and hence the "value": either the default value or an already customized value. In this example, that definition would be provided to `customize-face' as a completion candidate. There is a big difference between defining a face at autoload file generation time and defining it when the library containing its defface is loaded. For one thing, if the user has customized the face then the library's defface will have no effect, whereas a defface in an autoloads file might be eval'ed before the user's `custom-file' is loaded. I gave a specific example (scenario) for this, as you requested. Think how users interact with autoloaded commands and keymaps. I would like the same possibility for faces and options. For the same reasons. And yes, one of those reasons - for commands too - is access to the doc. > Then autoloading is not the right answer. We're back at the issue of > finding documentation for vars, functions, and now faces in not-yet > loaded code. We don't need to autoload the whole world for that. And you're no doubt thinking of only the current handling of autoload cookies for faces and options. That handling is indeed heavy-handed, perhaps even misguided. It is a sledgehammer substitute for real, lightweight autoloading (such as is provided for functions by function `autoload'). Autoload cookies simply predefine/pre-evaluate stuff. They do not really provide an autoload feature, as does function `autoload'. Except that for functions they DTRT: call `autoload'. Simply predefining in an autoloads file is not what we do for autoloading function definitions. This request (#2) is about extending function `autoload' to handle user options and faces, just as it handles functions (including commands and keymaps). For functions, we essentially preload only the doc, and we put in place a trigger to load the file that actually defines the function. That's what my request #2 is about: have function `autoload' treat options and faces analogously to its treatment of functions. And an autoload cookie would then handle defface and defcustom, like it handles defun, by handing things off to function `autoload'. I want to be able to actually autoload an option or face, having it become defined by loading its defining file, and not just having it be predefined in some autoloads file. Just like commands, users interact with things that can be customized: options and faces. I want to make it possible to let them interact with options and faces whose definitions have not yet been loaded. And I do not want to predefine those customizable things just in order to be able to autoload them. Just as for autoloaded commands, I want all of the defining logic to take effect in the library's load environment, not at some package-install time when a file of autoloads is generated. Letting user customizations be taken into account when loading is one example of that. Library file dependencies is another example. I want to separate such logic from the autoloads file - later, load-time binding, if you will. > [ Sorry, didn't read the rest, assuming that it is not relevant since > I rejected the main assumption. ] A copout. Try reading before rejecting out of hand. Especially since you asked for a scenario and I provided one - I described a specific use case. And I can point you to the code that inspired it if my description of it is not clear. But at least read the description, please.