From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: defvaralias Date: Fri, 6 May 2005 16:30:57 +1200 Message-ID: <17018.62209.92386.375984@farnswood.snap.net.nz> References: <200505060142.j461gYF08458@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1115354097 19894 80.91.229.2 (6 May 2005 04:34:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 6 May 2005 04:34:57 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 06 06:34:55 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DTuXv-0004OK-Pi for ged-emacs-devel@m.gmane.org; Fri, 06 May 2005 06:34:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DTueZ-0002Nh-QX for ged-emacs-devel@m.gmane.org; Fri, 06 May 2005 00:41:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DTuWX-0002Fg-MW for emacs-devel@gnu.org; Fri, 06 May 2005 00:33:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DTuWV-0002E3-OZ for emacs-devel@gnu.org; Fri, 06 May 2005 00:33:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DTuWV-0002CY-EH for emacs-devel@gnu.org; Fri, 06 May 2005 00:33:11 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DTuZY-0002E0-Ev for emacs-devel@gnu.org; Fri, 06 May 2005 00:36:20 -0400 Original-Received: from farnswood.snap.net.nz (p89-tnt1.snap.net.nz [202.124.110.89]) by viper.snap.net.nz (Postfix) with ESMTP id 03EFC4BDDE2; Fri, 6 May 2005 16:30:53 +1200 (NZST) Original-Received: by farnswood.snap.net.nz (Postfix, from userid 501) id C282862A99; Fri, 6 May 2005 05:30:57 +0100 (BST) Original-To: Luc Teirlinck In-Reply-To: <200505060142.j461gYF08458@raven.dms.auburn.edu> X-Mailer: VM 7.19 under Emacs 22.0.50.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:36745 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36745 Luc Teirlinck writes: > The old docstrings of define-obsolete-{function,variable}-alias > contained statements that if no docstring was provided, that is, > `(define-obsolete-{function,variable}-alias 'old 'new)', then OLD > would get the docstring of NEW, _unless_ it already had one. This has > been replaced with references to the `defalias' and `defvaralias ' > docs, which have no such "unless" statements. The "unless" appears to > be definitely false in the `function' case. But it is true in the > variable case. That is because it is false for defalias, but true for > defvaralias. That was my mistake. I looked at the behaviour of defvaralias and assumed defalias behaved the same way. > There are two solutions for the variable case. Document the fact in > the docstring and Elisp documentation of defvaralias, or make > defvaralias behave exactly like defalias and get rid of the "unless" > behavior. I prefer the latter. The patch below would implement > it. I can install if desired. > > To be more concrete: > > After: > > (defvar var1 "DOC1") > (defvar var2 "DOC2") > (defvaralias 'var1 'var2) I think if an alias is made only then only one of the variables needs to be declared. > C-h v var1 RET > > now shows "DOC1", whereas after the patch below it shows "DOC2", which > is behavior consistent with defalias. As Stefan has pointed out defvaralias has a symmetry in its arguments (unlike define-obsolete-variable-alias neither) but clearly it would make sense to be consistent with defalias. Nick