Re: Wizards (was: Re: Oort Version)

[Karl Kleinpaste <karl@charcoal.com>]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 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.

Do you still have the code?  It would be worth looking at today.  Rot
can be cut out.

>> - Prepackaged, selectable nnmail-split-rules entries to do "obvious"

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

Do you mean by using a long (contorted?) list of alternate selectors?
That could get really hairy, I would think.  But it would be good for
a first pass.

> A problem is that BBDB is FSF code, which makes it problematic to
( s/is/isn't/ ?)
> 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.

So let's provide BBDB auto-graft iff we detect that BBDB is
available.  Can "require" be wrapped inside "ignore-errors"?

  (if (ignore-errors (require 'bbdb))
     ( ... do whatever it takes to be able to auto-graft on request ... ))

I don't know if this is the right elisp idiom for such a purpose, but
my goal is to try to pull in BBDB, and if it succeeds ("ignore-errors"
returns nil if its contained forms fail; and I assume "require"
returns something other than nil when it successfully finds the
feature or loads the file), then make Gnus available for graft assist.

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

I wish I had any experience using VM, but I've never once invoked it
except by accident.

> Splitting the file for automatic customization further adds
> complexity without any measurable benefits.

Having thought it through a bit more, I agree with you.  But how does
this interact with users who run >1 simultaneous Emacs?

Start an Emacs, run Gnus in it.
Start 2nd Emacs.
Customize Gnus in 1st Emacs.
Exit Gnus from 1st Emacs.
Start Gnus in 2nd Emacs.

The advantage of .gnus is that it is loaded with every start of Gnus.
If we bury customizations in the usual auto-customize file, fresh
invocations of Gnus in a new Emacs don't get needed stuff picked up,
and induce another nightmare for the confused new user.