From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 27 20:29:37 2012 Received: (at submit) by debbugs.gnu.org; 28 Mar 2012 00:29:37 +0000 Received: from localhost ([127.0.0.1]:41970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCglb-0000r6-Or for submit@debbugs.gnu.org; Tue, 27 Mar 2012 20:29:37 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36178) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCgl1-0000q1-Sv for submit@debbugs.gnu.org; Tue, 27 Mar 2012 20:29:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCgGi-0001ke-8P for submit@debbugs.gnu.org; Tue, 27 Mar 2012 19:57:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:34058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCgGi-0001kY-5G for submit@debbugs.gnu.org; Tue, 27 Mar 2012 19:57:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCgGg-0000BQ-FX for bug-gnu-emacs@gnu.org; Tue, 27 Mar 2012 19:57:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCgGe-0001kJ-H2 for bug-gnu-emacs@gnu.org; Tue, 27 Mar 2012 19:57:37 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:17077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCgGe-0001k4-Ai for bug-gnu-emacs@gnu.org; Tue, 27 Mar 2012 19:57:36 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2RNvWQZ002460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Mar 2012 23:57:33 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2RNvVc2015292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Mar 2012 23:57:32 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2RNvV4Q023116 for ; Tue, 27 Mar 2012 18:57:31 -0500 Received: from dradamslap1 (/10.159.35.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Mar 2012 16:57:31 -0700 From: "Drew Adams" To: Subject: 24.0.94; enhancement request: have autoload treat faces like it does options Date: Tue, 27 Mar 2012 16:57:26 -0700 Message-ID: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0MdVwv1fa3weI9T2irxJRiyTpQMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090208.4F7253ED.007D,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Enhancement request: Be able to add an autoload cookie before a `defface', and have the face definition handled appropriately, similarly to what is done for user options (variables). And be able to specify `face' as the TYPE arg for function `autoload'. IOW, have faces handled by autoloading in a way similar to user options (variables). For options, the cookie adds property `custom-autoload' to the symbol, and that property is handled appropriately in code in custom.el etc. It would be good if "function" `autoload' explicitly handled both options and faces via its TYPE argument, just as it handles functions and keymaps. In particular, I would like to be able to do the following: ;;;###autoload (autoload 'someface "somelib" "Doc" nil 'face) And then have the file somelib.el[c] be autoloaded whenever the face is used (at least wrt some set of face-accessing functions). An advantage of this is that a file of generated autoloads would not contain the actual face definition, with its sexp that evals to the face's default "value". Instead, it would just contain that `(autoload...)' form, which would DTRT. This would obviate dealing with computing the default at the time that the autoloads file is loaded. And that would mean that any dependencies within that default sexp would be handled normally, when the library itself is loaded (not when the generated autoloads file is loaded). If my use case is not clear, ignore it. You can perhaps come up with your own use case. After all, faces are similar to user options in other ways. The purpose of this enhancement request is to extend that similarity to autoloading. (Just as for options, no one is required or necessarily encouraged to autoload any faces. This would just make it possible to do so, without putting the entire face definition into the autoloads file.) In GNU Emacs 24.0.94.1 (i386-mingw-nt5.1.2600) of 2012-03-19 on MARVIN Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include' From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 27 21:03:26 2012 Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 01:03:26 +0000 Received: from localhost ([127.0.0.1]:42006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SChIL-0001el-AG for submit@debbugs.gnu.org; Tue, 27 Mar 2012 21:03:26 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:31560) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SChI4-0001eQ-P2 for 11106@debbugs.gnu.org; Tue, 27 Mar 2012 21:03:23 -0400 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 q2S0VmZH031420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <11106@debbugs.gnu.org>; Wed, 28 Mar 2012 00:31:49 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2S0VmR4028653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <11106@debbugs.gnu.org>; Wed, 28 Mar 2012 00:31:48 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2S0VlfJ023612 for <11106@debbugs.gnu.org>; Tue, 27 Mar 2012 19:31:47 -0500 Received: from dradamslap1 (/10.159.35.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Mar 2012 17:31:47 -0700 From: "Drew Adams" To: <11106@debbugs.gnu.org> References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com> Subject: RE: bug#11106: 24.0.94; enhancement request: have autoload treat faces like it does options Date: Tue, 27 Mar 2012 17:31:42 -0700 Message-ID: <54253A206B4248F99B4AD830266E374C@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com> Thread-Index: Ac0MdVwv1fa3weI9T2irxJRiyTpQMAAAyVHg 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.0A090204.4F725BF5.0062,ss=1,re=0.000,fgs=0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11106 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) I wasn't as clear as I could have been. Maybe this will help. There are I guess two requests here: 1. Handle faces (deffaces) similarly to how options (defcustoms) are handled. 2. Have function `autoload' handle both faces and options via its TYPE arg. #2 would mean that the face attributes (hereafter default "value" of the face) and the option default value would not be computed by function `autoload'. Instead, that function would just cause the proper Lisp file to be loaded whenever the face or option was first accessed. If something tries to use the face or option, and it is not yet defined, the autoload would kick in and the file would be loaded to define it. #2 is helpful (to me) because it means that actually assigning a value would be done only when the library is loaded, not when the autoload form is created. For example, ;;;###autoload (autoload 'a-face "a-file" nil 'face) would put in place the triggers that would cause file "a-file.el[c]" to be loaded when face `a-face' is first accessed (is still undefined). That load would then cause the face to be defined, by evaluating its default "value" sexp. Similarly for user options. What I'm describing is in effect what happens for autoloaded functions (IIUC). It is the loading of the file that actually defines the functions (not the creation of the autoloads or the loading of a file of autoloads). I fear I'm not being clear enough. Perhaps because it's still fuzzy to me. But maybe it will make sense to someone. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 28 09:14:14 2012 Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 13:14:14 +0000 Received: from localhost ([127.0.0.1]:42542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCshZ-0005Ms-3H for submit@debbugs.gnu.org; Wed, 28 Mar 2012 09:14:14 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:25638) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCshJ-0005M7-Ah for 11106@debbugs.gnu.org; Wed, 28 Mar 2012 09:14:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9MCqRV/2dsb2JhbACBX5x7eacJhhkEmxmECQ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="170427075" Received: from 76-10-164-85.dsl.teksavvy.com (HELO pastel.home) ([76.10.164.85]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Mar 2012 08:41:29 -0400 Received: by pastel.home (Postfix, from userid 20848) id 632BF5942E; Wed, 28 Mar 2012 08:41:29 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#11106: 24.0.94; enhancement request: have autoload treat faces like it does options Message-ID: References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com> <54253A206B4248F99B4AD830266E374C@us.oracle.com> Date: Wed, 28 Mar 2012 08:41:29 -0400 In-Reply-To: <54253A206B4248F99B4AD830266E374C@us.oracle.com> (Drew Adams's message of "Tue, 27 Mar 2012 17:31:42 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11106 Cc: 11106@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 1. Handle faces (deffaces) similarly to how options (defcustoms) are handled. I don't know what that means. > 2. Have function `autoload' handle both faces and options via its TYPE arg. Can you provide a sample scenario where that would be useful? Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 28 10:11:30 2012 Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 14:11:30 +0000 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 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 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 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 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 Received: from dradamslap1 (/10.159.35.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Mar 2012 06:39:46 -0700 From: "Drew Adams" To: "'Stefan Monnier'" References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com><54253A206B4248F99B4AD830266E374C@us.oracle.com> Subject: RE: 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: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11106 Cc: 11106@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 28 12:22:46 2012 Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 16:22:46 +0000 Received: from localhost ([127.0.0.1]:43479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCve2-0003wU-2a for submit@debbugs.gnu.org; Wed, 28 Mar 2012 12:22:46 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:10591) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCvdT-0003vm-O2 for 11106@debbugs.gnu.org; Wed, 28 Mar 2012 12:22:44 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9MCqRV/2dsb2JhbACBX5x7eYhwnhmGGQSbGYQJ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="170451950" Received: from 76-10-164-85.dsl.teksavvy.com (HELO pastel.home) ([76.10.164.85]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Mar 2012 11:50:49 -0400 Received: by pastel.home (Postfix, from userid 20848) id F264A59437; Wed, 28 Mar 2012 11:50:48 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#11106: 24.0.94; enhancement request: have autoload treat faces like it does options Message-ID: References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com> <54253A206B4248F99B4AD830266E374C@us.oracle.com> Date: Wed, 28 Mar 2012 11:50:48 -0400 In-Reply-To: (Drew Adams's message of "Wed, 28 Mar 2012 06:39:39 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11106 Cc: 11106@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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? > 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. > to let users get to their doc. That's it? So you only want it for describe-face's purpose? 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. [ Sorry, didn't read the rest, assuming that it is not relevant since I rejected the main assumption. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 28 13:40:28 2012 Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 17:40:28 +0000 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 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 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 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 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 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Mar 2012 10:08:27 -0700 From: "Drew Adams" To: "'Stefan Monnier'" References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com><54253A206B4248F99B4AD830266E374C@us.oracle.com> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11106 Cc: 11106@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 28 15:17:16 2012 Received: (at 11106) by debbugs.gnu.org; 28 Mar 2012 19:17:16 +0000 Received: from localhost ([127.0.0.1]:43656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCyMs-0008CP-TD for submit@debbugs.gnu.org; Wed, 28 Mar 2012 15:17:15 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:25074) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCyMc-0008Bf-50 for 11106@debbugs.gnu.org; Wed, 28 Mar 2012 15:17:12 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9MCqRV/2dsb2JhbACBX5x7eYhwnhmGGQSbGYQJ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="170480270" Received: from 76-10-164-85.dsl.teksavvy.com (HELO pastel.home) ([76.10.164.85]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Mar 2012 14:45:34 -0400 Received: by pastel.home (Postfix, from userid 20848) id 6E7D759437; Wed, 28 Mar 2012 14:45:34 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#11106: 24.0.94; enhancement request: have autoload treat faces like it does options Message-ID: References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com> <54253A206B4248F99B4AD830266E374C@us.oracle.com> <08A31323DD6D4526AE56E760D45A623F@us.oracle.com> Date: Wed, 28 Mar 2012 14:45:34 -0400 In-Reply-To: <08A31323DD6D4526AE56E760D45A623F@us.oracle.com> (Drew Adams's message of "Wed, 28 Mar 2012 10:08:26 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11106 Cc: 11106@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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. Indeed, but it's supposed to be an internal detail (i.e. an optimization). >> 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. Then you were not trying to answer my question (which was not "in general" but at least in one scenario, by the way). > 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? Because the user can invoke commands, but not faces (with very few exceptions). > 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)? Because a function usually depends on its surrounding code, so copying its body without its surroundings would not result in a usable function. Because such autoloaded functions are simply entry points to the package and it's convenient to be able to auto-load the package without having to `require' it explicitly. > The same reason applies to options and functions: real autoloading has a use, > independent of the use of predefinition. I don't see how faces generally depend on their surrounding code. I don't see how the use of a face will often lead to the use of the rest of the package where it's defined. [ I stopped here, sorry, too long. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 10:17:43 2016 Received: (at 11106) by debbugs.gnu.org; 28 Apr 2016 14:17:43 +0000 Received: from localhost ([127.0.0.1]:53210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1avmlC-0000U2-St for submit@debbugs.gnu.org; Thu, 28 Apr 2016 10:17:43 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:40388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1avmlB-0000Tv-CH for 11106@debbugs.gnu.org; Thu, 28 Apr 2016 10:17:41 -0400 Received: from cm-84.215.1.64.getinternet.no ([84.215.1.64] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1avmkm-00060D-W1; Thu, 28 Apr 2016 16:17:36 +0200 From: Lars Ingebrigtsen To: Stefan Monnier Subject: Re: bug#11106: 24.0.94; enhancement request: have autoload treat faces like it does options References: <7134C9FED9064A64BCE682995B981BB6@us.oracle.com> <54253A206B4248F99B4AD830266E374C@us.oracle.com> <08A31323DD6D4526AE56E760D45A623F@us.oracle.com> Date: Thu, 28 Apr 2016 16:17:16 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 28 Mar 2012 14:45:34 -0400") Message-ID: <87a8kdkec3.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 11106 Cc: 11106@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: > I don't see how faces generally depend on their surrounding code. > I don't see how the use of a face will often lead to the use of the rest > of the package where it's defined. Me neither. Closing. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 10:18:01 2016 Received: (at control) by debbugs.gnu.org; 28 Apr 2016 14:18:01 +0000 Received: from localhost ([127.0.0.1]:53213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1avmlV-0000UX-3C for submit@debbugs.gnu.org; Thu, 28 Apr 2016 10:18:01 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:40396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1avmlT-0000UO-Go for control@debbugs.gnu.org; Thu, 28 Apr 2016 10:17:59 -0400 Received: from cm-84.215.1.64.getinternet.no ([84.215.1.64] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1avmlB-00060P-Ii for control@debbugs.gnu.org; Thu, 28 Apr 2016 16:17:58 +0200 Date: Thu, 28 Apr 2016 16:17:40 +0200 Message-Id: <878tzxkebf.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #11106 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tags 11106 wontfix close 11106 From unknown Fri Aug 15 21:26:21 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 27 May 2016 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator