Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

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.