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: 20 Nov 2003 09:35:06 -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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069339448 28966 80.91.224.253 (20 Nov 2003 14:44:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2003 14:44:08 +0000 (UTC) Cc: ihs_4664@yahoo.com, Luc Teirlinck , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Nov 20 15:44:02 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 1AMq2M-0003s9-00 for ; Thu, 20 Nov 2003 15:44:02 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AMq2L-0006Ac-00 for ; Thu, 20 Nov 2003 15:44:02 +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 1AMqsh-0005CJ-NX for emacs-devel@quimby.gnus.org; Thu, 20 Nov 2003 10:38:07 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AMqrt-00051Z-AZ for emacs-devel@gnu.org; Thu, 20 Nov 2003 10:37:17 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AMqrL-0004tg-Um for emacs-devel@gnu.org; Thu, 20 Nov 2003 10:37:15 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AMqrL-0004tT-Kx; Thu, 20 Nov 2003 10:36:43 -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 hAKEZ6bj008605; Thu, 20 Nov 2003 09:35:06 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id 89BC03C63E; Thu, 20 Nov 2003 09:35:06 -0500 (EST) Original-To: David Kastrup In-Reply-To: Original-Lines: 41 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:17964 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17964 >> > 1. Setting the variable with set-variable would not have any effect >> > other than maybe to confuse Emacs internals or the user. This is >> >> Sounds like a bug: if it works via customize-variable, there's not good >> reason why it can't work with set-variable. > There are reasons. Customize can specify actions to do whenever a > variable is set (there are a few customizable variables that switch on > minor modes, for example). That's what he said, basically and I replied that it's a bug in set-variable. For such vars, set-variable should either put a big warning or do the same as customize-variable (i.e. call the setter function). > Also when variables have a complex structure, it is a bit of policy to say > "this 20-element list does not make sense setting via set-variable". If it's too inconvenient for a user, he just won't use set-variable with it. The user can do this part of the policing himself. There's no need to introduce a distinction between two sorts of user-variables just because some are hard to change using one of the two interfaces. >> > Basically, everything can be summarized with: "use `*' if and only >> > if setting the variable with `set-variable' makes sense". I >> > should say that the fact set-variable itself will indeed not >> > distinguish (not even for completion) between `*' or no `*' is not >> > very consistent with >> >> And the fact that nobody has ever complained about the fact that >> set-variable can be used on vars that don't have a * (as long as >> they're defined with `defcustom') indicates that it is not a bad >> behavior. > And the fact that nobody has ever complained about undiscovered > crimes indicates that they are not a bad thing... Sorry, but absurd analogies do not count as an argument in my book, especially not if they resort to things like crime, nazism, etc... Stefan