From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: doc elisp intro cross reference fixes Date: Sun, 30 Nov 2003 09:19:11 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200311301519.hAUFJBj10396@raven.dms.auburn.edu> References: <87wua28zux.fsf@zip.com.au> <200311190528.hAJ5SrK02553@raven.dms.auburn.edu> <3FBBD155.2050703@yahoo.com> <200311192238.hAJMcTM06424@raven.dms.auburn.edu> <3FBD2533.6090503@yahoo.com> <200311270014.hAR0E0i02821@raven.dms.auburn.edu> <200311271611.hARGBhP04028@raven.dms.auburn.edu> <200311291445.hATEjN408572@raven.dms.auburn.edu> <200311291828.hATISht08904@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1070206127 11850 80.91.224.253 (30 Nov 2003 15:28:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2003 15:28:47 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Nov 30 16:28:44 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 1AQTV5-0000Yu-00 for ; Sun, 30 Nov 2003 16:28:43 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQTV5-0003jj-00 for ; Sun, 30 Nov 2003 16:28:43 +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 1AQUQT-0000S1-6T for emacs-devel@quimby.gnus.org; Sun, 30 Nov 2003 11:28:01 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AQUQ5-0000Rc-7Q for emacs-devel@gnu.org; Sun, 30 Nov 2003 11:27:37 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AQUPZ-0008RY-7T for emacs-devel@gnu.org; Sun, 30 Nov 2003 11:27:36 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AQUPY-0008H4-6y for emacs-devel@gnu.org; Sun, 30 Nov 2003 11:27:04 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id hAUFPWKk020734; Sun, 30 Nov 2003 09:25:32 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id hAUFJBj10396; Sun, 30 Nov 2003 09:19:11 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: abraham@dina.kvl.dk In-reply-to: (message from Per Abrahamsen on Sun, 30 Nov 2003 14:06:43 +0100) 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:18220 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18220 Per Abrahamsen wrote: I'd vote (0): if there is no group specified, don't put it in any group. That is exactly what I described under (1). The option may very well end up in a group anyway (explicit call to custom-add-to-group or the second argument to defgroup), but if it doesn't don't worry about it. I somehow forgot about those possibilities. There is, at closer reading, indeed nothing, even in the current Elisp manual, that says that a defcustom should have a :group. The manual seems to suggest that every option should wind up in at least one group (which can indeed be achieved in a variety of ways, it does not have to be done by specifying :group), and even that suggestion could be reversed. Having options that aren't in any group doesn't break anything, and we have already spend way to much energy on this non-problem. If nothing else, there is still one problem we have to take care of, namely the change mentioned in the NEWS: ** defcustom and other custom declarations now use a default group (the last group defined in the same file) when no :group was given. This change should be reversed. Not only does it not take custom-add-to-group and the second argument to defcustom into account, it clearly assumes that even the most inappropriate group is better than no group whatsoever. If somebody would have chosen a group for `eval-expression-print-level', `kill-read-only-ok' or `yank-excluded-properties', using one of the alternative (and documented) possibilities, then there would have been no reason to put them in the "paren-blinking" group too, just to make absolutely sure that they are in at least one group. Seeing such options in the "paren-blinking" group would be confusing to the Custom user. Sincerely, Luc.