From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.devel Subject: Re: doc elisp intro cross reference fixes Date: Thu, 20 Nov 2003 13:13:53 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <3FBD2081.2050000@yahoo.com> 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1069359612 17276 80.91.224.253 (20 Nov 2003 20:20:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2003 20:20:12 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Nov 20 21:20:09 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 1AMvHd-00049u-00 for ; Thu, 20 Nov 2003 21:20:09 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AMvHc-0001Ih-00 for ; Thu, 20 Nov 2003 21:20:09 +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 1AMwA8-0007Qb-Dq for emacs-devel@quimby.gnus.org; Thu, 20 Nov 2003 16:16:28 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AMw9Z-0007Pd-AD for emacs-devel@gnu.org; Thu, 20 Nov 2003 16:15:53 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AMw92-0007Gu-JI for emacs-devel@gnu.org; Thu, 20 Nov 2003 16:15:51 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AMw8u-0007FE-Sw for emacs-devel@gnu.org; Thu, 20 Nov 2003 16:15:13 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AMvBT-0002Lh-00 for ; Thu, 20 Nov 2003 21:13:47 +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 1AMvBR-0002LZ-00 for ; Thu, 20 Nov 2003 21:13:45 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AMvBQ-0004G2-00 for ; Thu, 20 Nov 2003 21:13:44 +0100 Original-Lines: 64 Original-X-Complaints-To: usenet@sea.gmane.org User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 X-Accept-Language: en-us 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:17978 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17978 Stefan Monnier wrote: >>I disagree. It is a useful distinction, and programmers can take >>advantage of it to prevent users from setting variables in a way that >>they shouldn't (and thence submitting bug reports when they don't get >>the desired effect). > > Can you give concrete examples where the distinction makes sense ? The example from the "Variable Definitions" node of the Emacs Lisp manual (cited by Luc): global-font-lock-mode >>I don't find the explanation of Variable Definitions in the Emacs Lisp >>manual that Luc cited to be too subtle. > > How many elisp programmers know about it and understand it ? How would I know either thing about other programmers? But ignorance of the law is no defense. >>set-variable and customize are independent mechanisms that are enabled >>by a doc string convention and the custom-* symbol properties >>respectively, and as a programmer I'd like to retain control over those >>mechanisms. > > Why should they be independent mechanisms ? > What is the benefit ? Why should something be only allowed via M-x > customize-variable but not via M-x set-variable (and vice-versa, BTW) ? They are independent because customize was introduced as a new mechanism, instead of extending set-variable. Whether they remain so is apparently up for discussion. (Would you feel comfortable removing set-variable, or aliasing it to customize?) Personally, I only use set-variable and avoid customize completely. I understand that programmers (including myself) want to provide the customize interface to the features they provide. But if I (as a user) have to use customize to enable feature foo, I'd rather just do M-x turn-on-foo-mode; and I don't want to be allowed to set-variable foo-mode if it doesn't do the right thing. > As a programmer, the distinction seems very faint and I have a hard time > coming up with cases where it could make sense to prevent one use > and allow the other. > > As a user it just makes for inconsistency where some variables can be set > via M-x set-variable while others need M-x customize-variable. That "inconsistency" accurately reflects the difference between variables whose values (alone) determine Emacs' behavior and those that don't (because they interact with other things). -- Kevin Rodgers