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 06:39:39 -0700 Message-ID: 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 1332942055 19074 80.91.229.3 (28 Mar 2012 13:40:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2012 13:40:55 +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 15:40:53 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 1SCt7M-00085c-Lb for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Mar 2012 15:40:53 +0200 Original-Received: from localhost ([::1]:39705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCt7L-0006Jn-TZ for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Mar 2012 09:40:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCt7E-00061g-FI for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 09:40:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCt7B-0003OQ-4Z for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 09:40:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCt7B-0003OK-0d for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 09:40:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SCtbV-0007g3-LC for bug-gnu-emacs@gnu.org; Wed, 28 Mar 2012 10:12:01 -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 14:12:01 +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.133294389029472 (code B ref 11106); Wed, 28 Mar 2012 14:12:01 +0000 Original-Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 14:11:30 +0000 Original-Received: from localhost ([127.0.0.1]:43326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCtaz-0007fI-5D for submit@debbugs.gnu.org; Wed, 28 Mar 2012 10:11:30 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:26999) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCtai-0007eu-59 for 11106@debbugs.gnu.org; Wed, 28 Mar 2012 10:11:27 -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 q2SDdmHU014386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Mar 2012 13:39:49 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 q2SDdlHP011001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2012 13:39:48 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2SDdk8k020516; Wed, 28 Mar 2012 08:39:46 -0500 Original-Received: from dradamslap1 (/10.159.35.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Mar 2012 06:39:46 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac0M4EJpUKElqM+nTTWOJMveNJkiKAAANnaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090209.4F7314A6.0005,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:58238 Archived-At: > > 1. Handle faces (deffaces) similarly to how options > > (defcustoms) are handled. > > I don't know what that means. 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. > > 2. Have function `autoload' handle both faces and options > > via its TYPE arg. > > Can you provide a sample scenario where that would be useful? #2 is more important, to me, and is not directly related to #1. Maybe this scenario will help, maybe not. (I'm using default "value" of a face as shorthand for the value of the second arg, SPEC, to defface.) In the same file, have two deffaces, f1 and f2, in that order. Suppose that the sexp defining the default value of f2 depends on the value of f1 and on the availability of function foo. If foo is not available then f2's default value uses constants in the SPEC sexp. If foo is available, then foo is invoked with f1 as an arg, to come up with f2's default value. Assume you want to provide autoloading for the faces, to let users get to their doc. For that, you add an autoload cookie before each defface. But that means that the SPECs get eval'd at autoloads-file generation time, not when the library is loaded. What's more, because you want to make foo available if its defining library is in the user's load-path, you add a soft require: (require 'foolib nil t). And since foo would also need to be available at autoloads-generation time, you add an autoload cookie for that soft require as well. But one reason for having f2 use f1's (possibly customized) value in its own SPEC was to let a user customize f1 and have the default value of f2 be based on that. At any time, the user should be able to customize f1, restart Emacs and have f2's value reflect that customization. (And no, this is not something that can be done in general using face inheritance. Assume that in this case function foo does something interesting, using f1's value as input.) But if the autoloads file is generated before the user customizes f1 then the customized f1 value is not used to compute f2. The dependencies and openness to customization get defeated by the fact that f1 and f2 become fully defined at autoloads generation time (i.e., when the autoloads file is created). In addition, foo's library needs to be loaded both when the autoloads file is generated and when the file with the deffaces is loaded. Things are a lot more complicated than they should need to be: the logic of dependencies is carried over (duplicated) from library load time into autoloads generation time, and some functionality (e.g. customization relationships) is lost. The enhancement request (#2) would let you use an autoload cookie with an explicit `autoload' call for an option or face, on the same line, just as for a command: ;;;###autoload (autoload 'f2 "file" nil 'face) At autoload-file generation time, only the `(autoload...)' sexp would be written to the autoloads file. And function `autoload' would DTRT, meaning that it would cause file `file.el[c]' to be loaded whenever face f2 is needed and not yet defined. That way, the face itself would not be defined completely at autoload time, but only when its defining file is loaded. The autoloads file would only put in place the autoloading of f2's file; it would not also predefine the face. Similarly for user options (defcustoms): ;;;###autoload (autoload 'opt1 "optsfile" nil 'option) That would not set the option value. It would only set up autoloading for the option, so that when it is needed and is not yet defined, its defining file, optsfile.el[c], would be loaded. This way, the doc for options and faces could be made available to users, and customization and loading of their definitions would involve only the logic in their defining files, not also some things happening at autoloads generation time and possibly getting in the way. In sum, the idea would be to have function `autoload' become face-aware and option-aware. IOW, be able (using function `autoload' with an autoload cookie) to separate autoloading _per se_ from predefining. That is essentially what autoloading of functions does. It does not predefine a function completely. It just "defines" it partially using a placeholder, and it puts in place a mechanism to automatically load its file, which load actually defines the function fully. The aim here would be to provide that same feature (real autoloading) for options and faces. Autoloading of functions (e.g. commands) does what autoloading was designed to do: make sure loading takes place automatically if the function is needed but not yet defined. IIUC, autoloading of anything other than a function does not do what autoloading was designed to do. An autoload cookie simply copies the defining sexp to the autoloads file, essentially defining it at the time that file is generated. And function `autoload' does nothing for a non-function (a keymap being handled as a function) - it is not option-aware or face-aware. Dunno whether I'm clear enough. And again, some lack of clarity is no doubt due to my insufficient understanding of the autoload code. Feel free to point out stuff that I'm missing. Thx.