Re: Oort Version

[Karl Kleinpaste <karl@charcoal.com>]

"Robin S. Socha" <robin@socha.net> writes:
> I'd like to see some luser-proof clicky-clicky interface to fancy
> split rules.

Take off the qualifying end clause and I'd be really interested: Some
very general, very wide-ranging luser-proofing.

That is, it seems to me that there continues to be a huge gap between
us, the Gnus cognoscenti, and people who've managed to install XEmacs
but have just barely figured out that it's got a built-in tutorial.
The latter folks, as exemplified in news.software.readers this week,
have trouble even invoking Gnus for the first time.  I had to write a
brief walk-through for someone, just to help him set gnus-select-
method and start it all up.  Our "market penetration" will be forever
miserable if we always represent such a steep wall to be scaled.

Customize is good, but I would really like to see...

- A set of functions named things like gnus-init-very-first-time,
  gnus-init-mail, gnus-init-topics.  And then have Gnus use these
  functions based on obvious criteria.  For example, the lack of any
  .gnus would be a firm indicator of a need for gnus-init-first-time,
  where the user would be queried for the name of his NNTP server, set
  up authinfo if needed, and perhaps be asked if there are any groups
  he'd like to see immediately subscribed.  Maybe bring up an explanatory
  buffer to sit alongside *Group* to explain server mode, so as to find
  other groups to subscribe.  Make some of these "init" functions into
  toolbar buttons, such as for setting up mail for the very first time.

- Generally, lots of interactive help in setting up mail.  We get lots
  and lots of questions in gnu.emacs.gnus about the umpteen thousand
  ways to suffer through mail configuration.  It should never be this
  hard, and Outlook and Netscape Messenger users have it so easy.
  Conceptually, mail configuration _is_ easy: Pick sources, perhaps
  pick servers + names + passwords, set variables to indicate those
  things.  Joe Luser shouldn't have to invoke setq himself.  We should
  pick one backend as "the standard luser mail backend" and conform
  Joe Luser to that.

- 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*.

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

- 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.

- ...other stuff of this sort...

Finding a way to overcome the luser barrier interests me most.
Unfortunately, it's precisely the sort of topic that might not garner
the interest of the cognoscenti, generally, specifically because we're
not the lusers that such effort would help.

Related question: It should be possible to customize custom-file in a
buffer-local way, yes?  That is, assuming Joe Luser wants to use one
Emacs for both ordinary editing work as well as Gnus, if he uses
customize for normal stuff, he wants the customizations to end up in
.emacs, but if he customizes Gnus stuff, it should land in .gnus.
Regardless of any luser-proofing, we should ensure that customize does
the Right Thing from within Gnus.

--karl