Wizards (was: Re: Oort Version)

[Per Abrahamsen <abraham@dina.kvl.dk>]

A couple of years ago I did some prelimenary work on integrating
customize with w3, which should allow for the creation of wizards that
guide users through customization.  Unfortunately I didn't get as far
as creating a good example, and the code has likely suffered bit-rot
since.

Karl Kleinpaste <karl@charcoal.com> writes:

> - Prepackaged, selectable nnmail-split-rules entries to do "obvious"
>   things, such as splitting yahoogroups.com mailing lists to their own
>   groups, or selecting classes of users into usable groups (prototypes
>   for things like "family", "coworkers", "kinky people I know from
>   Usenet"), or punting mailer errors to their own group.  Think of how
>   Netscape Messenger walks the user through filtration rules.  Also,
>   we should pre-make (`G m') any mail groups requested, so that the
>   user needn't (e.g.) go hunting for `F' in *Group*.

That sound interesting, it may even being doable now with the : rules.

> - Help the user auto-graft BBDB onto his universe.  "What address book
>   does Gnus provide?" is another perennial gnu.emacs.gnus question.

A problem is that BBDB is FSF code, which makes it problematic to
depend on it in a FSF project like Gnus.  I sometimes fantasize about
writting a LBDB for FSF just to have the functionality present always.

> - Maybe some sort of WYSIWYG buffer configurator.  There are lots of
>   viewpoints on what buffers ought to be where in what context.  The
>   defaults aren't bad, but a lot of people want to do other things,
>   and they tend to be rather confused by gnus-add-configuration.

Kyle Jones apparently have some very good code for VM which could be
rewritten for Gnus.

> Regardless of any luser-proofing, we should ensure that customize does
> the Right Thing from within Gnus.

The Right Thing(TM) is to write in custom-file, and leave .gnus for
manual customization.  The only reason customize write in .emacs is
that RMS only want one customization file.  In XEmacs, they are moving
towards one file for manual customization, and one file for automatic
customization which makes lots of sense.  Splitting the file for
automatic customization further adds complexity without any measurable
benefits.