Re: [nimh-dev] TODO

[Joel Uckelman <uckelman@xxxxxxxxx>]

Thus spake "Jon Stewart":
> > 1. Make a TODO file.
> 
> Are you guys interested in using a bug/issue-tracking system (e.g. 
> Bugzilla, scarab)?

Maybe. I'm familiar with Bugzilla from reporting bugs myself. How
hard is it to set up? I guess we could have a sepearate category
for each command, plus the library.
 
> > 3. Decide what to do about mh-format: keep? toss?
> >   If toss:
> >     Maybe we want to define, e.g., a 'scanformatproc' key, which just
> >     feeds the raw data to some program, which then hands its output back to
> >     scan. That way, I could write my scan format in python or sed or perl o
> r
> >     cat it from /dev/random, and I could make it as (un)readable as I choos
> e.
> >   Maybe mhlib should understand mh-formats too?
> 
> 
> I think mh-format is baroquen. I like the idea of calling an external 
> program, if specified, or calling a specified python module (then you have 
> access to the object model, which is cool). If not, things like scan 
> should perform the default behavior themselves. Maybe at some point we can 
> attract an old mh hand to write a parser/converter, but I don't have much 
> invested in their weird-ass formatting language and I'd prefer not to have 
> to understand it.

Maybe that means I just nominated myself to write the mh-format -> python
code translator. Actually, MH comes with something like that, sort of.
Run /usr/lib/nmh/fmtdump, and check out what it gives you as output.
 
> Besides, the de-coupled approach is more powerful. You could write a 
> webmail backend using it, or half of a GUI.

Half-a-GUI: Dialogs have buttons which say 'O' and 'Can'.

_______________________________________________
nimh-dev mailing list
nimh-dev@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/nimh-dev