From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.devel Subject: Re: doc elisp intro cross reference fixes Date: Sun, 30 Nov 2003 20:31:20 +0000 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <877k1h38fb.fsf@emptyhost.emptydomain.de> 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070224421 9314 80.91.224.253 (30 Nov 2003 20:33:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2003 20:33:41 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Nov 30 21:33: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 1AQYGA-0003dm-00 for ; Sun, 30 Nov 2003 21:33:38 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQYGA-00072A-00 for ; Sun, 30 Nov 2003 21:33:38 +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 1AQZD4-0005Du-NC for emacs-devel@quimby.gnus.org; Sun, 30 Nov 2003 16:34:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AQZCx-0005D9-GC for emacs-devel@gnu.org; Sun, 30 Nov 2003 16:34:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AQZCP-0004Xn-SJ for emacs-devel@gnu.org; Sun, 30 Nov 2003 16:34:22 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AQZCP-0004W7-F5 for emacs-devel@gnu.org; Sun, 30 Nov 2003 16:33:49 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by mx20.gnu.org with esmtp (Exim 4.24) id 1AQYEC-0003ni-Rn for emacs-devel@gnu.org; Sun, 30 Nov 2003 15:31:36 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AQYEA-000616-00 for ; Sun, 30 Nov 2003 21:31:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQYE8-00060y-00 for ; Sun, 30 Nov 2003 21:31:32 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AQYE8-0002NP-00 for ; Sun, 30 Nov 2003 21:31:32 +0100 Original-Lines: 90 Original-X-Complaints-To: usenet@sea.gmane.org User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:KSDpD1nC4yG0gJ4A4YBO38SbkKg= 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:18231 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18231 Stefan Monnier writes: >> 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. >> But maybe it is possible to change Custom such that it doesn't need >> those variables? > > Huh? Those variables are needed for other reasons, not for custom. > There simply needs to be a place where we store the current state > of those minor modes. For some minor modes, we can use things > like (member foo bar-hook) or somesuch, but in general we just > need a minor-mode variable. D'oh. I just /knew/ something had to be wrong, but I didn't know what. Hm. Okay. > 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". >> Then we could remove all the variables that have no >> effect when set via setq, > > You also want to "remove" non-existent variable like stefan-test-1 ? Well, err. Hm. How to explain... There are some options that can be tweaked via custom by customizing a variable. But what actually tweaks the option is the setter function associated with that variable. 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. But another thing that could be done is to change Emacs such that the variable isn't used as the custom interface anymore. 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. This would cause the foo-minor-mode variable to become an internal variable, not to be changed by the user. An effect of this would be that the foo-minor-mode variable could be documented as storing the current state of that minor mode, and the "Takes no effect if set via setq" warning doesn't need to be there, anymore, since also "You can customize this variable" is gone. Hm. For example, M-x foo-minor-mode RET could ask the user whether to make that setting permanent. If the user says yes, then custom would write its thing to custom-file. I realize that this is most probably not how it is going to be done, but I'm using it just as an example of how an interface that does not use customize-variable at all is possible. In some sense, this is a strange idea. After all, the current mechanism works well. But we already need Custom to be able to do other things than just setting variables (and, en passant, invoking setter functions): it would be nice if Custom could do some semantic equivalent of add-hook or remove-hook, and it would be nice if Custom could do some semantic equivalent of define-key. So once we do this, we can also have Custom do the semantic equivalent of invoking foo-minor-mode... All of the above is just an idea. Maybe it turns out it is better to continue using the existing setter-functions mechanism. Maybe you already thought about all of this, and discovered that what I'm suggesting doesn't work. In this case, I apologize. Kai