From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Documentation not clear for the Lisp function set-variable Date: Tue, 28 Jun 2005 18:19:00 +0200 Message-ID: References: <87slz6nr3h.fsf@jurta.org> <874qbi8p49.fsf-monnier+emacs@gnu.org> Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1119976255 15077 80.91.229.2 (28 Jun 2005 16:30:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2005 16:30:55 +0000 (UTC) Cc: juri@jurta.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 28 18:30:54 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DnIyh-0006ga-5h for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 18:30:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnJ6Y-0004VO-U9 for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 12:38:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DnJ2Z-0003AY-4F for emacs-devel@gnu.org; Tue, 28 Jun 2005 12:34:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DnJ2P-000359-Pf for emacs-devel@gnu.org; Tue, 28 Jun 2005 12:34:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnJ2N-0002zV-AC for emacs-devel@gnu.org; Tue, 28 Jun 2005 12:34:15 -0400 Original-Received: from [64.233.182.193] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DnIs6-00047a-2K for emacs-devel@gnu.org; Tue, 28 Jun 2005 12:23:38 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so230731nfe for ; Tue, 28 Jun 2005 09:19:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gfZA6RrQXXaBoIPK7rjnr9PJToMEPFt1udQyYb25z3LAgrFyCURpEozR4wUvCT4uj7lsAQvTOrvXI6KQZ280oe/EOM1yG5H++F9IrV+dXPN0mx6QZ8eafJs7lLm7EwdyM93lwqXCYGUHoX6rqkZ2DtCBCXFY0jbfwqb0A24L/is= Original-Received: by 10.48.250.12 with SMTP id x12mr156500nfh; Tue, 28 Jun 2005 09:19:00 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Tue, 28 Jun 2005 09:19:00 -0700 (PDT) Original-To: Stefan Monnier In-Reply-To: <874qbi8p49.fsf-monnier+emacs@gnu.org> Content-Disposition: inline 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:39797 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39797 > I think we should use the complete-in-turn thingy Hmm. Some more info, please? :-) > so that completion first > tries to complete without obsolete vars and only if that fails then it tr= ies > to complete with obsolete vars. OK, once I understand what are you referring to with the "complete-in-turn thingy"... > I recommend not to classify cases as "alias" and "obsolete alias" > but as "alias" and "obsolete" where this latter case can be an alias > or not. Setting an obsolete var should be discouraged, whether it's alia= sed > to some other var or not. OK, with respect to giving a warning (wrt completion I don't agree, but I'll implement whatever is deemed best, of course). > If you want a warning for aliases, it should come after, in the same way = as > the display of shortcuts after M-x foobar RET. Where is that implemented? > As for warnings of obsoleteness, I would argue to put them before (with > a (sit-for 1)), since we want to send a clear message that they should no= t > use this variable any more. OK, makes sense. If I understand correctly, you're OK'ing the `user-variable-p' patch and we're now discussing patching `set-variable'. --=20 /L/e/k/t/u