From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Getting more info on a variable in Customize buffers Date: Sun, 2 Jan 2005 17:57:58 -0800 Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1104717567 25325 80.91.229.6 (3 Jan 2005 01:59:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Jan 2005 01:59:27 +0000 (UTC) Cc: Reiner Steib , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 03 02:59:17 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ClHV7-0004LK-00 for ; Mon, 03 Jan 2005 02:59:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClHgE-0005HB-W8 for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2005 21:10:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClHg6-0005H5-JY for emacs-devel@gnu.org; Sun, 02 Jan 2005 21:10:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClHg6-0005Gt-59 for emacs-devel@gnu.org; Sun, 02 Jan 2005 21:10:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClHg6-0005Gq-2M for emacs-devel@gnu.org; Sun, 02 Jan 2005 21:10:38 -0500 Original-Received: from [141.146.126.229] (helo=agminet02.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1ClHUO-0006mh-AB for emacs-devel@gnu.org; Sun, 02 Jan 2005 20:58:32 -0500 Original-Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j031wSet004987; Sun, 2 Jan 2005 17:58:28 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j031wQ04004960; Sun, 2 Jan 2005 17:58:27 -0800 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j031wPWH020699; Sun, 2 Jan 2005 18:58:25 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-64-253.vpn.oracle.com [141.144.64.253]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j031wGK3020653 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 2 Jan 2005 18:58:21 -0700 Original-To: "Stefan" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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: main.gmane.org gmane.emacs.devel:31715 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31715 > - You need to load `cus-edit.el' to see this variable (not a > great problem, but it would be good to have it autoloaded). Most variables are only visible once the corresponding package is loaded. That's normal. It may be normal for most variables, but I think this one merits an autoload. It sounds from this thread as if the decision to prettify names by default in Customize is not too solidly supported anyway, and that many users might prefer the Lisp names. If users who potentially would prefer Lisp names don't even know that displaying Lisp names is an option, then that is a loss. There are plenty of `custom-*' variables whose doc strings are available on startup of Emacs - this should be one of them. > What about 1) having click-a-name-to-toggle-its-display-type, as I just > mentioned, and 2) display a message in the echo area when you do this, > saying that you can use `custom-unlispify-tag-names' to set the custom > display type globally. Finding this (oddly named) option would then be > fairly easy and common. The problem is that custom's "variables" aren't the same as Elisp variables. They look very much alike, and they usually are exactly the same, but that's not always the case. The :get, :set, and :init thingies allow you to define a custom setting "foo-bar" which controls "toto" rather than the variable "foo-bar". I probably don't fully understand, although I think I follow you. Sounds like an implementation problem to me - or perhaps a design problem? So, what about the "usual" case? (90%? 99%? 99.999%? 80%? 60%? 51%? - what does "usually" mean here?) Why couldn't/shouldn't this be implemented for the _usual_ case, and not worry about the corner cases? Anyway, if this is a problem for the unusual cases, then how is possible to have option `custom-unlispify-tag-names' work for them? If there is a problem with corner cases, then that problem must already manifest itself with `custom-unlispify-tag-names', no? If you can get the desired effect by turning off `custom-unlispify-tag-names', then why can't you turn it off locally by clicking the "pretty" name? What's the obstacle, here? If you care about the variable names, I recommend you just skip custom altogether and write elisp code in your .emacs. It'll be cleaner and easier to understand. That sounds ridiculous to me (but perhaps I misunderstand you). Emacs priests have been preaching that Customize is _The Way_ for quite some time now. Most of the standard Emacs code now uses Customize for user variables. To understand and modify the standard Emacs variables, we are naturally led to Customize. And you're now telling us that if I we don't like something about the Customize UI we should just skip it? Instead of letting Customize show the same thing (as an option!) that `C-h v' shows, we should just forget it? Why not get rid of `C-h v', or prettify its names too, while you're at it? If the Customize UI is not enough user-friendly or presents obstacles to navigating the available information, the answer is not to send users packing, to tell them to just use `setq's in their .emacs. I "care about variable names" because that's what I need to care about in order to use Emacs well. If the code and the doc strings and the Info doc and Apropos and... all used the Customize "pretty" names - if none of _them_ "cared about variable names" - then no, I wouldn't care much about variable names either. Sheesh! (Quand les poules auront des dents...)