bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mailutils new competitor


From: Alain Magloire
Subject: Re: Mailutils new competitor
Date: Sun, 18 Feb 2001 15:59:02 -0500 (EST)

> 
> On Sun, Feb 18, 2001 at 01:38:47AM -0500, Alain Magloire wrote:
> 
> > > > I'm just musing, is there really a problem to be solved?
> > > 
> > > The problem is that with the mailutils API being a moving target, it's 
> > > quite hard to keep the documentation up to date.  I'm having alot of 
> > > trouble figuring out which functions to code to.  If the documentation 
> > 
> > 8-)
> > So did you decide on which language hydrant will be code in ?
> > Last it was C++, which is the one I would advocate for.
> > If you come up with a plan, I maybe able to help.
> 
> Still C++.  I've been reading my C++ books to figure out what's the best 
> wrapper to put around mailutils.

Good.  I'd say at one point in time we could have a mailutils++
With a full implementation base on the experience acquire with the C version.

> I'm hoping to post something soon with 
> what I think.  I haven't looked at mailutils src code in a long time.

Well, don't, you will get biais.  Rather go with a fresh mind and see
what sort of components/object you need to make a __program__ work cleanly.
mailutils/mailbox was a different approach rather a set of components
to make an easy and transparent API across protocols :

- folder_t # container for mailboxes
|---* mailbox_t # container for messages
    +---* message_t
        +---|-envelope_t
            |- header_t
            |- body_t

> > > were trivial to update (like it is with Javadoc) to add comments, the 
> > > Alain has said he will use it. =)
> > 
> > I'm ready to make the effort, but my experience tells me you will
> > have a hard time converting the non-believers.  Unless the tool
> > is really good and can generate really really, I mean really good doc.
> 
> Do you have a sample of "really good doc" that I can see?  that would 
> help me focus my thoughts.

grep ;-) simple under 20 pages and to the point.
awk, bison, flex, make, autoconf, recode, ..
The FSF/GNU and the maintainers came up with some very nice material.

But those are programs,  for library ... 
I can think of the old regex manual (ftp://ftp.gnu.org/gnu/regex)
readline, glibc(too big).

> > Ok OT, got grep-2.5c beta out cool !!
> 
> Excellent!  I haven't looked, is there a command line switch yet to make 
> it *always* display the file name
# grep --help 
....
  -H, --with-filename       print the filename for each match 

> (and maybe another one to only display 
> the filename for find lists)?

# grep --help
...
  -L, --files-without-match only print FILE names containing no match
  -l, --files-with-matches  only print FILE names containing matches

> I forget half the time to add the 
> /dev/null to:  find . -name \* -exec grep foo '{}' /dev/null \;

This is no longer necessary

# grep --recurse -H foo .
or
# grep --recurse -H foo *

> > PS: Can you drop it on alpha ;-)
> 
> Done.

Thanks!

> I haven't set you up because it's just as easy to get you onto Oasis.  

Ok I'll phone during the week.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]