From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57430 Path: main.gmane.org!not-for-mail From: "Ted Zlatanov" Newsgroups: gmane.emacs.gnus.general Subject: Re: Wizards! I mean, Assistants! Date: 17 May 2004 14:52:21 -0400 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4nzn86honu.fsf@lifelogs.com> References: <4nd653nm2i.fsf@lifelogs.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084820987 2320 80.91.224.253 (17 May 2004 19:09:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 19:09:47 +0000 (UTC) Original-X-From: ding-owner+M5970@lists.math.uh.edu Mon May 17 21:09:31 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BPnUR-0005NL-00 for ; Mon, 17 May 2004 21:09:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BPnTw-0005lE-00; Mon, 17 May 2004 14:09:00 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BPnTo-0005l8-00 for ding@lists.math.uh.edu; Mon, 17 May 2004 14:08:52 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BPnTl-00030K-Ny for ding@lists.math.uh.edu; Mon, 17 May 2004 14:08:49 -0500 Original-Received: from mail.bwh.harvard.edu (sysblade0.bwh.harvard.edu [134.174.9.44]) by justine.libertine.org (Postfix) with ESMTP id F40FF3A005E for ; Mon, 17 May 2004 14:08:43 -0500 (CDT) Original-Received: (qmail 9249 invoked from network); 17 May 2004 19:03:13 -0000 Envelope-Sender: tzz@lifelogs.com Envelope-Recipients: ding@gnus.org, Original-Received: from asimov.bwh.harvard.edu (HELO asimov) ([134.174.9.63]) (envelope-sender ) by mail.bwh.harvard.edu (qmail-ldap-1.03) with SMTP for ; 17 May 2004 19:03:12 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 17 May 2004 19:05:02 +0200") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57430 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57430 On Mon, 17 May 2004, larsi@gnus.org wrote: > "Ted Zlatanov" 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 -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