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 11:48:26 -0800 Message-ID: References: <200501021327.j02DRpq08157@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1104695400 25152 80.91.229.6 (2 Jan 2005 19:50:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Jan 2005 19:50:00 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 02 20:49:49 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 1ClBjY-0004zF-00 for ; Sun, 02 Jan 2005 20:49:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClBuf-0000wt-LM for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2005 15:01:17 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClBuX-0000wa-DB for emacs-devel@gnu.org; Sun, 02 Jan 2005 15:01:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClBuW-0000vu-2Z for emacs-devel@gnu.org; Sun, 02 Jan 2005 15:01:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClBuV-0000vr-Uv for emacs-devel@gnu.org; Sun, 02 Jan 2005 15:01:08 -0500 Original-Received: from [148.87.2.201] (helo=inet-mail1.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1ClBiv-0004OS-BF for emacs-devel@gnu.org; Sun, 02 Jan 2005 14:49:09 -0500 Original-Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j02JmwcW023929; Sun, 2 Jan 2005 11:48:58 -0800 (PST) Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j02JmnBP023842; Sun, 2 Jan 2005 11:48:54 -0800 (PST) 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 j02JmmAH029555; Sun, 2 Jan 2005 12:48:48 -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 j02Jmh9d029534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 2 Jan 2005 12:48:47 -0700 Original-To: "Luc Teirlinck" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200501021327.j02DRpq08157@raven.dms.auburn.edu> 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:31696 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31696 I hesitated whether to send my message to emacs-devel as a suggestion or to help-gnu-emacs as a question. Perhaps I should have done the latter, as some of the "problems" I mentioned were user error. Mea culpa. However, maybe there is a lesson or two for emacs-devel anyway, in that at least this user couldn't seem to find this info. And I still think that some of the info is not there to be found. I personally agree that it would be better not to prettify variable names in Custom, but this probably has been discussed before. You can get the variable name by first clicking on "Show Value", then on "State" and then selecting "Show initial Lisp expression". Thanks. However, that seems to show the _initial expression_ (written in the code), which is not the same as the current value of the variable. I still don't see any way to obtain the current value as a sexp, without using `C-h v'. I assume that the initial Lisp expression is available here to give users an idea of how to code an expression leading to a value. But customizing is about changing the current value, so that current value should also be available (in sexp form). Also, another State menu item, "Don't show as Lisp expression", seems to be presented as the converse of "Show Initial...", but it shows the current value (in pretty form), not the initial expression. If these are supposed to be opposites (as suggested by their complementary enablement), then shouldn't they both be about initial expression or both be about current value? "Don't show..." doesn't just hide the Lisp expression; it also shows the current value. And the word "as" in its name suggests that it shows the value not "as" a Lisp expression, which suggests that Show Initial Lisp Expression does show the _value_ as a sexp, which is incorrect. This is confusing, to me. If we make both the initial Lisp expression and the current value available as sexps alternately in the same display field, then the menu items should reflect that: Show Initial Lisp Expression, Show Value as Lisp, Show Value as Text, or some such; and each menu item should only be disabled when its action is a no-op (when what it shows is already shown). I guess that no-op disabling is what happens now, but 1) Show Value as Lisp is missing, and 2) Show Value as Text is called "Don't Show as Lisp Expression", and this, together with 3) the complementary enablement, misleads me into thinking that "Don't Show as..." is somehow the converse of Show Initial Lisp Expression". In any case, perhaps State is the wrong menu for this "show" stuff, IMO. I expect to find menu items for _changing_ (setting) the state there (the tooltip says "Change the state of this item"). Neither of these menu items changes the state (value) of the variable or even the state of the variable's setting wrt Emacs sessions. I don't expect to see items for _showing_ the variable's defining expression or its current value in the (change-) State menu. Why don't we move these show/don't-show items to the Show Value menu (whose tooltip says "Show the value of this item", which is closer to what "Show initial Lisp expression" and "Don't show as Lisp expression" do? And change "Show Value" back to "Show", as it was in Emacs 20 (since the initial Lisp expression is not the variable value, but an expression that yields a value). That way, we would have one menu (State) for changing the variable's session state and another menu (Show) for changing its Customize display state. (And Hide would then be inappropriate, obviously.) If we did that, then State would be better named Change. However, the State button is not so much about changing the variable value (the Value Menu and the input text fields are for that) as it is about _saving_ the new value for the current session or future sessions. The State button would be best named "Setting", which indicates both 1) the act of setting/resetting and 2) actions concerning the current setting. And the presence of "Setting" will serve as a hint that changing the value is not enough: it needs to be set. BTW, all "buttons" that are actually menus should somehow look different from the action buttons that immediately do something. Links to other locations should look like links (e.g. underlined), as discussed previously; action buttons should look (as now) like buttons that you press for an immediate action; and menus should look different from both. A common appearance for menus that are not in a menu bar is an icon or text button with a tiny down-pointing triangle: "Show v". Finally, why tie up the action to show the real (Lisp) variable _name_ with the action to show the Lisp _value_ or the initial expression? Someone looking for the variable name will not necessarily think to look for the Lisp value or the initial sexp in order to find the name. I'd suggest that display of real (Lisp) names vs pretty names be a user option (variable), so that it is possible to globally display all names in either way (so you can, say, search the Customize buffer). Also, clicking either name could toggle that individual name to the opposite name display (Lisp <--> pretty). And I repeat my suggestion for Expand All (or Show All) for the information in the More buttons (so you can search all doc strings for the group). 2) a link to the variable definition in the source code If you need to read the source code to customize a variable, then there is a really bad problem with the docstring. Somebody wanting to study source code is going to do C-h v. Why should one need to do `C-h v'? Customize does everything else that `C-h v' does, so why not let it also get you to the code? I disagree that doc strings should or could provide all of the info provided by the source code - they will never do that. And these are not necessarily two different groups of "somebodys": many (most?) users consult both doc and code sometimes - they are complementary information sources. And the question is not just whether you _need_ to consult the source code to be able to _customize_ a variable - Customize is not just for changing things (customizing); it is also an options and options-groups _browser_ (remember `edit-options'?). Even if a doc string is perfect, I might want to consult the code - and I doubt that I am alone in that. If we do decide to provide a link to the code as we do in `C-h v', then the need to show the initial Lisp expression in the Customize buffer disappears or is diminished. Showing the current value is much more important (to me), anyway, than showing the initial Lisp sexp. 3) a button to display the Lisp value of the variable (Hide/ Show/Show Lisp would do the trick). Can be done as explained under 1). In this case, the pretty form is sometimes more helpful to the user than the actual Lisp value. Each is useful, for different needs. Again, the current Lisp value (not just the initial expression) should be available, and the menu item is in the wrong menu, IMO. 4) perhaps a link to the variable's explanation in Info (when appropriate) The person writing the defcustom can already make such a link. (Using the :link keyword.) Thanks; I wasn't aware of that. Yes, that's the right way to handle this. - To the Customize buffer for an individual variable only, we add: 1) everything listed above for the Customize group buffer 2) a link to the Customize group buffer There already is such a link. It says: Parent groups: Ediff Hook where "Ediff Hook" is a link you can follow. Apologies. I was looking for those parent-group buttons in the same position as in the other Customize buffers; the parent-groups links in this case are at the buffer bottom, not the top. That little inconsistency threw me off. There is a lot to read/scan in a Customize buffer. I looked all over for those links, but somehow I didn't see them (old eyes). It's important to keep things the same in the different Customize buffers, whenever possible, so users can find things easily without needing to reread the same boilerplate text they've already read in the other buffers. I'd suggest moving these links to their usual place (near buffer top), unless there is some good reason not to. And I see now why we can't just drop the individual-variable Customize buffer and send the user instead to the group Customize buffer (to provide context): a variable can belong to more than one group. Thanks, Drew