Ok, I have had it. A proposal for wizards.

Ok, I have had it. A proposal for wizards.

[David Kastrup]

Emacs comes bundled with a whole lot of packages that are not loaded
by default.  The typical scene when somebody complains to a guru "it
would be so convenient if Emacs could do such-and-such" is "well,
have you enabled/configured this-and-that?" -- blank stare.

So what to do about that?  Wizards.  A wizard is a human-friendly
walk-through through some configuration issue.

A package registers for wizards in manner similar to autoload cookies
(we usually want neither the package nor its wizard loaded unless the
user is actually going to configure anything), and it will usually
register for a major mode instead of a function call.  Now we get a
"wizard" menu with unexamined goodies highlighted, and a conditional
magic wand toolbar button that appears whenever any goody for the
current major mode has not yet been examined.  The autoload
cookie-like thing will be enough to provide a title line such as

RefTeX  Manage Crossreferences, Indexes and tocs in TeX modes
[Mark as Seen] [Configure] [Info]

When I press [Mark as Seen], this means the obvious thing (it will
register the fact in a customized variable or something).  When I
press [Info], I get the manual, when I press [Configure], I enter a
dialog with explanations of what the stuff does and Yes/No questions
and the most important customizable variables.  This dialog will
obviously be stored in a file of its own so as to be only loaded when
needed (usually once per user).  When new packages get installed
side-wide, appropriate wizard entries would want to get added in order
to notify the users that new features are available.

I mean, take a look alone at the minibuffer-related modes: we have
oodles of useful things like iswitchb-mode, file-name-shadow-mode,
minibuffer-electric-default-mode and so on.  Nobody ever uses them
because nobody knows about them.  And would have to read info pages
in order to find out more, and follow the instructions in each of
those different files for switching the feature on, and so forth and
so on.  Too much trouble.

Advanced modes (like AUCTeX or cperl-mode or so) would register their
wizards also in the modes they are supposed to supplant.  That way
people would be notified if superior or different alternatives were
available.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, I have had it. A proposal for wizards.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: 02 Jan 2004 04:28:42 +0100
> 
> Emacs comes bundled with a whole lot of packages that are not loaded
> by default.  The typical scene when somebody complains to a guru "it
> would be so convenient if Emacs could do such-and-such" is "well,
> have you enabled/configured this-and-that?" -- blank stare.
> 
> So what to do about that?  Wizards.  A wizard is a human-friendly
> walk-through through some configuration issue.

Last time we discussed something similar, the overall consensus was
to call these ``saints'', not ``wizards''.

Re: Ok, I have had it. A proposal for wizards.

[David Kastrup]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > From: David Kastrup <dak@gnu.org>
> > Date: 02 Jan 2004 04:28:42 +0100
> > 
> > Emacs comes bundled with a whole lot of packages that are not loaded
> > by default.  The typical scene when somebody complains to a guru "it
> > would be so convenient if Emacs could do such-and-such" is "well,
> > have you enabled/configured this-and-that?" -- blank stare.
> > 
> > So what to do about that?  Wizards.  A wizard is a human-friendly
> > walk-through through some configuration issue.
> 
> Last time we discussed something similar, the overall consensus was
> to call these ``saints'', not ``wizards''.

Wonderful.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, I have had it. A proposal for wizards.

[Danilo Segan]

"Eli Zaretskii" <eliz@elta.co.il> writes:
>
> Last time we discussed something similar, the overall consensus was
> to call these ``saints'', not ``wizards''.
>

Just to point out that Gnome (GNU Desktop environment) is
standardizing on "assistants" instead (mostly because everything else
like 'druid', 'wizard' is hard to translate to other languages).

Even though Emacs UI is not translated, if there's no any practical
reason not to use the same terminology, I think 'assistant' would be a
good choice.

Emacs manual seems to contain only one occurence of word "assistant",
so I don't see a terminology clash anywhere.

Cheers,
Danilo

Re: Ok, I have had it. A proposal for wizards.

[David Kastrup]

Danilo Segan <dsegan@gmx.net> writes:

> "Eli Zaretskii" <eliz@elta.co.il> writes:
> >
> > Last time we discussed something similar, the overall consensus was
> > to call these ``saints'', not ``wizards''.
> >
> 
> Just to point out that Gnome (GNU Desktop environment) is
> standardizing on "assistants" instead (mostly because everything
> else like 'druid', 'wizard' is hard to translate to other
> languages).
> 
> Even though Emacs UI is not translated, if there's no any practical
> reason not to use the same terminology, I think 'assistant' would be
> a good choice.

Personally, I don't like "saint" since the predominant quality
associated with sainthood is not wisdom and/or teaching but
perseverance and faith, and this is exactly what the user will need
without assistance.  However, I'll be willing to let those assistants
be called shoplifters, easter bunnies or toll booths as long as
somebody implements them.

And for all I care, whoever implements them gets naming rights.  So
win your fight for the right name by beating everybody else in
implementing them, and I'll defend your choice of name with a
vengeance.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, I have had it. A proposal for wizards.

[Miles Bader]

Danilo Segan <dsegan@gmx.net> writes:
> Just to point out that Gnome (GNU Desktop environment) is
> standardizing on "assistants" instead (mostly because everything else
> like 'druid', 'wizard' is hard to translate to other languages).

I like the word `assistant', it's straight-forward and clear.

`Wizard' sounds like someone trying to be cute, and sort of promotes the
idea that `computers are hard, you cannot hope to understand them';
`assistant' says `hey, nothing magic, but I'll try to give you a hand,'
-- not only friendlier, but more honest too: these sort of automatic
assistants/wizards _aren't_ magic, and _do_ screw things up all too
often.  Trying to pretend otherwise isn't doing the user any favors...

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Ok, I have had it. A proposal for wizards.

[Richard Stallman]

This proposal sounds vaguely similar to C-h p.
With C-h p you can look at a category and then browse the
packages in it.

C-h p doesn't have all the features that you propose.
It doesn't have a way to mark packages as "seen" or
a way to go to their customization.  Perhaps someone could
add those features to it.

Currently C-h p uses the Commentary section of the package; more packages
have that than have Info documentation.  But one could add a button to
view the Info documentation when there is some.

Re: Ok, I have had it. A proposal for wizards.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> This proposal sounds vaguely similar to C-h p.
> With C-h p you can look at a category and then browse the
> packages in it.

My proposal was to bind the hierarchy to a major mode rather than a
category.  The difference is that Emacs knows about the major mode it
is in, but not about the categories that might be related.

In consequence, Emacs can offer a specific selection of relevant
packages to configure at any point of time.

Also, the idea was not just to provide information, but also offer
the most common configuration options.

The focus of C-h p is about browsing independently of what one is
currently doing.  My idea was to have stuff that is relevant at the
moment presented and configurable.

It might be an idea also to group the offered packages according to
their category keywords, but this would not change the proposal much.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum