From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: doc elisp intro cross reference fixes Date: 20 Nov 2003 15:51:29 +0100 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 1069340922 566 80.91.224.253 (20 Nov 2003 15:08:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2003 15:08:42 +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 16:08:38 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 1AMqQ9-0005ho-00 for ; Thu, 20 Nov 2003 16:08:37 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AMqQ9-0006Tf-00 for ; Thu, 20 Nov 2003 16:08:37 +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 1AMrKp-00048H-UB for emacs-devel@quimby.gnus.org; Thu, 20 Nov 2003 11:07:11 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AMrEs-0000eS-O7 for emacs-devel@gnu.org; Thu, 20 Nov 2003 11:01:02 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AMr7K-0005zd-SW for emacs-devel@gnu.org; Thu, 20 Nov 2003 10:53:46 -0500 Original-Received: from [217.80.160.118] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AMr7D-0005mX-0C for emacs-devel@gnu.org; Thu, 20 Nov 2003 10:53:07 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hAKEpXI5017871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2003 15:51:33 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hAKEpTdl017867; Thu, 20 Nov 2003 15:51:29 +0100 Original-To: Stefan Monnier In-Reply-To: Original-Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:17968 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17968 Stefan Monnier writes: > >> > 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). If set-variable does not tend to consult the "customize" data structures in other circumstances, it would be unexpected if it did in this case. I do seem to remember, though, that set-variable declined setting a variable to values opposed to any possibly customize declaration. So perhaps making set-variable do pretty much the "set for current session" operation procedure of customize would be sensible behavior. That does not imply that the current behavior would be a bug, simply that it might make sense to change it (along with its documentation). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum