unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Jani Nikula <jani@nikula.org>
To: Austin Clements <amdragon@MIT.EDU>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH 0/5] lib: make folder: prefix literal
Date: Sat, 01 Feb 2014 16:54:19 +0200	[thread overview]
Message-ID: <87fvo2yjc4.fsf@nikula.org> (raw)
In-Reply-To: <20140130220234.GI4375@mit.edu>

On Fri, 31 Jan 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> What if we introduce two prefixes, say folder: and path: (maybe dir:?)
> to address both use cases, each as naturally as possible?  Both would
> be boolean prefixes because of the limitations of probabilistic
> prefixes, but we could take advantage of Jani's idea of generating
> several boolean terms.

Agreed. On to details:

> folder: could work the way I suggested (simply the path to the file,
> with {cur,new} stripped off).

What if the file is not in a folder named cur/new? I suggest indexing
the folder as-is, if only for some backwards compatibility.

What if there is not all of cur/new/tmp folders? I suggest ignoring
that, and only look at the path to the file being indexed. This is
simplest to implement, and it does not matter if the sibling directories
come and go, and for this reason also unsurprising.

For top level cur/new, index the empty string "".

> path: would support file system search
> uses.  These seem more varied, but I think fall into exact match and
> recursive match.  Since I don't have this use case, I can't have any
> strong opinions about syntax, but I'll throw out an idea: many shells
> support "**" for recursive path matching and people are already quite
> familiar with glob patterns for paths, so why not simply adopt this?
> In other words, when adding the path "a/b/cur/x:2," add path: terms
> "a/b/cur" and "a/b/**" and "a/**" and "**".

Since folder: would cover the cur/new cases, I suggest the non-recursive
variant of path: prefix is the exact filesystem folder name as-is (with
the top level being the empty string ""). I presume this is what you
meant too.

I kind of like the "/**" suffix for recursive, but there's two small
wrinkles: 1) it needs quoting on the command line (unlike my original
suggestion of just "/" suffix), and 2) what should the top level
recursive search be? path:"**" or path:"/**" or path:"./**"? I guess the
first one is most obvious?

So here's what my original suggestions would become:

>> Here's a thought. With boolean prefix folder:, we can devise a scheme
>> where the folder: query defines what is to be matched.
>> 
>> For example:
>> 
>> folder:foo	match files in foo, foo/new, and foo/cur.

-> folder:foo

>> folder:foo/	match all files in all subdirectories under foo (this
>> 		would handle Tomi's use case), including foo/new and foo/cur.

-> path:"foo/**"

>> folder:foo/.	match in foo only, and specifically not in foo/cur or foo/new.

-> path:foo

>> folder:foo/new  match in foo/new, and specifically not in foo/cur (this
>> 		allows distinguishing between messages in cur and new).

-> path:foo/new

>> folder:/	match everything.

-> path:"**"

>> folder:/.	match in top level maildir only.

-> path:""

>> folder:""	match in top level maildir, including cur/new.

-> folder:""


I'd like these details to be ironed out and agreed on before I send the
next version.

BR,
Jani.

  parent reply	other threads:[~2014-02-01 14:54 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 22:18 [PATCH 0/5] lib: make folder: prefix literal Jani Nikula
2014-01-09 22:18 ` [PATCH 1/5] " Jani Nikula
2014-01-24 21:18   ` Austin Clements
2014-01-09 22:18 ` [PATCH 2/5] test: fix insert folder: searches Jani Nikula
2014-01-24 21:20   ` Austin Clements
2014-01-25 19:32     ` Rob Browning
2014-01-09 22:18 ` [PATCH 3/5] test: fix test for literal folder: search Jani Nikula
2014-01-09 22:18 ` [PATCH 4/5] test: add test database in format version 1 Jani Nikula
2014-01-09 22:18 ` [PATCH 5/5] test: add database upgrade test from " Jani Nikula
2014-01-24 21:17 ` [PATCH 0/5] lib: make folder: prefix literal Austin Clements
2014-01-24 23:21   ` David Bremner
2014-01-25  9:33   ` Jani Nikula
2014-01-25 10:47     ` Tomi Ollila
2014-01-25 11:06       ` Jani Nikula
2014-01-25 11:52         ` Tomi Ollila
2014-01-25 15:38     ` Jani Nikula
2014-01-25 16:58       ` David Bremner
2014-01-25 18:22         ` Jani Nikula
     [not found]       ` <874n4rvcvo.fsf@yoom.home.cworth.org>
2014-01-29 19:05         ` Jani Nikula
     [not found]           ` <87k3dir3ci.fsf@yoom.home.cworth.org>
2014-01-29 20:46             ` Austin Clements
     [not found]               ` <87bnyuqw60.fsf@yoom.home.cworth.org>
2014-01-30  6:34                 ` Jani Nikula
2014-01-30 21:15                   ` Mark Walters
2014-01-30 22:02       ` Austin Clements
2014-01-31 19:19         ` Rob Browning
2014-02-04 20:14           ` Austin Clements
2014-02-04 20:17             ` Rob Browning
2014-01-31 19:24         ` Rob Browning
2014-02-01 14:54         ` Jani Nikula [this message]
2014-02-04 20:02           ` Austin Clements
2014-02-05 13:12             ` Tomi Ollila
2014-02-05 21:12               ` Tomi Ollila

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fvo2yjc4.fsf@nikula.org \
    --to=jani@nikula.org \
    --cc=amdragon@MIT.EDU \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).