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: Defcustoms, how do users find them? Date: Tue, 17 Nov 2009 09:49:30 -0800 Message-ID: References: <87ocn1fnko.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1258480234 20799 80.91.229.12 (17 Nov 2009 17:50:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2009 17:50:34 +0000 (UTC) Cc: 'Emacs-Devel devel' To: "'Juri Linkov'" , "'Lennart Borgman'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 18:50:27 2009 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 1NASC9-0004Wt-FA for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2009 18:50:27 +0100 Original-Received: from localhost ([127.0.0.1]:44934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NASC9-0005yy-1z for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2009 12:50:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NASC3-0005yh-LI for emacs-devel@gnu.org; Tue, 17 Nov 2009 12:50:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NASBy-0005y6-CE for emacs-devel@gnu.org; Tue, 17 Nov 2009 12:50:18 -0500 Original-Received: from [199.232.76.173] (port=35108 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NASBy-0005y3-5y for emacs-devel@gnu.org; Tue, 17 Nov 2009 12:50:14 -0500 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:18557 helo=rgminet11.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NASBx-0005qD-O8 for emacs-devel@gnu.org; Tue, 17 Nov 2009 12:50:13 -0500 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAHHoDwS009263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Nov 2009 17:50:15 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAHHpoEu003533; Tue, 17 Nov 2009 17:51:51 GMT Original-Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 402882781258480154; Tue, 17 Nov 2009 09:49:14 -0800 Original-Received: from dradamslap1 (/24.5.185.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Nov 2009 09:49:14 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ocn1fnko.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcpneA3feyvQ+8noQlenJbdCZdF8gQAL241g X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4B02E24D.01CB:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:117107 Archived-At: > > This defcustom is not autoloaded. How are users supposed to find it? > > Should all defcustoms be autoloaded? > > Autoloading of defcustom causes problems with default values. > For autoloaded defcustoms the default is computed at the startup time > before loading .emacs and calling custom-set-variables where > other variables > get their values that may be used for computing the default value of > the autoloaded defcustom. > > Please see the related bug#4387 for more information: > http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4387 > > There is the following etc/TODO task: > > ** Remove unnecessary autoload cookies from defcustoms. > This needs a bit of care, since often people have become used to > expecting such variables to always be defined, eg when they modify > things in their .emacs. > > I'm not sure what does mean "This needs a bit of care"? > So I hesitate to remove the autoload cookie from `find-name-arg' > to fix the bug#4387. > > PS: Removing the autoload cookie from `find-name-arg' also means > adding (require 'find-dired) to rgrep where it is used, but it seems > this is not a problem. I'll generally keep out of this discussion. I'm no expert on Customize. I will add my 2c now, though. I agree with Lennart that it would be beneficial for users to have the _doc strings_ of all (or at least most, if there are particular problems for some) vanilla Emacs options available at startup. IMO, this is as important (no - more important) for `C-h v' and apropos as it is for `customize-variable'. The latter would let you see a list of options, but it wouldn't tell you anything about them. In this I disagree with Lennart, who said that providing all options for completion by `customize-variable' would be sufficient. IIUC, the difficulties Juri refers to have to do only (?) with the _values_ of those options, not with their doc strings. IOW, there is an implementation concern here, but it does not necessarily have to do with doc/help. (It might have to do also with doc the way things are implemented today, but does it _necessarily_ have to do with doc?) Couldn't we find some way to more or less "autoload" (note the quotes) only the doc strings and not also pre-initialize the values, since that could be problematic (:set, :initialize etc.)? `C-h v', apropos, etc. could then let you know what options are available and what each option is for, even if the info these help commands provide might be limited by not letting you know a value until the variable is bound. IOW, being known wrt doc/help isn't, conceptually at least, the same thing as having a value. Must we couple the two in a rigid way, so that users can know about variables only if they have values? The Emacs UI, more than any other I know of, makes it easy to discover what's there - what's available on the surface as well as what's available under the covers. It's too bad that we have this doc limitation. It's a shame we don't provide doc strings for more options (and for more commands) from the get-go. By such a limitation, we put (unnecessary?) obstacles in the way of user discovery of what's possible. I recognize that if we did what I'm asking then a simple `boundp' wouldn't be sufficient, in commands that provide help, to distinguish variables from non-variables. And I'm sure there are other implementation concerns and this is not necessarily a simple thing. But we could at least think about it and not just have the reaction "No, please god, no!". And maybe this wouldn't really be a big deal in terms of implementation. We can already provide doc for a variable without defining it (i.e. no defvar, no defcustom, no setq, no let - no value): (put 'foo 'variable-documentation "Helpful doc for `foo'.") C-h v foo foo is void as a variable. Documentation: Helpful doc for `foo'. Couldn't we use something similar as the basis for defcustom documentation, somehow gathering all of the defcustoms for a vanilla Emacs session initially, defining only the doc strings (not the values) for those that are not loaded? It would of course be good if the help provided could also point to the variable's library (automatically), but even without that info it would be useful.