Re: IMAP server side search integration
On Sunday, 11 September 2005 at 16:02, Patrick Welche wrote:
> On Mon, Sep 05, 2005 at 10:51:03AM -0700, Brendan Cully wrote:
> > On Monday, 05 September 2005 at 19:06, Oswald Buddenhagen wrote:
> > > On Mon, Sep 05, 2005 at 09:31:00AM -0700, Brendan Cully wrote:
> > > > This patch adds a '$' modifier to the pattern language that turns
> > > > regexp searches into simple string matches.
> > > >
> > > > Examples:
> > > > ~b mutt: client regexp match
> > > >
> > > i for one would change the ~ to = instead of prepending $ - less to type
> > > and more intuitive (to somebody with perl knowledge ;).
> >
> > Good idea. It gets rid of the nasty nested modifier semantics
> > too. Here's a patch that adds a = operator, identical to ~ but
> > produces a string match instead of a regexp match. It still does an
> > implicit string match if the regexp contains no metacharacters.
>
> I just wonder about:
>
> + /* If there are no RE metacharacters, use simple search anyway */
> + if (!pat->stringmatch && !strpbrk (buf.data, "|[{.*+?^$"))
> + pat->stringmatch = 1;
>
> I don't think the '|' character impiles RE does it? There is an "OR" key
> in the imap search command to which it will map - ah I see.. One would
> then need to alter the pattern to s/|/ OR / ..
First of all, that code is turned off in the patch that went in - we
never automatically fall back to string match now, since = is just as
easy to use as ~. Second, that code is where simple subexpressions are
compiled, so the OR that you're thinking of will already have been
handled.
Consider ~f foo | ~s bar: the regular expressions are being executed
on different fields, so mutt needs two separate regular expressions,
neither of which will have | in them. On the other hand, ~f 'foo|bar'
will.