From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Documentation not clear for the Lisp function set-variable Date: Tue, 28 Jun 2005 12:09:01 -0400 Message-ID: <874qbi8p49.fsf-monnier+emacs@gnu.org> References: <87slz6nr3h.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1119974709 10038 80.91.229.2 (28 Jun 2005 16:05:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2005 16:05:09 +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:05:06 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DnIa0-0002V7-Iy for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 18:04:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnIhs-0006ox-Md for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 12:13:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DnIhJ-0006cE-PK for emacs-devel@gnu.org; Tue, 28 Jun 2005 12:12:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DnIhD-0006Yp-Si for emacs-devel@gnu.org; Tue, 28 Jun 2005 12:12:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnIhC-0006Vd-Ih for emacs-devel@gnu.org; Tue, 28 Jun 2005 12:12:22 -0400 Original-Received: from [209.226.175.188] (helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DnIiP-00038Q-9f; Tue, 28 Jun 2005 12:13:37 -0400 Original-Received: from alfajor ([67.71.35.153]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050628160900.XEXU27245.tomts25-srv.bellnexxia.net@alfajor>; Tue, 28 Jun 2005 12:09:00 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id 4ABEFD732C; Tue, 28 Jun 2005 12:09:01 -0400 (EDT) Original-To: Juanma Barranquero In-Reply-To: (Juanma Barranquero's message of "Tue, 28 Jun 2005 11:17:50 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:39795 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39795 > - Is there a consensus whether obsolete aliases should be shown or > not? In a recent message Juri proposed that obsolete aliases were not > shown by default, but could be set anyway. Currently `set-variable' > does not accept unknown variable names (to prevent the user setting > misspelled variables, I suppose). Doing what Juri proposes would mean > either changing that, or modifying `read-variable' to check after the > fact whether a given symbol is an obsolete alias or not; all that for > no clear added benefit, and with the added inconvenience that the user > will end typing more if he really wants to set an obsolete alias and > not the current variable the alias points to. I think we should use the complete-in-turn thingy so that completion first tries to complete without obsolete vars and only if that fails then it tries to complete with obsolete vars. > - It is OK for `user-variable-p' to return nil for alias loops > instead of signaling an error? Looks fine to me. If it's an alias loop, it's not a user-variable. > - Should `set-variable' give warnings for all aliases, for obsolete > aliases only? Should o it for obsolete variables even if they aren't > aliases? 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 aliased to some other var or not. > - What's the right moment to give the warning? Before setting the > value or after it? 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. 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 not use this variable any more. Stefan