From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: doc elisp intro cross reference fixes Date: 26 Nov 2003 19:51:47 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87wua28zux.fsf@zip.com.au> <87ad6vdsxi.fsf@mail.jurta.org> <200311190418.hAJ4ITC02466@raven.dms.auburn.edu> <200311190528.hAJ5SrK02553@raven.dms.auburn.edu> <3FBBD155.2050703@yahoo.com> <200311192238.hAJMcTM06424@raven.dms.auburn.edu> <3FBD2533.6090503@yahoo.com> <200311262349.hAQNn2l02786@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069894661 10123 80.91.224.253 (27 Nov 2003 00:57:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 27 Nov 2003 00:57:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Nov 27 01:57:38 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1APATS-0003Mu-00 for ; Thu, 27 Nov 2003 01:57:38 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1APATR-0007gA-00 for ; Thu, 27 Nov 2003 01:57:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1APBQY-0005vn-TD for emacs-devel@quimby.gnus.org; Wed, 26 Nov 2003 20:58:42 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1APBPv-0005bj-8S for emacs-devel@gnu.org; Wed, 26 Nov 2003 20:58:03 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1APBP7-0004hZ-J8 for emacs-devel@gnu.org; Wed, 26 Nov 2003 20:57:44 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1APBLV-0003Gr-Mv for emacs-devel@gnu.org; Wed, 26 Nov 2003 20:53:30 -0500 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (8.12.9/8.12.9) with ESMTP id hAR0plbj002611; Wed, 26 Nov 2003 19:51:47 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id 691483C63E; Wed, 26 Nov 2003 19:51:47 -0500 (EST) Original-To: Luc Teirlinck In-Reply-To: <200311262349.hAQNn2l02786@raven.dms.auburn.edu> Original-Lines: 60 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner: Found to be clean X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18154 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18154 >> It is an entirely different interface. >> (defalias 'set-variable 'customize-set-variable) >> or >> (defalias 'set-variable 'customize-set-value) >> would make sense though. The difference is that the first uses the >> :set function, the later doesn't. > Indeed. > Indeed which one? Either: they both "would make sense". > Indeed: (defalias 'set-variable 'customize-set-variable) > Note that if you mean this literally, this is a non-trivial change in > as far as prefix arguments are concerned. That doesn't mean it doesn't make sense. It just means it has to be souped up a little. But that's a minor issue of coding: nothing compared to the amount of work necessary to convince people on this list to accept the change in behavior w.r.t whether or not there's a * in the docstring. > Indeed. We'd just need to make (defvar a b "*c") equivalent > to (defcustom a b "c"). > You make this sound a lot simpler than it would be. This will have to > be handled individually and very carefully for each *-defvar, a huge > amount of work. Doesn't have to be done that way, does it ? > If an author decided to use a *-defvar instead of a > defcustom, there probably is a good reason why he decided not to use a > defcustom. In few very rare cases. > For instance, default-enable-multibyte-characters has a > *-defvar. You do not want to turn this into a defcustom, because it > would duplicate the defcustom for enable-multibyte-characters, which > also sets the default value. It's just another case of multiple name for the same var, as is the case for all the default-* vars, right? We can probably take care of this specially, if needed, although I must say I don't see the harm is adding a "redundant" custom-var, as long as the variable does not appear in any normal group and is thus only accessed via M-x customize-variable or M-x set-variable or somesuch. > That would be extremely confusing to the Custom user. I'd expect most custom users would never even be confronted with the potential for confusion. And we can of course try and fix those things as time goes: the important thing is that there is no real hurry. > Not only would blindly turning a *-defvar into a > defcustom be dangerous, it is impossible. BZZT! Thanks for playing, it works exactly as I showed: (defcustom a b "c") Stefan