From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Tue, 23 Apr 2002 09:31:07 +0300 (IDT) Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1019540022 26562 127.0.0.1 (23 Apr 2002 05:33:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2002 05:33:42 +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 16zsvu-0006uI-00 for ; Tue, 23 Apr 2002 07:33:42 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zsww-0001yU-00 for ; Tue, 23 Apr 2002 07:34:47 +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 16zsvj-0002kU-00; Tue, 23 Apr 2002 01:33:31 -0400 Original-Received: from is.elta.co.il ([199.203.121.2]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zsv8-0002O2-00 for ; Tue, 23 Apr 2002 01:32:54 -0400 Original-Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id JAA23462; Tue, 23 Apr 2002 09:31:08 +0300 (IDT) X-Sender: eliz@is Original-To: Brady Montz In-Reply-To: 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:3073 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3073 On 22 Apr 2002, Brady Montz wrote: > 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) Emacs has tooltips for menu items, and the Help menu uses that heavily to help the novice. It's not easy to get the help text right, and did take a few iterations, but at least you have a larger place to cram some descriptive text into than just the menu item itself. > 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. If the Help menu items aren't obvious, their text or organization (or both) should be improved, IMHO. > 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 second Stephen's question: Algorithm? The idea is very nice, and I'm sure many of us played with it, but it's hard to come up with a viable implementation. If you can suggest a practical solution, please do. > 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. Tooltips can help here as well. In Emacs, we try to put on every clickable part of the display a tooltip that tells about mouse-2's action, since many users don't know about mouse-2. > > > 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). The manual is the place where all of these come together. The single command `i' will find a function, a key, a variable, and a subject (like "paste"). The other help commands exist because they are more efficient when you know better what you are looking for. > 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). Try `i' in the Info manual. (Perhaps we should have an example to make this less abstract.) > > 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. I agree in principle, but please tell what kind of better search do you have in mind. Most kinds I can think of need additional information that someone will have to supply, information that isn't in the text of the manual or in the doc strings. > > 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. > > Yeah, I'm not so sure about that one though. I've never found those to > be particularly useful. Try the HP site where they give advice about troubleshooting printer problems (don't have the URL handy, sorry). When done right, that's a very powerful and useful technique.