From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: autoload cookies for defcustoms Date: Sat, 23 Jan 2010 21:24:57 +0100 Message-ID: References: <2DC911234A9B4A6ABD34459FB8C26C1C@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1264278340 30052 80.91.229.12 (23 Jan 2010 20:25:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Jan 2010 20:25:40 +0000 (UTC) Cc: Emacs-Devel devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 23 21:25:32 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NYmXz-0001Sr-F4 for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2010 21:25:31 +0100 Original-Received: from localhost ([127.0.0.1]:40932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYmY0-0005R4-IS for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2010 15:25:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYmXv-0005Qo-5n for emacs-devel@gnu.org; Sat, 23 Jan 2010 15:25:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYmXp-0005Ot-Nc for emacs-devel@gnu.org; Sat, 23 Jan 2010 15:25:25 -0500 Original-Received: from [199.232.76.173] (port=52891 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYmXp-0005Oo-Cn for emacs-devel@gnu.org; Sat, 23 Jan 2010 15:25:21 -0500 Original-Received: from mail-fx0-f215.google.com ([209.85.220.215]:37304) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYmXn-00010X-FD for emacs-devel@gnu.org; Sat, 23 Jan 2010 15:25:20 -0500 Original-Received: by fxm7 with SMTP id 7so527674fxm.8 for ; Sat, 23 Jan 2010 12:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=rqs+X29V5+kkap1/5b5GcwkzaAXio+kRiRisAFdjEjQ=; b=M0vfL5rATZIWaiPJZzfwt6GpOaWTqNOP6GH3Pbc3mpJ4FJBNws1O1Alh+ZlGVz2vzx StPQGlJtcWLY/VHF+T+0a0gQKThPByCfswiIeym6FhIqHTWibFrfLlFjpkOogrXzBj/i C8VxFuw7abaXhPRXH9WYb4E0VLhmxB4Eot69g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=u10ooXc94nJlenwcTTrio7ekwOj87ZOmSl86AVCw6QxDCNgPFwmBVBdHsx7DDriQ5q +EsoPpFw1tErV4lBlON8J6zFw55SmHXm8zzHycfnCpXTC0WwpQDx8BvWBj7qEjR+5XFb CNIHatZldIckeJkMX2p/m9kuc2WrSejnYs7c4= Original-Received: by 10.239.172.208 with SMTP id b16mr530066hbf.39.1264278317123; Sat, 23 Jan 2010 12:25:17 -0800 (PST) In-Reply-To: <2DC911234A9B4A6ABD34459FB8C26C1C@us.oracle.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:120310 Archived-At: On Sat, Jan 23, 2010 at 7:31 PM, Drew Adams wrote: > Just curious. Is there a policy, for the Lisp code distributed with Emacs, about > using autoload cookies for defcustoms? If so, what is it? We had a discussion about that in November: http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00504.html The conclusion there was that all defcustoms (~7000) can't be autoloaded but that we can probably set it up so that completion of options knows all option names (and maybe apropos can know about them too). But we did not finish that. I think I have some more things to test there, but anyone who want to join is of course wellcome. > Looking through the code, it seems that most defcustoms are not autoloaded, but > some are. And in the same library some might be and others not. > > Some use `purecopy' for their values, so I guess it makes sense to autoload > those. But it's not clear which came first, the cookie or the decision to use > `purecopy'. > > If, in some library, only the options that use `purecopy' are autoloaded, > doesn't that give a misleading impression to users of `C-h v'? They see only the > `purecopy' ones (before loading), which aren't necessarily the most important to > know about. > > IOW, are there two conflicting criteria for autoloading an option: (1) its > importance or frequency of use or the need for users to know about it before > loading vs (2) the purely technical (implementation) criterion of its use of > `purecopy'. Shouldn't the only criterion be use- and user-centered (i.e., #1)? > > Some options that do not use `purecopy' are nevertheless autoloaded. And some > that do use `purecopy' do not have an autoload cookie - e.g., > `epa-file-name-regexp', `automount-dir-prefix', `directory-free-space-program', > `search-whitespace-regexp', `jka-compr-load-suffixes', `rmail-file-name', > `site-run-file', `initial-scratch-message', `vc-directory-exclusion-list', > `adaptive-fill-regexp', `adaptive-fill-first-line-regexp'. (Is that wrong, or > are all of those libraries always preloaded?) > > If there is no general policy, and this is decided individually for each > defcustom, then just what considerations affect the judgment? And why is there > such variability among libraries? > > The same question could apply to command definitions, but there there doesn't > seem to be such a difference among libraries for them. Most commands seem to > have autoload cookies (just as most options do not), and I'm guessing that those > commands that do not are considered to be less often used. > > > >