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: Sun, 11 Dec 2005 21:40:09 -0800 Message-ID: References: <200512120503.jBC53N628378@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 1134366366 2885 80.91.229.2 (12 Dec 2005 05:46:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2005 05:46:06 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 12 06:46:05 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ElgUL-00058H-N9 for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 06:44:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElgUo-0005KM-ME for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 00:45:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ElgR3-0003ny-Ok for emacs-devel@gnu.org; Mon, 12 Dec 2005 00:41:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ElgQm-0003ji-En for emacs-devel@gnu.org; Mon, 12 Dec 2005 00:41:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElgQl-0003jU-P7 for emacs-devel@gnu.org; Mon, 12 Dec 2005 00:41:00 -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 1ElgSQ-00089S-0v for emacs-devel@gnu.org; Mon, 12 Dec 2005 00:42:42 -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 jBC5w5R7025141 for ; Sun, 11 Dec 2005 23:58:05 -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 jBC5eH7b013637 for ; Sun, 11 Dec 2005 22:40:17 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-73-217.vpn.oracle.com [141.144.73.217]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBC5eGRZ013623 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 11 Dec 2005 22:40:17 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <200512120503.jBC53N628378@raven.dms.auburn.edu> 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:47519 Archived-At: Your doc-string changes correctly reflect the current prefix-arg behavior - the arg distinguishes customizable variables from other variables. However, wouldn't it also be useful to be able to distinguish all user variables (options) - whether customizable or not - from internal variables? Yes, but is it useful to have them in a Custom buffer? M-x apropos-variable will show all (loaded) user-options (defined with defcustom or docstring starting with a `*') and with a numeric arg it shows all variables. Of course, it will not show them in a Custom buffer. I see your point, I think. But wouldn't it be at least as useful to be able to show all user options (i.e., including those that are not customizable) in a Custom buffer as it is to show _all_ variables in a Custom buffer (i.e., including those that a user should not change)? 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. If we keep the current policy of showing stuff that cannot be customized, then it would also be good to clearly indicate when a user option cannot be customized and when a variable is internal and should not be changed. That is, clearly distinguish the three classes in a Custom buffer. I believe that, currently, user-settable user options that are not customizable are indistinguisable from internal variables in a Custom buffer. 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.