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 11:17:50 +0200 Message-ID: References: <87slz6nr3h.fsf@jurta.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 1119951068 29714 80.91.229.2 (28 Jun 2005 09:31:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2005 09:31:08 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 28 11:31:07 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DnCQV-0005vL-GA for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 11:30:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnCYK-0001rY-0j for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 05:38:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DnCJQ-0004jG-1Q for emacs-devel@gnu.org; Tue, 28 Jun 2005 05:23:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DnCJM-0004hq-Tu for emacs-devel@gnu.org; Tue, 28 Jun 2005 05:23:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnCJL-0004bd-UR for emacs-devel@gnu.org; Tue, 28 Jun 2005 05:23:20 -0400 Original-Received: from [64.233.182.193] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DnCIR-0000Tu-TV for emacs-devel@gnu.org; Tue, 28 Jun 2005 05:22:24 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so206291nfe for ; Tue, 28 Jun 2005 02:17:50 -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=cjQMzcRTpwz/LNnL9dyFzZofBZNN1+UiXgnY1iC+iUESSD7jvckgv285rDEW86TqLWbLFXRCH2I87oJFgqkufJxc8NEY+OjVBVpIdPHbEgpwu2P91tZ1iDzMUDsjR+01BYTj7mHRmXwr/pOLh0HJl0HyWI7Q4juvxqUsVZLc0eo= Original-Received: by 10.48.250.12 with SMTP id x12mr139983nfh; Tue, 28 Jun 2005 02:17:50 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Tue, 28 Jun 2005 02:17:50 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: 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:39776 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39776 On 6/28/05, Richard M. Stallman wrote: > Please install your patch. After all this discussion, I'm not sure what's to be installed, so let me recapitulate. The patch below modifies `user-variable-p' so it also considers as user variables these aliases that point, directly or indirectly, to other user variables; that includes also obsolete aliases, I'm not filtering them out. It also returns nil for alias loops, irrespective of whether any of the aliases in the loop would qualify as a user variable or not. This patch fixes the problem originally reported by Juri, i.e., that `set-variable' didn't allow setting aliases to user options. Questions remaining: - 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. - It is OK for `user-variable-p' to return nil for alias loops instead of signaling an error? I think yes because `user-variable-p' is not a user command, ant its main use is with `mapatoms' and completion, where the idea is filtering out uninteresting variables. - Should `set-variable' give warnings for all aliases, for obsolete aliases only? Should o it for obsolete variables even if they aren't aliases? - What's the right moment to give the warning? Before setting the value or after it? Sorry for being so prolix, but I prefer to ask everything and try to avoid multi-headed hydras... er, threads where no clear conclusion is reached :) --=20 /L/e/k/t/u