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: Mon, 01 Dec 2003 21:14:43 +0000 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87d6b8qlz0.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> <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 1070342665 24639 80.91.224.253 (2 Dec 2003 05:24:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Dec 2003 05:24:25 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Dec 02 06:24:22 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 1AR31K-0004Zd-00 for ; Tue, 02 Dec 2003 06:24:22 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AR31K-0006hy-00 for ; Tue, 02 Dec 2003 06:24:22 +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 1AR3x6-0004CH-IY for emacs-devel@quimby.gnus.org; Tue, 02 Dec 2003 01:24:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AR1o8-0007VE-Uz for emacs-devel@gnu.org; Mon, 01 Dec 2003 23:06:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AR1VT-0004fa-Sk for emacs-devel@gnu.org; Mon, 01 Dec 2003 22:47:55 -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 1AQwUH-0003gi-HI for emacs-devel@gnu.org; Mon, 01 Dec 2003 17:25:49 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by mx20.gnu.org with esmtp (Exim 4.24) id 1AQvNj-0004EC-TB for emacs-devel@gnu.org; Mon, 01 Dec 2003 16:15:00 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AQvNi-0006Gt-00 for ; Mon, 01 Dec 2003 22:14:58 +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 1AQvNh-0006Gl-00 for ; Mon, 01 Dec 2003 22:14:57 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AQvNh-0005jq-00 for ; Mon, 01 Dec 2003 22:14:57 +0100 Original-Lines: 79 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:8h2Ve9R9U4VU/KCQgFruo3y8xPY= 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:18257 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18257 Stefan Monnier writes: >>> 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. Sorry, I still said something misleading. I didn't know that Custom only looked at 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). Yes, that's one way to do it. Is it the only one? >> 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). But to the user, it looks like setting a variable: M-x customize-variable RET scroll-step RET M-x customize-variable RET global-font-lock-mode RET The former is just a pretty interface to setting a variable, the latter is a pretty interface to the global-font-lock-mode function. The only way for a user to see that they are different is from the name of the variable. Maybe it's my view at things. For me, Custom is a pretty interface for things people do in their .emacs files. And setq is one of them, whereas add-hook and define-key are others. It looks a lot like customize-variable is the pretty interface to setq, whereas pretty interfaces to add-hook and define-key are lacking. And once you add pretty interfaces to add-hook and define-key, you can also add a pretty interface to turning on/off modes. I even asked for being able to add comments to custom settings, since ";;" is also often used in my .emacs file ;-) It's quite possible that this is a bad way at looking at it. What's the way you look at it? >> Instead of "setting a variable" via custom, people would "turn on a hook" Eek. I meant "turn on a mode", not "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). Cool. Kai