From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: customize-apropos Date: Mon, 12 Dec 2005 16:22:19 -0800 Message-ID: References: <200512122356.jBCNuaQ07998@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1134433462 23161 80.91.229.2 (13 Dec 2005 00:24:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2005 00:24:22 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 13 01:24:20 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Elxwv-0003vP-5r for ged-emacs-devel@m.gmane.org; Tue, 13 Dec 2005 01:23:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElxxP-0000D5-9U for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 19:23:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ElxwY-0000D0-Ai for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:22:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ElxwW-0000Cn-SI for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:22:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElxwW-0000Cj-BY for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:22:56 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ElxyK-0004a1-5z for emacs-devel@gnu.org; Mon, 12 Dec 2005 19:24:48 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBD0eJti000785 for ; Mon, 12 Dec 2005 18:40:19 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBD0MLc2025548 for ; Mon, 12 Dec 2005 17:22:21 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBD0MLS1025542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 12 Dec 2005 17:22:21 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200512122356.jBCNuaQ07998@raven.dms.auburn.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:47581 Archived-At: IOW, your argument is really an argument for not showing anything in a Custom buffer that is not customizable. That might be reasonable, but it is not the current policy. I believe that it _is_ the current policy not to show any variable in a Custom buffer that is not defined with defcustom. That is exactly why I installed my patch to customize-apropos. The numeric argument is just a way for a super-sophisticated user to override that policy. I personally do not care about that numeric argument. I just kept it because it was there. I would not have put it in myself. Use of the numeric argument was precisely the point in question. Yes, without the argument variables in Custom are customizable. But current policy also shows non-customizable variables if you use the numeric arg. That's the point under discussion - like it or not, that's the current policy. Instead of saying just "NO CUSTOMIZATION DATA; you should not see this" (which is what I see, in a CVS snapshot from June), a user option should be labeled as such, with, for example, a message/label such as "You cannot customize this option, but you can set it with command `set-variable'. That might be somewhat confusing, but it is more helpful than what is displayed currently. No. People should _really_ not see this, unless for some (strange) reason they very explicitly asked for it. The message is intended for two kinds of people: the average user and the person who wrote a defcustom and checks his work. The "you should not see this" tells the average person to stay away from it and, if he saw it without doing anything unusual, file a bug report. It tells the programmer that there is a bug in his defcustom. What do you mean by "some (strange) reason"? If we allow the numeric-arg behavior, then we allow non-customizable stuff to be shown - that's current policy, strange or not. If we allow numeric-arg behavior, then we want to inform people that they cannot (or should not - see below) customize it (in Custom). I think we agree so far (?). Where we disagree, I think, is whether we should tell people how they _can_ change such non-defcustom options. I think we should mention `set-variable'; you do not. Your suggested replacement text is incorrect. If you really know what you are doing, you _can_, up to a point, customize these variables in the Custom buffer. I take your word for it (but tell me how; I'm curious). Change my use of "cannot" to "should not" in that case: these are variables that we do not want people to try to change using Customize, right? Do we agree that Custom buffers are not _intended_ for changing non-customizable user variables (sorry, I mean variables not defined with defcustom). Since some things will work and others not, I would definitely not recommend this for the average user. Not recommend what? Trying to partially customize non-defcustom stuff? Or using the numeric arg with customize-apropos to display non-defcustom vars? I also believe that the usefulness of this feature for advanced users is limited. I have never used it except out of curiosity. I'm not clear on which feature you're referring to. The numeric-arg feature? If so, I have no problem with getting rid of it. But there should be some way for users to get the list of all user variables (defcustom or not) - do you want another command? And it would be preferable for those user vars that are customizable to be shown in a Custom-buffer context, for easy customization. Would you prefer a separate command that did both of these things? 1) showed the matching defcustom vars in a Custom buffer, 2) listed the matching non-defcustom vars in a *Help* buffer, with their descriptions and an intro sentence saying that you can change them with `set-variable'. I would prefer just using Custom and putting the message about `set-variable' there, next to each non- defcustom var.