Re: mail regex

[Alain Magloire]

> 
> Bonsoir!

allo!

> 
> Sorry, last few days I've been absent and was unable to take part in the
> discussion.
> 
> I agree with Alain's point that using Mutt search syntax hardly matches
> mail/mailx way of specifying message sets. I think that any new features
> we are adding should follow the mail's idea of doing things. I'd propose
> to extend the message set specification in the following way (using
> summary table provided by Alain):
> 
>     Ref                 Meaning
>     ---------------------------------------------------------------------
>     n                   Message number n
>     n-m                 Messages n through m
>     .                   The current message
>     ^                   The first undeleted message
>                         (or first deleted message for undelete)
>     $                   The last message
>     *                   All messages
>     +                   Next message
>     -                   Previous message
>     user                All messages from the given user
>     /string             All messages with string in the subject line
>                         (the case of characters in string is ignored)
> *   header:/regex/      All messages whose header: contents matches regex
>                       (case insensitive). "header" is corresponding
>                       header name in lowercase.
> *   Header:/regex/      All messages whose header: contents matches regex
>                         (case sensitive). "Header" is corresponding
>                       header name, capitalized.
> *   body:/regex/      All messages whose body matches regex
>                       (case insensitive).
>     :d                  All deleted messages
>     :n                  All new messages
>     :o                  All old messages
>     :r                  All messages that have already been read
>     :u                  All unread messages
> 
> *   :on DATE          All messages sent on DATE
> *   :since DATE         All messages sent after DATE
> 
> (* marks proposed extensions.) This table does not include already implemented
> extensions (n[P] meaning part number P of the nth message, etc.).
> Comments?
> 
> I have already implemented header: and Header: semantics and am ready to
> commit the changes.

How do you make a distinction between "header:" and "body:"?

Subject:/grep/  --> (case sensitive) search for msgs with "grep" in the
                    Subject header.
subject:/grep/  --> (case insensitive) search for msgs with "grep" in the
                    Subject header.

/grep           -->  a special case for "subject:/grep/"

body:/grep/     --> how to make the distinction between "body" the keyword
                    and "body" a header field?

Are you assuming "body" will never be use as a header fieldname?

> 
> By the way, this reminds me of the necessity to have a generalized search
> API in the library. It could have various front ends, allowing to parse
> mail, mutt, imap4d, etc. message specifications, and returning msgset_t
> array. This way it could be used in all parts of mailutils.


100% in agreement, will send you mail on this later.

> > Mailx is archaic i.e. it's not a `visual' mail browser and there is
> > a danger in extending too much it's capabilities.
> 
> Sure, but it also has its "ecological niche", hasn't it? For example, when
> working over a slow modem line, one would surely prefer to run mail instead
> of a full-screen mail browser, provided that mail offers enough features
> to comfortably handle one's mail (that's what I am doing when I happen to
> be far from my console, by the way :^)

Yes, I agree.  I wanted to raise a flag to go easy on the features, it is very
tempting to add more and more,  but IMHO, mailx was not design for such goals.

> > There is an effort call `hydrant', wich is yet another mail browser, that
> > Jeff wanted to start.  The interesting thing about hydrant is that it
> > will rely on mailutils/mailbox to provide much of the functionnality.
> 
> This is really very interesting. The full-screen mail browser seems to be
> the only application the project lacks this far. 

8-) YAMB(Yet Another Mail Browser).  
Jeff B. started this and I wanted a mail browser to put the lib
(mailutils/mailbox{,2}) under stress, trying to get mutt/pine/elm/etc ...
to use mailutils underneath was a pain, they were too much tied to the
backend.

In theory ... libmailbox should have all the necessary pieces to
make life easy. But writing an application to interact with users is
a real pain.