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

[Brady Montz <bradym@balestra.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> >>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:
> 
>     Brady> For this particular example, a popup menu of common "what
>     Brady> you might want to see after reading this help text" actions
>     Brady> might be the best menu modification.
> 
> Algorithm?  Or are we going to have to rely on massive effort from
> volunteers?  :-)

Heh, being a developer and not a manager, I'll always pick the
algorithm when possible :).

>     Brady> I dislike relying on having things like only in a menu
>     Brady> though, since it's not obvious to right-click when you want
>     Brady> "more." A little "click here for more" button is more to my
>     Brady> liking.
> 
> But more what?  Does that mean go from the docstring to Info page (and
> should that be the User Guide or the Lispref?), or the mode's keymap
> wallpaper, or the mode docstring, or hyperapropos, or Info index?  Or
> (dare I say it?) help-on-help?

Sounds like a good start to me. Keeping in mind the 90/10 rule, I'm
still happy with an interface with better cross-referencing between
these various "doc domains." 

For example, I have no beef using a web site that has a dictionary
cross refernced with a thesaurus with an encyclopedia. People
understand that sometimes you have to skip around. I just want the
skipping around to be as easy as possible. 

I think that having links between the various doc sources that we
already have and know about which are immediately apparant to the user
would nicely take care of the 90% case. 

As I've said many times before, in the cross referencing case we
already have the most of the info we need, and are largely there. If
we only automate/unify what experienced users do by habit (here I do
C-h a, then I select that and do a C-h f, now I select that and do a
find-library, ...) that would be a nice improvement.

Then, when could consider more exotic brainstormy stuff like dropping
in a googly search mechanism for the info pages, or (something I would
love) "check this out" lists for functions added or changed since
(x)emacs version xx.yy.zz, etc.

> I think one problem is that most of the people working on (X)Emacs cut
> their teeth on permuted indicies, man -k, apropos, whatis, etc
> commands.  Possibly if `C-h a' were glossed "search for functions (and
> variables) with similar names" instead of "apropos"?  (Would "Names
> like ... (C-h a)" do it?)

Yeah. As has been hashed in the vocabulary portion of this thread,
emacs has an, um, unusual linguistic heritage compared to many of the
newer users. I really have no opinion about what to do about that, but
lean towards the glossary approach. Gotta call these things something,
and nothing picked will be obvious to everyone.

But, as much as I like "apropos" I imagine people might be happier
with something else. sigh.

>     Brady> Help shouldn't require help.
> 
> Have you ever tried to use Windows help?
> 
> I have _never_ used Windows for anything other than sanity-check
> Cygwin builds of XEmacs and that wonderful doc2txt utility that MS
> Office provides.  But I'm better at navigating Windows help than any
> of the Windows users I know -- if they don't understand, they ask; if
> they don't get a useful answer, they give up or look in the deadtree
> manual.
> 
> I'm afraid that "help shouldn't require help" is just wishful thinking.

I can't even imagine that windows help is something we can even
compare to. That is such a useless pile. 

However, I have found MSDN, especially the newer content which appears
to have a higher quality standard, to be very useful though. I've
satisfied 90% of my windows API questions by wandering about there,
and have learned lots of unasked for but very useful stuff along the
way. Plopping into a contract at microsoft with absolutely no windows
experience (sympathies please), once pointed towards MSDN I found it
needed no help at all. And, at least the stuff I've been talking about
(functions, variables, generic API sorta stuff), is a very similar
problem to what MSDN was designed for. And, I've been assuming the
users, while emacs novices, are not computer novices.

I see emacs as primarily a programmer's editor, not a word
processor. If we are to model after anything, we should model after
what programmers are used to. For that reason, I don't think things
like "apropos" were a bad choice. But it is an increasingly archaic
one.

To chime in on "buffers" - programmers know what buffers are, they know
that words that programs use have funny meanings, and they know you
gotta use a glossary sometimes. So, I don't see any need to change
that terminology.

But, programmers are used to things like MSDN, man pages, and howtos,
so looking at them isn't a bad thing.

Back to your point, yes "help shouldn't require help" might be just
wishful thinking. How about "help should require minimal help?"

-- 
 Brady Montz
 bradym@balestra.org