Wizards! I mean, Assistants!

Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

No, still no code.

And I forgotten what conclusion (if any) we reached last time around.

So, here's some thoughts, again.

We want Gnus to be easy to set up for newbies.  So when you start
Gnus for the first time, you'd ideally be guided through some easy
steps to get up and running.

As a trivial example, Gnus would look around at the normal variables,
ask if this is the right NNTP server to connect to, and if not,
what's the address of the server; then it would check that the server
exists and you can connect to it, and if not, it would say so.  If
everything's OK, it'd write these customizations to file and let you
carry on with reading news.

(We could imagine many similar, more complex wizards.  (I don't
really like that word, though.  "Assistant"?)  Setting up mail, spam
filtering, scoring...  Stuff that you can't do through M-x customize,
because it's kinda interactive.  You query the user, look if the
response is reasonable, set stuff up.

There are two areas of difficulty here:

1) Specifying these Assistants.  If it's boring to write them, and
   they're difficult to maintain, that'd suck.  And they'd not get
   written.

2) Rendering the Assistants.  If they aren't pleasant to use, then
   that'd suck.

For 2) I'd originally though "just use W3", but it might not be the
best fit.  It's too...  free, in a way.  We want to guide the user.
Sternly.  So perhaps a simpler renderer has to be written.  Or
several.  There could be one buffer-based renderer, and one
Gtk-based, etc.

I'll just do the buffer-based one, though.

For 1), I don't really have a clue.  The specification language has
to be easy to read and write, and will be a mix of code and text.

I'll just type a bit and see if my fingers invent something usable:

---------------
<page 1>
(!valid
(let ((stream
        (condition-case err
           (open-network-stream "nntpd" nil server port)
          (error (setq error err)))))
   (if (memq (process-status stream) '(open run))
       (progn
         (delete-process stream)
         t)
     nil)))
(!result (gnus-select-method (list server port)))
So you want to read news.  The news server to use
is (?server (gnus-getenv-nntpserver));
port number (?port 119).
</page>
---------------

Er, that wasn't all that pleasant to write.  The idea was that
(?server) sets a variable that defaults to the argument, and then the
user can edit the value.  And the (!valid) thing is run when the user
presses the "next" button, and does input validation.  In this case,
it checks whether you can connect to the server, and if not, it'll
display the error message.  If it validates, the (!result) is that
you get a gnus-select-method set.

Hm.  Brainstorm, please.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

> (I don't really like that word, though.  "Assistant"?)

I think "saints" was proposed last time, but I don't recall if people
liked it.  

Another idea is to spin something off the swedish word (but surely also part of
most scandinavian languages) "(hus-)tomte" which are small creatures that help
people do things, like milk a cow and other everyday matters.  I don't know
an english word for it, though.  Except for the obvious "santa claus" (which
probably has too many other connotations to be useful), my dictionary only
propose "brownie".  Do people associate "brownie" with anything but cookies?

But, surely a specification-language for this must exist?  How do you write a
wizard under Windows, or GTK?  I really hope people aren't designing those
widget by widget.

Of course, it would be nice if it was generic, so other Emacs packages
can use it.

Err.  Only diversion and no code from me, sorry.

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> I think "saints" was proposed last time, but I don't recall if people
> liked it.  

It has kinda religious connotations...

> Another idea is to spin something off the swedish word (but surely
> also part of most scandinavian languages) "(hus-)tomte" which are
> small creatures that help people do things, like milk a cow and
> other everyday matters.  I don't know an english word for it,
> though.

"Troll".  :-)  Or leprechaun. 

> But, surely a specification-language for this must exist?  How do
> you write a wizard under Windows, or GTK?  I really hope people
> aren't designing those widget by widget.

Good question.  Anybody know?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Frank Schmitt]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Another idea is to spin something off the swedish word (but surely
>> also part of most scandinavian languages) "(hus-)tomte" which are
>> small creatures that help people do things, like milk a cow and
>> other everyday matters.  I don't know an english word for it,
>> though.
>
> "Troll".  :-)  Or leprechaun. 

Both have some negative meanings in common games :-)

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Wizards! I mean, Assistants!

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I think "saints" was proposed last time, but I don't recall if people
>> liked it.  
>
> It has kinda religious connotations...

Maybe it is my religious background speaking (see my Organization
header), but I *like* the connotations.

Also: <http://www.stallman.org/saint.html>

Re: Wizards! I mean, Assistants!

[Adam Sjøgren]

On Sun, 16 May 2004 17:24:03 +0200, Lars wrote:

>> "(hus-)tomte" which are small creatures that help people do things,
>> like milk a cow and other everyday matters. I don't know an english
>> word for it, though.

> "Troll". :-) Or leprechaun.

Perhaps "pixie"?


  :-),

-- 
 "We've reached a special place... Spiritually...             Adam Sjøgren
  ecumenically... grammatically."                        asjo@koldfront.dk

Re: Wizards! I mean, Assistants!

[Per Abrahamsen]

Instead of implementing saints when I got home, I watched a couple of
episodes of Scrubs.  So now I want the saints to be called "drcox" and
be incredible rude, call user by girl names (unless they are female,
in which case it should refer to them as "Barbie"), but ultimately
helpful.

...

Slightly more serious, it would be kind of fun if one could implement
different personalities for the saints.

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Slightly more serious, it would be kind of fun if one could implement
> different personalities for the saints.

:-)

If we keep the textual parts kinda separate, that should be pretty
easy to implement...

<text personality=nasty>
</text>

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> If we keep the textual parts kinda separate, that should be pretty
> easy to implement...
>
> <text personality=nasty>
> </text>

I don't think anything else but the "base personality" should be in
the main specification.  It would probably be something often done by
third parties.

(saint-personality-page 'gnus-server 'drcox
   "What is this whining noise?  Why won't it go away?  Oh, it you
Barbie.  We need to find a news server willing to put up with the the
noise, so you won't bother me anymore.  Now find the papers you got
from the Internet provider you signed up with.  Can you do that?  Good
girl.  Now what name does it specify for \"news server\"?  Or NNTP
host?")

saint-personality-page PAGE PERSONALITY TEXT

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I don't think anything else but the "base personality" should be in
> the main specification.  It would probably be something often done by
> third parties.

Perhaps, but how would these personalities be distributed?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps, but how would these personalities be distributed?

Good point.  Those who can install Lisp code probably won't need
saints.  Still, it would simplify independent development if someone
could submit a gnus-drcox.el file here.

Re: Wizards! I mean, Assistants!

[Jesper Harder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Instead of implementing saints when I got home, I watched a couple of
> episodes of Scrubs.  So now I want the saints to be called "drcox" and
> be incredible rude, call user by girl names (unless they are female,
> in which case it should refer to them as "Barbie"), but ultimately
> helpful.

Ah, you just gave me an excuse to watch the late-night rerun and
classify it as »important usablitity research«.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Wizards! I mean, Assistants!

[Jonas Steverud]

Simon Josefsson <jas@extundo.com> writes:

> Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> (I don't really like that word, though.  "Assistant"?)
>
> I think "saints" was proposed last time, but I don't recall if people
> liked it.  

Considering that this is for new users that might be new to Emacs as
well, I don't think it is a wise decision to invent a new word for an
old concept. There are plenty of places to confuse the newbie without
having to confront them with unknown words. Besides, the user will
mostly become angry - "if this is x, why the #@% don't they call it x
then?!" The user know what to expect if he is presented with "This
Assistant will guide you through the configuration process", but might
more easily be confused if it is "This gnome..." or "This daisy..." or
"This elf..." It never pays of to be witty when to find names for
concepts that will live much longer then any laughter.

Two other "cases in point:" I think Wizard is trademarked by
you-know-who (I remember seeing some information about some discussion
about the topic for about five years ago... you get the
picture). Apple calls 'em Assistants in Mac OS X and yes, they might
have trademarked that as well - worth checking out.

These dialogs doesn't do any magic, so lets not call 'em Wizards.
It sounds too much PR/Marketing Management to me. Assistants are much
better.

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Wizards! I mean, Assistants!

[Paul Jarc]

Jonas Steverud <tvrud@bredband.net> wrote:
> Apple calls 'em Assistants in Mac OS X and yes, they might have
> trademarked that as well - worth checking out.

Oracle uses the same word, so I doubt it's trademarked.


paul

Re: Wizards! I mean, Assistants!

[Jonas Steverud]

prj@po.cwru.edu (Paul Jarc) writes:

> Jonas Steverud <tvrud@bredband.net> wrote:
>> Apple calls 'em Assistants in Mac OS X and yes, they might have
>> trademarked that as well - worth checking out.
>
> Oracle uses the same word, so I doubt it's trademarked.

That's good.

And I heartfully agree with Miles Bader.

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Wizards! I mean, Assistants!

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> > (I don't really like that word, though.  "Assistant"?)
> 
> I think "saints" was proposed last time, but I don't recall if people
> liked it.  

What's wrong with "assistant" anyway?  Sure it's a bit boring, but it's
damn clear (much more so than "wizard")... and I'd think for the people
that need such things, clear is good.

"Assistants" also has a slightly less obvious advantage:  whereas a word
like "wizard" (or saint) might give the impression that it can magically
figure out and solve all your problems (which they can't -- lets face
it, such things are actually pretty stupid), assistant is realistic, and
says something more like "well, I'll try my best to help you."

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Wizards! I mean, Assistants!

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> > (I don't really like that word, though.  "Assistant"?)
> 
> I think "saints" was proposed last time, but I don't recall if people
> liked it.  

What's wrong with "assistant" anyway?  Sure it's a bit boring, but it's
damn clear (much more so than "wizard")... and I'd think for the people
that need such things, clear is good.

"Assistants" also has a slightly less obvious advantage:  whereas a word
like "wizard" (or saint) might give the impression that it can magically
figure out and solve all your problems (which they can't -- lets face
it, such things are actually pretty stupid), assistant is realistic, and
says something more like "well, I'll try my best to help you."

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> "Assistants" also has a slightly less obvious advantage:  whereas a word
> like "wizard" (or saint) might give the impression that it can magically
> figure out and solve all your problems (which they can't -- lets face
> it, such things are actually pretty stupid), assistant is realistic, and
> says something more like "well, I'll try my best to help you."

We could give the assistant a groovy name.  Perhaps "Clippit". 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Steven E. Harris]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> X-Now-Playing: Cabaret Voltaire's _Western Re-Works 1992_:
>                "Just Fascination"

I was just listening to this on the way to work the other day. The
receipt in the cassette tape is from 12 July 1992. It still sounds
fresh.

-- 
Steven E. Harris

Re: Wizards! I mean, Assistants!

[Ian Fitchet]

Simon Josefsson <jas@extundo.com> writes:

> an english word for it, though.  Except for the obvious "santa claus" (which

 Santa Claus has little elves to help him...

Cheers,

        Ian

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Ian Fitchet <idf@lunanbay.LESS-SPAM.com> writes:

>> an english word for it, though.  Except for the obvious "santa claus" (which
>
>  Santa Claus has little elves to help him...

Hm.  Setup Elf.  Or Setup Fairy.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Lloyd Zusman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ian Fitchet <idf@lunanbay.LESS-SPAM.com> writes:
>
>>> an english word for it, though.  Except for the obvious "santa
>>> claus" (which
>>
>>  Santa Claus has little elves to help him...
>
> Hm.  Setup Elf.  Or Setup Fairy.

Setup Gnu?



-- 
 Lloyd Zusman
 ljz@asfast.com
 God bless you.

Re: Wizards! I mean, Assistants!

[luis fernandes]

    larsi> Hm.  Setup Elf.  Or Setup Fairy.

"Assistant" is fine, actually, but she needs a name-- I suggest
"Tolva". See the following comic for an explanation:

http://www.ee.ryerson.ca/~elf/reeality/strips/reeality63.jpg

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

luis fernandes <elf@ee.ryerson.ca> writes:

> "Assistant" is fine, actually, but she needs a name-- I suggest
> "Tolva". See the following comic for an explanation:
>
> http://www.ee.ryerson.ca/~elf/reeality/strips/reeality63.jpg

:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

I'm now writing the assistant parser and renderer.  I've decided to
not rely on texinfo.el, since that's a kinda complicated parser that
doesn't seem very amenable to library usage.  (That is, it's totally
geared towards transforming TeXinfo into info.)

The pseudo-TeXinfo that's in the assistants is easy enough to parse,
so I've just written a new one.

The @next section will have to be written as Ted described them, I
think.

So they're now

@next (string= type "pop") "Setting up a POP client"

That is, first a test that's evaled, and then the node name.  If no
tests match, then "next" will be "Finish", which will save the data. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The pseudo-TeXinfo that's in the assistants is easy enough to parse,
> so I've just written a new one.

And it now parses and renders (very, very simply) the simple nntp
server setup assistant.  To try it, do something like:

(assistant "~/gnus/etc/gnus/news-server.ast")

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> (assistant "~/gnus/etc/gnus/news-server.ast")

Does it support @ignore/@end ignore?

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> Does it support @ignore/@end ignore?

In that it ignores all the tags it doesn't understand; yes.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Does it support @ignore/@end ignore?
>
> In that it ignores all the tags it doesn't understand; yes.  :-)

But the crucial thing about @ignore is that you can't ignore it... :-}

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> But the crucial thing about @ignore is that you can't ignore it... :-}

Well, true.  The assistant.el parser doesn't ignore @ignore, but it
doesn't use it, either, so it kinda works.

It doesn't allow nested @ignores, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Well, true.  The assistant.el parser doesn't ignore @ignore, but it
> doesn't use it, either, so it kinda works.

Does it ignore the text in between though?

@ignore
    You big fat slob!  Get your ass in gear and edit your .emacs file
    like real man!  Yeah, you can't deal with more than two buttons at a
    time, huh?  Luser, luser, luser, luser, luser, luser, luser, luser.
@end ignore

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> Does it ignore the text in between though?

Sure.

> @ignore
>     You big fat slob!  Get your ass in gear and edit your .emacs file
>     like real man!  Yeah, you can't deal with more than two buttons at a
>     time, huh?  Luser, luser, luser, luser, luser, luser, luser, luser.
> @end ignore

I'm certainly ignoring that.  Just look!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Anyway, the assistant now works.  Even though it doesn't actually set
anything.

So now I just need a more complex assistant to play with.  Not that
I'm impatient or anything.  Nooo.

Why doesn't TAB tab to the widget, though?  That seems kinda odd.  It
does tab to the button, but not to the editable-field...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Anyway, the assistant now works.  Even though it doesn't actually set
> anything.
>
> So now I just need a more complex assistant to play with.  Not that
> I'm impatient or anything.  Nooo.
>
> Why doesn't TAB tab to the widget, though?  That seems kinda odd.  It
> does tab to the button, but not to the editable-field...

It is a bug.  It cannot find zero-width text fields.  Put some text in
it, at tab will find it.

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> It is a bug.  It cannot find zero-width text fields.  Put some text in
> it, at tab will find it.

I just use

	 (widget-create
	  'editable-field
          "Here's some text")

And that widget isn't found by TAB...          

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Man, writing these assistants is just plain difficult.  There's so
many choices and stuff...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Man, writing these assistants is just plain difficult.  There's so
> many choices and stuff...

Phew.  I think I've now kinda completed the new server setup.

(assistant "~/pgnus/etc/gnus/news-server.ast")

It's not complete, because it doesn't really check whether a user
name/password is necessary...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
>> It is a bug.  It cannot find zero-width text fields.  Put some text in
>> it, at tab will find it.
>
> I just use
>
> 	 (widget-create
> 	  'editable-field
>           "Here's some text")
>
> And that widget isn't found by TAB...          

What is tab bound to?

If I do 

(progn (widget-create 'editable-field "Here's some text")
       (widget-setup))

in the *scratch* buffer, and type M-x widget-forward <ret>, then point
move to the beginning of the text field.

Re: Wizards! I mean, Assistants!

[Steinar Bang]

>>>>> luis fernandes <elf@ee.ryerson.ca>:

larsi> Hm.  Setup Elf.  Or Setup Fairy.

> "Assistant" is fine, actually, but she needs a name-- I suggest
> "Tolva". See the following comic for an explanation:

> http://www.ee.ryerson.ca/~elf/reeality/strips/reeality63.jpg

According to the strip, that would be "Tölva" rather than "Tolva" (ö
and o aren't the same sound).

Re: Wizards! I mean, Assistants!

[Simon Josefsson]

> Simon Josefsson <jas@extundo.com> writes:
>
>> Another idea is to spin something off the swedish word (but surely
>> also part of most scandinavian languages) "(hus-)tomte" which are
>> small creatures that help people do things, like milk a cow and other
>> everyday matters.  I don't know an english word for it, though.
>
> I believe house-gnome is the most common translation.  I don't think
> that would work that well though, it's somewhat taken in software
> circles.

Ah, of course, silly me.

I do agree with someone who said that introducing a new term for this is
confusing.

OTOH, existing Wizards in Windows are often quite unwizardlike, so I'm not
sure mimicking them too closely is what users would appreciate.  I guess
I'm hoping the Gnus Wizard would be radically different, and better, to
justify a new term.

Re: Wizards! I mean, Assistants!

[Ted Zlatanov]

On Sun, 16 May 2004, larsi@gnus.org wrote:

> There are two areas of difficulty here:
> 
> 1) Specifying these Assistants.  If it's boring to write them, and
>    they're difficult to maintain, that'd suck.  And they'd not get
>    written.

I think this is the important part right now.

> 2) Rendering the Assistants.  If they aren't pleasant to use, then
>    that'd suck.

I agree, but I think this should come once (1) is done.  Perhaps a
very simple q&a renderer (nothing but minibuffer queries) should be
the first step for testing.

> <page 1>
> (!valid
> (let ((stream
>         (condition-case err
>            (open-network-stream "nntpd" nil server port)
>           (error (setq error err)))))
>    (if (memq (process-status stream) '(open run))
>        (progn
>          (delete-process stream)
>          t)
>      nil)))
> (!result (gnus-select-method (list server port)))
> So you want to read news.  The news server to use
> is (?server (gnus-getenv-nntpserver));
> port number (?port 119).
> </page>

There should be distinct sections for expected variables,
initialization, validation, resetting, and undo (going back).  They
won't always be used, but the ability should be there.  This is how I
would do it (to be parsed by ELisp):

(assistant-pages
 (assistant 'nntp-server "NNTP server setup" 1 ; assistant name, title, page#
 '((produces '(server string) '(port integer))

  (initialize
   server (gnus-getenv-nntpserver)
   port 119)

  (reset 'redo-initialize)

  (undo 'redo-initialize)

  (validate 
   (server port) 'user-override [open-network-stream code goes here])

 So you want to read news.  The news server to use is `server'; port
 number `port'.
)))

The (produces) section is crucial.  It lets us specify the exact thing
this assistant will create, and further assistant pages can use these
variables also.

For validation, there should be a way to specify that the user can
override the validation or not; for instance the NNTP server may be
down but still it needs to be made active.

Just some ideas...

Ted

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> I agree, but I think this should come once (1) is done.  Perhaps a
> very simple q&a renderer (nothing but minibuffer queries) should be
> the first step for testing.

Yup.

> There should be distinct sections for expected variables,
> initialization, validation, resetting, and undo (going back).  They
> won't always be used, but the ability should be there.  This is how I
> would do it (to be parsed by ELisp):

But I don't want to repeat stuff more than I have to, so it should
use sensible defaults as often as possible.

> (assistant-pages
>  (assistant 'nntp-server "NNTP server setup" 1 ; assistant name, title, page#
>  '((produces '(server string) '(port integer))
>
>   (initialize
>    server (gnus-getenv-nntpserver)
>    port 119)
>
>   (reset 'redo-initialize)
>
>   (undo 'redo-initialize)
>
>   (validate 
>    (server port) 'user-override [open-network-stream code goes here])
>
>  So you want to read news.  The news server to use is `server'; port
>  number `port'.
> )))

I think one of the reasons that HTML is successful is that it's 1)
text-like, and 2) sloppy.  Matching parentheses around blocks of free
text (which may contain more parentheses) requires more rigor.  So I
think I'd go with something <tag>-like, but with Lisp sections.  I
think. 

> The (produces) section is crucial.  It lets us specify the exact thing
> this assistant will create, and further assistant pages can use these
> variables also.

Yes...  but in this example they mostly just repeat what's in the
text, so that section could default to those.

---
So you want to read news.  The news server to use is (? server string
(gnus-getenv-nntpserver))
---

Hm.  I think I like your version better.  :-)  But I think the
`produces' and `initialize' sections can be mushed together.

> For validation, there should be a way to specify that the user can
> override the validation or not; for instance the NNTP server may be
> down but still it needs to be made active.

That's true.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Ted Zlatanov]

On Mon, 17 May 2004, larsi@gnus.org wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> There should be distinct sections for expected variables,
>> initialization, validation, resetting, and undo (going back).  They
>> won't always be used, but the ability should be there.  This is how I
>> would do it (to be parsed by ELisp):
> 
> But I don't want to repeat stuff more than I have to, so it should
> use sensible defaults as often as possible.

Sure, so where I had reset and undo calling 'redo-intialize, that can
be the default.  It's a sensible default anyway.

>> (assistant-pages
>>  (assistant 'nntp-server "NNTP server setup" 1 ; assistant name, title, page#
>>  '((produces '(server string) '(port integer))
>>
>>   (initialize
>>    server (gnus-getenv-nntpserver)
>>    port 119)
>>
>>   (reset 'redo-initialize)
>>
>>   (undo 'redo-initialize)
>>
>>   (validate 
>>    (server port) 'user-override [open-network-stream code goes here])
>>
>>  So you want to read news.  The news server to use is `server'; port
>>  number `port'.
>> )))
> 
> I think one of the reasons that HTML is successful is that it's 1)
> text-like, and 2) sloppy.  Matching parentheses around blocks of free
> text (which may contain more parentheses) requires more rigor.  So I
> think I'd go with something <tag>-like, but with Lisp sections.  I
> think.

I'm OK with any text templating format, as long as it can accomodate
the fields we need.  I'm actually partial to the Template Toolkit for
Perl, but that's unlikely to be of interest to ELisp developers :)

For instance, above you have `server' - in the text renderer that
would be a pre-filled text field, not just the *contents* of the
server variable.  In other words, we're writing the content and the
interface at the same time.  I hope that came across.

>> The (produces) section is crucial.  It lets us specify the exact thing
>> this assistant will create, and further assistant pages can use these
>> variables also.
> 
> Yes...  but in this example they mostly just repeat what's in the
> text, so that section could default to those.

I think it's important to specify the type of variables before they
are used.  In other words, I don't want `server' to auto-default to a
string.  The template should either complain on unknown variables, or
just print `TEXT' when it's not a known variable.  There's several
reasons for this:

- we know what variables to expect before any template work is done

- text like `this' can be used inside the template (if we allow)

- validate can have default checks, e.g. that the port is really an
  integer, on top of the programmer-specified checks

- it's easier to interface with this templating system

> Hm.  I think I like your version better.  :-)  But I think the
> `produces' and `initialize' sections can be mushed together.

You're right.  Something like this maybe:

  (initialize
   server :string (gnus-getenv-nntpserver)
   port :integer 119)

Anyhow, if people want to give ideas for assistant sequences, I can
try to code them into this pseudo-language and see if it has
deficiencies based on real usage.  This will also give us an idea of
the things that users want to be assistant-enabled in Gnus.

Ted

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> Anyhow, if people want to give ideas for assistant sequences, I can
> try to code them into this pseudo-language and see if it has
> deficiencies based on real usage.  This will also give us an idea of
> the things that users want to be assistant-enabled in Gnus.

Set up Gnus for mail usage.  :-)

Let's see...  that's choosing which mail backend to use, and then
setting up the mail sources (file, pop, maildir) for incoming mail,
and configuring outgoing mail (using local sendmail or smtpmail.el).

I think setting up mail splitting would be something that's not
ideally suited for an assistant, because it's just one thing -- it's
not a process that you need guiding for.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Wizards! I mean, Assistants!

[Kai Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
>
>> Anyhow, if people want to give ideas for assistant sequences, I can
>> try to code them into this pseudo-language and see if it has
>> deficiencies based on real usage.  This will also give us an idea of
>> the things that users want to be assistant-enabled in Gnus.
>
> Set up Gnus for mail usage.  :-)

Set up spam handling...

Kai

Re: Wizards! I mean, Assistants!

[Ted Zlatanov]

On Tue, 18 May 2004, kgrossjo@eu.uu.net wrote:

>> "Ted Zlatanov" <tzz@lifelogs.com> writes:
>>
>>> Anyhow, if people want to give ideas for assistant sequences, I can
>>> try to code them into this pseudo-language and see if it has
>>> deficiencies based on real usage.  This will also give us an idea of
>>> the things that users want to be assistant-enabled in Gnus.
> 
> Set up spam handling...

You know, I thought of that, but was hoping no one would mention it :)

I think I'll try to write the mail setup script for Lars first, and
see how that goes.  But I will get to the spam handling setup
eventually.

Ted

new user assistant (was: Wizards! I mean, Assistants!)

[Ted Zlatanov]

@title Configuring Gnus for the first time
@node What do you want to do with Gnus?

;; defaults to nnml
@variable backends :'(set (const :tag "Read news via NNTP" nntp)
                          (const :tag "Read news via RSS" nnrss)
                          (const :tag "Read news from Slashdot" nnslashdot)
                          (const :tag "Manage TODO items" nntodo)
                          (const :tag "Read mail with nnml" nnml)
                          (const :tag "Read mail with nnmaildir" nnmaildir)
                          (const :tag "Read mail with nnimap" nnimap))
                    '(nnml)

;; defaults to sendmail
@variable outbound :'(choice (const :tag "Send mail via sendmail" sendmail)
                             (const :tag "Send mail via SMTP" smtp))
                   'sendmail

@result primary-mail-selections (list backends outbound)
@text
Welcome to Gnus.  You need to tell us what you want to do with Gnus
before we go on to specific configurations.

Choose the tasks you want to set up: @variable{backends}

Choose the method Gnus will use to send mail: @variable{outbound}
@end text

;; note that @next is a list, so we are building a tree starting at
;; this node - this is a very important piece of the format
;; I'm not worrying about the correctness of the backquoted macros,
;; this is just a demo of the "next node" syntax
@next `(,@(when (assq 'nnml backends) "Configuring the nnml backend")
        ,@(when (assq 'nntp backends) "Configuring the NNTP backend")
       [...]
        ,@(when (eq sendmail outbound) "Configuring sendmail")
        ,@(when (eq smtp outbound) "Configuring SMTP"))

What do you think about the format, before I write more?

Ted

Re: new user assistant

[Lars Magne Ingebrigtsen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> ;; defaults to nnml
> @variable backends :'(set (const :tag "Read news via NNTP" nntp)
>                           (const :tag "Read news via RSS" nnrss)
>                           (const :tag "Read news from Slashdot" nnslashdot)
>                           (const :tag "Manage TODO items" nntodo)
>                           (const :tag "Read mail with nnml" nnml)
>                           (const :tag "Read mail with nnmaildir" nnmaildir)
>                           (const :tag "Read mail with nnimap" nnimap))
>                     '(nnml)

[...]

> ;; note that @next is a list, so we are building a tree starting at
> ;; this node - this is a very important piece of the format
> ;; I'm not worrying about the correctness of the backquoted macros,
> ;; this is just a demo of the "next node" syntax
> @next `(,@(when (assq 'nnml backends) "Configuring the nnml backend")
>         ,@(when (assq 'nntp backends) "Configuring the NNTP backend")
>        [...]
>         ,@(when (eq sendmail outbound) "Configuring sendmail")
>         ,@(when (eq smtp outbound) "Configuring SMTP"))

I don't think you'll need macros -- these things will be funcalled,
anyway.  (That is, wrapped in `lambda' forms.  Or perhaps just evaled.

Anyway, I don't think there'll be just one assistant -- the menu will
have lots of them, so it's not necessary to start with "do you want
to set up news or mail?"  And that might make navigation easier.

So, if we just allow one element to branch, that could perhaps be
expressed more succinctly... 

@next nntp "Reading news from a news server"
@next nnspool "Reading news from the local spool"

Or something.  (Except that the last one wouldn't be an option,
because it's really rare that anybody would want to do nnspool.  :-)

> What do you think about the format, before I write more?

I think it's nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: new user assistant

[Ted Zlatanov]

On Tue, 18 May 2004, larsi@gnus.org wrote:

>> @next `(,@(when (assq 'nnml backends) "Configuring the nnml backend") ,@(when
>> 	(assq 'nntp backends) "Configuring the NNTP backend") [...]  ,@(when
>> 	(eq sendmail outbound) "Configuring sendmail") ,@(when (eq smtp
>> 	outbound) "Configuring SMTP"))
> 
> I don't think you'll need macros -- these things will be funcalled,
> anyway.  (That is, wrapped in `lambda' forms.  Or perhaps just evaled.

> So, if we just allow one element to branch, that could perhaps be
> expressed more succinctly... 
> 
> @next nntp "Reading news from a news server"
> @next nnspool "Reading news from the local spool"
> 
> Or something.  (Except that the last one wouldn't be an option,
> because it's really rare that anybody would want to do nnspool.  :-)

I'm sure there's a Real Programmers joke in there.

Anyhow, I would prefer more complex decisions for branching.  You
should at least be allowed to examine the variables produced by the
current node and branch conditionally, so you don't have to write
special code in the subsequent nodes.

Ted

Re: new user assistant

[Lars Magne Ingebrigtsen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> Anyhow, I would prefer more complex decisions for branching.  You
> should at least be allowed to examine the variables produced by the
> current node and branch conditionally, so you don't have to write
> special code in the subsequent nodes.

Yes, it should be possible to do that, but in most cases I think
the branches will be simple.  That is, if you choose pop mail, you
get one branch; if you choose maildir, that's another branch...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Gnus mail reading assistant (was: new user assistant)

[Ted Zlatanov]

Some more work on the mail setup assistant.  The syntax is nebulous
so I'm trying my best to make it do what we want.  It's not clear,
for example, what we should do when a nnml server is created - do we
create a new "mail" group?  Do we set up splitting?

For NNTP, do we ask for a username and password, or do we test the
server and see if they are needed, or is that too advanced for a
setup assistant?

Ted

@ifassistant

@title Configuring Gnus for the first time
@node What do you want to do with Gnus?

;; defaults to nnml
@variable backends :'(set (const :tag "Read news via NNTP" nntp)
                          (const :tag "Read news via RSS" nnrss)
                          (const :tag "Read news from Slashdot" nnslashdot)
                          (const :tag "Manage TODO items" nntodo)
                          (const :tag "Read mail with nnml" nnml)
                          (const :tag "Read mail with nnmaildir" nnmaildir)
                          (const :tag "Read mail with nnimap" nnimap))
                    '(nnml)

;; defaults to sendmail
@variable outbound :'(choice (const :tag "Send mail via sendmail" sendmail)
                             (const :tag "Send mail via SMTP" smtp)) 
                    'sendmail

@result primary-mail-selections (list backends outbound)
@text
Welcome to Gnus.  You need to tell us what you want to do with Gnus
before we go on to specific configurations.

Choose the tasks you want to set up: @variable{backends}

Choose the method Gnus will use to send mail: @variable{outbound}
@end text

;; this is like a cond, and multiples are allowed
@next (assq 'nnml backends) "Configuring the nnml backend"
@next (assq 'nntp backends) "Configuring the NNTP backend"
@next (eq sendmail outbound) "Configuring sendmail"
@next (eq smtp outbound) "Configuring SMTP"

@node "Configuring the nnml backend"

;; note that we don't need "@variable nnml-directory"

;; but we do need @result, so undo and reset know what to undo
@result nnml-directory

;; invented functions
@next-action '(gnus-server-add-server-direct 'nnml)

@undo-action '(gnus-server-remove-server-direct 'nnml)

@text

In order to use nnml, you need to specify a directory where your mail
will live: @variable{nnml-directory}

The default is usually fine.

@end text

@node "Configuring the NNTP backend"

;; defaults to nntp-address?
@variable server :string nntp-address

;; invented functions
@next-action '(gnus-server-add-server-direct 'nntp server)

@undo-action '(gnus-server-remove-server-direct 'nntp server)

@text

You need a NNTP server to read news via nntp: @variable{server}

@end text

@end ifassistant

Re: Gnus mail reading assistant

[Lars Magne Ingebrigtsen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> Some more work on the mail setup assistant.  The syntax is nebulous
> so I'm trying my best to make it do what we want.  It's not clear,
> for example, what we should do when a nnml server is created - do we
> create a new "mail" group?  Do we set up splitting?

Not splitting; no...

> For NNTP, do we ask for a username and password, or do we test the
> server and see if they are needed, or is that too advanced for a
> setup assistant?

Hm...  it should allow for specifying the user name and password, at
least, but connecting to the server and seeing if we get a user
name/password challenge would be really nice.

Let's see...

----------
@title Configuring Gnus for reading news


@node Setting up the news server name and port number
@variable server :string (gnus-getenv-nntpserver)
@variable port :number 119
@validate (assistant-validate-connect-to-server server port)
@result gnus-select-method (list server port)
@text
Usenet news is usually read from your Internet service prodider's news
server.  If you don't know the name of this server, contact your ISP.

As a guess, the name of the server might be news.yourisp.com.

The server name is @variable{server}; port number @variable{port}.
@end text
@next t "User name and password"


@node User name and password
@variable user-name :string (user-login-name)
@variable password :password (find-password-in-authinfo)
@validate "... lots of code ..."
@result ... er... put stuff in .authinfo, I guess
@text
Some news servers require that you enter a user name and
a password.

@if (password-required-p)
It looks like your news server is one of those.
@else
It doesn't look like your news server requires passwords.
@endif

User name: @variable{user-name}
Password: @variable{password}
@end text
------------


Hm.  The text to "markup" ratio is pretty small...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: new user assistant

[Dale Hagglund]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> @title Configuring Gnus for the first time
> @node What do you want to do with Gnus?
> ... interesting example follows ...

As a Gnus user, I doubt I'll do much *writing* of this syntax, but I
do like the way it looks.

However, if the assistant is meant to help novice users set things up,
it should noted that they're the ones who are completely ignorant of
the meanings of nnml versus nnmaildir versus nnimap, etc, so a simple
menu for the backends actually won't help them very much.

How would you write an assistant that tried to either (a) discover
what the user might want to do based on environment vars and other
pre-exisiting information, or (b) queried the user for such
information, and then presented him with a suitable (aye, there's the
rub) initial configuration?

Do you want this language to be able to handle the maintenance of
configurations or just the initial creation of such a configuration?
Ie, I have both nnml and nnimap mail groups in my gnus setup.  Suppose
I used an assistant to set up my first nnml group.  Would the language
you're thinking about support writing an assistant that would walk me
through adding a nnimap mailing group?

Dale.

(Regarding the XML debate: XML is a wonderful, or at least fully
adequate, syntax for data exchange between programs.  It is hopeless
as a human-input syntax.  The fact that people say "oh, its much
easier with an xml editor" is proof.)

Re: new user assistant

[Ted Zlatanov]

On Sat, 22 May 2004, rdh@yottayotta.com wrote:

> However, if the assistant is meant to help novice users set things up,
> it should noted that they're the ones who are completely ignorant of
> the meanings of nnml versus nnmaildir versus nnimap, etc, so a simple
> menu for the backends actually won't help them very much.

What would you suggest?  At some point, a minimal knowledge of the
desired mail storage is necessary, otherwise the user doesn't know
what to ask for, and we can't teach them how files and directories
work.

For example, nnml is a very bad storage choice for home directories
with small quotas - nnimap is much better in those cases.  nnmaildir
works better than nnml over NFS.

If you have ideas, you don't have to write code.  Write the text of
the assistant, and I or other Gnus developers can fill in the code.

> How would you write an assistant that tried to either (a) discover
> what the user might want to do based on environment vars and other
> pre-exisiting information, or (b) queried the user for such
> information, and then presented him with a suitable (aye, there's the
> rub) initial configuration?

That's impossible.  We can assist with tasks, but we can't make
guesses that are almost certainly wrong.  The number of possible
configurations and the ways in which they can be guessed wrongly is
much greater than what Gnus developers have time for, IMHO.

> Do you want this language to be able to handle the maintenance of
> configurations or just the initial creation of such a configuration?

Just creation for now!  It's hard enough to do an initial setup, I
don't want to spend time creating a configuration maintenance system
as well.

> Ie, I have both nnml and nnimap mail groups in my gnus setup.  Suppose
> I used an assistant to set up my first nnml group.  Would the language
> you're thinking about support writing an assistant that would walk me
> through adding a nnimap mailing group?

There could be an assistant that *adds* a nnimap group.  That's not
too bad.

Ted

Re: new user assistant

[Per Abrahamsen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> What would you suggest?  At some point, a minimal knowledge of the
> desired mail storage is necessary, otherwise the user doesn't know
> what to ask for, and we can't teach them how files and directories
> work.

The user who just type "Next" should get a nnml backend, as that is
the most "native" backend for Gnus.  At some point in the
installation, he should be asked

How should Gnus store your mail?

( ) Choose manually.
(*) Use the default method [nnml].

For most users, the default method [nnml] is adequate.  You can read
more about [Gnus backends] before making a choice.

[Previous]   [Cancel]   [Next]

Re: new user assistant

[Derrell.Lipman]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> The user who just type "Next" should get a nnml backend, as that is
> the most "native" backend for Gnus.  At some point in the
> installation, he should be asked
>
> How should Gnus store your mail?
>
> ( ) Choose manually.
> (*) Use the default method [nnml].
>
> For most users, the default method [nnml] is adequate.  You can read
> more about [Gnus backends] before making a choice.
>
> [Previous]   [Cancel]   [Next]

If you're going to provide a choice at this point, and a link to the further
documentation, then why add the extra page required by "Choose manually"?  Why
not replace "Choose manually" by the list of other backends?  Seems like less
coding for the programmer (no extra set of questions/answers), and less
clicking/tabbing for the user.  Selecting "Next" can still choose the default
nnml backend.

(I've been watching the progress on this assistant with interest, and smiling.
There's one very annoying, excessively prolific (on this and numerous other
mailing lists and news groups) poster who's been requesting (repeatedly, ad
nauseum, for the past many years) something like this assistant and has always
been rebuffed.  I guess maybe enough annoyment causes action. :-)

Cheers,

Derrell

Re: new user assistant

[Ted Zlatanov]

On Tue, 25 May 2004, Derrell.Lipman@unwireduniverse.com wrote:

> If you're going to provide a choice at this point, and a link to the further
> documentation, then why add the extra page required by "Choose manually"?  Why
> not replace "Choose manually" by the list of other backends?  Seems like less
> coding for the programmer (no extra set of questions/answers), and less
> clicking/tabbing for the user.  Selecting "Next" can still choose the default
> nnml backend.

That was my original design, and it's bad because it confuses the
user with too much technical lingo they don't care to learn.

I think nnimap should be a first-tier choice, because it is very
common among ISPs.  So nnml and nnimap should be the first-tier
choices (maybe nntp as well), and the other backends can be selected
on a separate screen.

Ted

Re: new user assistant

[Paul Jarc]

"Ted Zlatanov" <tzz@lifelogs.com> wrote:
> So nnml and nnimap should be the first-tier choices (maybe nntp as
> well),

Although Gnus thinks of mail and news as the same thing, I'm not sure
that users do.  It might make sense to split news into a separate
section, independent of the mail stuff.


paul

Re: new user assistant

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Although Gnus thinks of mail and news as the same thing, I'm not sure
> that users do.  It might make sense to split news into a separate
> section, independent of the mail stuff.

I always assumed the first setup page would look like 

| Do you want to setup Gnus for 
| 
| ( ) Mail
| (*) News
| ( ) Both

Re: new user assistant

[Paul Jarc]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> I always assumed the first setup page would look like
>
> | Do you want to setup Gnus for
> |
> | ( ) Mail
> | (*) News
> | ( ) Both

That would work, or maybe have a "News" step and a "Mail" step, and
give each of them a "skip" option.  Or make them separate assistants.
It would be nice if the assistants could add a new server/select
method even after some were already defined, so the user wouldn't have
to get through everything all at once.


paul

Re: new user assistant

[Per Abrahamsen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> That was my original design, and it's bad because it confuses the
> user with too much technical lingo they don't care to learn.

Yes, the typical user should go through the setup and be presented
with as little information as possible.  One could argue that is the
main point of assistants.

> I think nnimap should be a first-tier choice, because it is very
> common among ISPs.

If imap is common (my isp doesn't provide it), and the Gnus
implementation is robust, imap should be the prefered choice, simply
because it leave mail on the server.

There need to be a strong warning (now the user no longer has to
sacrifice a goat), that the other backends will move mail away from
the server.

Re: Wizards! I mean, Assistants!

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> For 2) I'd originally though "just use W3", but it might not be the
> best fit.  It's too...  free, in a way.  We want to guide the user.
> Sternly.  So perhaps a simpler renderer has to be written.  Or
> several.  There could be one buffer-based renderer, and one
> Gtk-based, etc.

The biggest problem is that w3 is not really maintained.  If we could
just find a suck... hero to take over maintenance, it would be
excellent.  It could also work as a specification language.  It
actually already has a few extra tags for that purpose.  Here is the
test (again) I wrote originally for that purpose:

  <http://www.dina.kvl.dk/~abraham/custom/gnus.html>

Anyway, I don't think brainstorming is what we need most.  What we
need would be for someone to do the boring work of implementing a
saint using existing capabilities, and then use the experience for
writing tools making the next saint easier to write.

Re: Wizards! I mean, Assistants!

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> The biggest problem is that w3 is not really maintained.  If we could
> just find a suck... hero to take over maintenance, it would be
> excellent.  It could also work as a specification language.  It
> actually already has a few extra tags for that purpose.  Here is the
> test (again) I wrote originally for that purpose:
>
>   <http://www.dina.kvl.dk/~abraham/custom/gnus.html>

Yes, it's pretty neat, but I think it's kinda underspecified...

> Anyway, I don't think brainstorming is what we need most.  What we
> need would be for someone to do the boring work of implementing a
> saint using existing capabilities, and then use the experience for
> writing tools making the next saint easier to write.

Definitely.  So I think I'll be going with a variant of what Ted
suggested.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen