From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Brady Montz Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: 22 Apr 2002 13:46:50 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: References: <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp> <87vgak30cw.fsf@tleepslib.sk.tsukuba.ac.jp> <7263-Mon22Apr2002224014+0300-eliz@is.elta.co.il> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019508515 15089 127.0.0.1 (22 Apr 2002 20:48:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2002 20:48:35 +0000 (UTC) Cc: xemacs-design@xemacs.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16zkjj-0003vG-00 for ; Mon, 22 Apr 2002 22:48:35 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zkka-0006w7-00 for ; Mon, 22 Apr 2002 22:49:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zkjT-0002ye-00; Mon, 22 Apr 2002 16:48:19 -0400 Original-Received: from c64-255-216-95.sea1.cablespeed.com ([64.255.216.95] helo=sandman.balestra.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zki8-0002hg-00 for ; Mon, 22 Apr 2002 16:46:56 -0400 Original-Received: (from bradym@localhost) by sandman.balestra.org (8.10.2/8.10.2) id g3MKkoF04020; Mon, 22 Apr 2002 13:46:50 -0700 (PDT) X-Authentication-Warning: sandman.balestra.org: bradym set sender to bradym@balestra.org using -f Original-To: Eli Zaretskii In-Reply-To: <7263-Mon22Apr2002224014+0300-eliz@is.elta.co.il> Original-Lines: 156 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3053 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3053 "Eli Zaretskii" writes: > > From: Brady Montz > > Date: 22 Apr 2002 09:54:09 -0700 > > > > I see very little in the UI which makes these various > > options obvious, and the biggest single struggle I have helping emacs > > beginners is helping them learn how to find out > > information. Currently, people have suggested three ways to get to > > sort-paragraph from sort-lines: open sort.el (my fallback approach), > > apropos, or Info-elisp-ref, and putting xrefs in the doc strings. > > These all (and more) are under "Help" in the menu bar. > > If you are saying the the menu bar is not obvious enough, then please > suggest practical ways to make that more obvious. The problem with > help functions is that, IMO, a user should generally request help > explicitly, or make some sign that she needs help. Otherwise, if we > stick the help info into her face when it is not requested, we risk > ending up with the equivalent of that annoying MSWord-style paper > clip. So if the menu bar is not enough, please suggest the ways Emacs > should use to decide that the user needs help (and perhaps what kind > of help as well). Yes, can't have clippy. I much prefer a passive approach where everything is unobtrusively at your fingertips over clippy's obtrusive sticking fingers in your eyeball. As for the menu bar, I don't know what emacs 21's looks like. since I moved to xemacs back when emacs was at 19. I don't think that, for this particular scenario, the xemacs help menu bar is at all obvious. Asside from the terminology issues (will a novice understand the difference between lookup command and lookup function, and "apropos" is the epitome of obscure) which is being covered elsewhere, it's certainly not obvious to me which of those menu items is the best thing to select to show me what's similar to the command I currently have open in a help buffer. For this particular example, a popup menu of common "what you might want to see after reading this help text" actions might be the best menu modification. I dislike relying on having things like only in a menu though, since it's not obvious to right-click when you want "more." A little "click here for more" button is more to my liking. > > Back to my example. So far, three people have suggested three > > ways. First, not all of these ways work for every function (for > > example, C-h C-f gnus just failed for me) > > Is "C-h C-f" supposed to show the Info node for a command you type? > If so, the equivalent command works for me in Emacs with gnus. Yeah. I was referring to Stephen's usage of that. Doesn't work on my xemacs installation, so it's probably just an install issue. > > > nor for every situation > > (for example, starting from a keybinding instead of a function name) > > "C-h K" does that for me in Emacs. Exactly. My point which you responded to was that for my example (sort-lines), the three (maybe four) methods people gave for getting the list of related commands don't work in all situations. For the related situation where you know the key command but not the name, you need yet another method (C-h k, followed by some others). So, we have a situation where there's approx. 14 useful C-h commands worthy of mention in the xemacs help menu, and I don't think it's immediately obvious which to use when (oh, I know the key so I use C-h k. I want the related functions and because this function is nicely named C-h a will probably do the trick. I want a general overview and this is a stable core function so the info page is probably good let's try C-h C-f, this really should be in the info index so let's get to that with C-h i, this is a function so C-h f, no wait it's a variable C-h v, dammit I just want the key binding so C-h w). Help shouldn't require help. Here's what I'm starting to come to after this discussion - I'd like an abstraction layer or interface between me and the help/configuration systems. Not a wizard, but a unified interface that wouldn't require a wizard. I think we already have all the info we need in the various docs and source code, and most of the functionality is already there. It's a matter of presenting more efficient interface to it all. > > none of them are apparant from the UI > > Help->More Manuals->Find Key in Manual and Find Command in Manual do > that in Emacs. Just because they are in the menu does not mean that it's apparant to the user than when he's reading about sort-lines in a help buffer, he should select those items to find out about related commands. It is reasonable expect a user to figure out that the "find command in manual" might do that (but only for things with an info page). I don't see anything in the interface of that help buffer pointing me to that. The menu bar is about the furthest thing from my mind while reading that text. It's out of band. > > So, time to experiment with some code. I'd like to know any idioms > > that people have for finding information. In particular, I'd like to > > know the situations in which those idioms are used. > > It depends on what you are looking for, I think. If the goal is to > find quickly a description of some subject, then a keyword-based > search (a user types several keywords, and Emacs finds the appropriate > documentation) is IMHO the best. The `i' command in Info gets pretty > close to that (it's normally the first or second method I try when > looking for things). I'm thinking a better search mechanism would be really nice. Just having better searching of the info pages would be huge. > This could be inappropriate for people who want an introduction to > some broad issue, though. > > Another idea is to try the hierarchical approach: a user is asked a > series of questions about the subject she wants to read about, which > (the questions) progress from general to more and more specific, until > the subject is determined and its documentation displayed. With each > question, the user is given a small number (like 4) of possible > responses that should narrow the search in the next stage. Some > knowledge bases on the net are organized in such ways. Yeah, I'm not so sure about that one though. I've never found those to be particularly useful. I think the info pages do a nice job for that. Just prefix each item or section with a "I want to" or "what is a" and it seems it's about as close as we could hope to get. There might be some really nifty knowledge base lisp engines out there that we could benefit from though. > > For example, > > knowing a fair bit about emacs, I generally start with my comfortable > > turf which is a known similar function, then I apropos, search the > > info pages or source, or a known phrase (generally with nice emacs > > terms like buffers, regions, yank, that are stirring up so much > > trouble elsewhere on this thread :)), and I google search. > > A suggestion for a procedure that uses Emacs facilities in a certain > order (derived from experience) can be found in the node "Help" of > the latest Emacs user manual (shipped with Emacs 21.1). I'll check that out. -- Brady Montz bradym@balestra.org