On Tue, Feb 04 2014, Austin Clements amdra...@mit.edu wrote:
Quoth Jani Nikula on Feb 01 at 4:54 pm:
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
On Wed, Feb 05 2014, Tomi Ollila tomi.oll...@iki.fi wrote:
On Tue, Feb 04 2014, Austin Clements amdra...@mit.edu wrote:
In zsh:
$ echo whatever:/**
whatever:/**
Except (retested after seeing related IRC msg from Austin):
$ unsetopt no_nomatch
$ echo whatever:/**
zsh: no matches found:
Quoth Jani Nikula on Feb 01 at 4:54 pm:
On Fri, 31 Jan 2014, Austin Clements amdra...@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
Quoth Rob Browning on Jan 31 at 1:19 pm:
Austin Clements amdra...@mit.edu writes:
folder: could work the way I suggested (simply the path to the file,
with {cur,new} stripped off).
Hmm, so would notmuch try to guess whether or not it's dealing with a
maildir++ tree, and if so convert
Austin Clements amdra...@mit.edu writes:
The simple algorithm of taking the relative path and stripping
{new,cur} (if present) does a good job of supporting both Maildir and
non-Maildir stores (while balancing this support with simplicity,
predictability, and usability).
Unless, of course,
Austin Clements amdra...@mit.edu writes:
Agreed. I believe this will also support MH, if I understand MH
correctly (does anyone actually use MH?)
When I started notmuch, I had all of my mail in one-message-per-file in
various directories, (without these silly cur and new directories
that
On Fri, 31 Jan 2014, Austin Clements amdra...@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
Austin Clements amdra...@mit.edu writes:
folder: could work the way I suggested (simply the path to the file,
with {cur,new} stripped off).
Hmm, so would notmuch try to guess whether or not it's dealing with a
maildir++ tree, and if so convert folder:foo to a search of .foo, and/or
Quoth Jani Nikula on Jan 25 at 5:38 pm:
On Sat, 25 Jan 2014, Jani Nikula j...@nikula.org wrote:
Perhaps we need to have two prefixes, one of which is the literal
filesystem folder and another which hides the implementation details,
like I mentioned in my mail to Peter [1]. But consider
On Sun, 26 Jan 2014, Carl Worth cwo...@cworth.org wrote:
Jani Nikula j...@nikula.org writes:
Here's a thought. With boolean prefix folder:, we can devise a scheme
where the folder: query defines what is to be matched.
I like the idea, but I tried to infer the rules from the examples, and I
Jani Nikula j...@nikula.org writes:
Unfortunately, I haven't had the time to experiment with this. But it
bugs me that the probabilistic folder: prefix has stemming and it's case
insensitive. It's possible to work around the stemming with the anchors
you suggest or by quoting, but is there a
On Wed, 29 Jan 2014, Carl Worth cwo...@cworth.org wrote:
Austin Clements acleme...@csail.mit.edu writes:
I think you're assuming we have much more control over this than we
do.
To be fair, I only started discussing my proposal for '^' and '$' in
response to Jani's proposal with special
On Fri, 24 Jan 2014, Austin Clements acleme...@csail.mit.edu wrote:
On Thu, 09 Jan 2014, Jani Nikula j...@nikula.org wrote:
Hi all, this series makes the folder: search prefix literal, or switches
it from a probabilistic prefix to a boolean prefix. With this, you have
to give the path from the
On Sat, Jan 25 2014, Jani Nikula j...@nikula.org wrote:
On Fri, 24 Jan 2014, Austin Clements acleme...@csail.mit.edu wrote:
On Thu, 09 Jan 2014, Jani Nikula j...@nikula.org wrote:
Hi all, this series makes the folder: search prefix literal, or switches
it from a probabilistic prefix to a
On Sat, 25 Jan 2014, Tomi Ollila tomi.oll...@iki.fi wrote:
On Sat, Jan 25 2014, Jani Nikula j...@nikula.org wrote:
Perhaps we need to have two prefixes, one of which is the literal
filesystem folder and another which hides the implementation details,
like I mentioned in my mail to Peter [1].
On Sat, 25 Jan 2014, Jani Nikula j...@nikula.org wrote:
Perhaps we need to have two prefixes, one of which is the literal
filesystem folder and another which hides the implementation details,
like I mentioned in my mail to Peter [1]. But consider this: my proposed
implementation does cover
Jani Nikula j...@nikula.org writes:
On Sat, 25 Jan 2014, Jani Nikula j...@nikula.org wrote:
Perhaps we need to have two prefixes, one of which is the literal
filesystem folder and another which hides the implementation details,
like I mentioned in my mail to Peter [1]. But consider this: my
On Sat, 25 Jan 2014, David Bremner da...@tethera.net wrote:
Jani Nikula j...@nikula.org writes:
On Sat, 25 Jan 2014, Jani Nikula j...@nikula.org wrote:
Perhaps we need to have two prefixes, one of which is the literal
filesystem folder and another which hides the implementation details,
like
Jani Nikula j...@nikula.org writes:
Here's a thought. With boolean prefix folder:, we can devise a scheme
where the folder: query defines what is to be matched.
I like the idea, but I tried to infer the rules from the examples, and I
failed. It looks like there are two new symbols, / and /. but
On Thu, 09 Jan 2014, Jani Nikula j...@nikula.org wrote:
Hi all, this series makes the folder: search prefix literal, or switches
it from a probabilistic prefix to a boolean prefix. With this, you have
to give the path from the maildir root to the folder you want in full,
including the maildir
Austin Clements acleme...@csail.mit.edu writes:
On Thu, 09 Jan 2014, Jani Nikula j...@nikula.org wrote:
I strongly disagree with requiring the cur/new component. The cur/new
directory is an internal implementation detail of Maildir (and a rather
broken one at that) and no more a part of the
21 matches
Mail list logo
