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: 30 Nov 2003 16:08:32 -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> <3FBD2081.2050000@yahoo.com> <873cc650kd.fsf@emptyhost.emptydomain.de> <877k1h38fb.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070226614 13060 80.91.224.253 (30 Nov 2003 21:10:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2003 21:10:14 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Nov 30 22:10:11 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 1AQYpW-00057D-00 for ; Sun, 30 Nov 2003 22:10:10 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQYpW-0007Sa-00 for ; Sun, 30 Nov 2003 22:10:10 +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 1AQZm6-0008Ku-9a for emacs-devel@quimby.gnus.org; Sun, 30 Nov 2003 17:10:42 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AQZm0-0008Jn-LX for emacs-devel@gnu.org; Sun, 30 Nov 2003 17:10:36 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AQZlU-00088v-Iz for emacs-devel@gnu.org; Sun, 30 Nov 2003 17:10:35 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AQZlT-00087J-Iw for emacs-devel@gnu.org; Sun, 30 Nov 2003 17:10:03 -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 hAUL8Xbj004916; Sun, 30 Nov 2003 16:08:33 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id CB8723C63E; Sun, 30 Nov 2003 16:08:32 -0500 (EST) Original-To: Kai Grossjohann In-Reply-To: <877k1h38fb.fsf@emptyhost.emptydomain.de> Original-Lines: 57 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:18232 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18232 >>> Maybe one needs to think more radical thoughts: Where is the sense in >>> allowing me to do (setq global-font-lock-mode t) even though it has no >>> effect? >> >> Do you really mean `setq' (i.e. something outside custom or even >> outside set-variable) ? > Yes. I still have trouble believe it, since in the rest of the message I get the impression that you consider set-variable and setq as being almost the same. `set-variable' is much closer to customize-variable (and we pretty much agreed in this thread that it should be made closer by paying attention to setter functions). >> Furthermore, AFAIK, custom already does not need the variable: if you >> provide a setter and a getter that don't use the variable, it won't >> use the variable. There might be a few places in custom where >> this is not quite true but it should be easy to fix. > Well, IIUC, M-x customize-variable RET global-font-lock-mode RET is > how people frob that setting, isn't it? And if the variable went > away, people couldn't type that anymore. That's what I meant with > "need". And what I said is that even if the variable went away they still could, because custom does not have to pay any attention to the variable: it just calls the getter and setter and looks at properties of the symbol. > Now one thing that could be done is to change Emacs such that the > setter function is called more often (eg, the setter function could be > called by set-variable). Then, tweaking the option via custom and > tweaking the option another way works similarly -- by changing the > variable. Right, that's one of things we almost agreed on in this thread (I personally don't care whether set-variable calls the setter or not, but it needs to pay attention to it and either call it or tell the user that maybe he's not doing what he thinks he is). > But another thing that could be done is to change Emacs such that the > variable isn't used as the custom interface anymore. It's not use as such: only the symbol is used, not the variable (i.e. not the variable slot of the symbol). > Instead of "setting a variable" via custom, people would "turn on a hook" > via custom. Custom could write (foo-minor-mode 1) or (foo-minor-mode -1) > into the .emacs file, depending on the setting. Custom could already do that. I happen to think it should, but I haven't written the code to do it (it's a bit tricky since custom needs to be able to recognize it as a setting so it knows the state saved in the .emacs file). Stefan