Re: Wizards! I mean, Assistants!

["Ted Zlatanov" <tzz@lifelogs.com>]

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