On Wed, Feb 05 2014, Tomi Ollila wrote:
> On Tue, Feb 04 2014, Austin Clements wrote:
>
>
> In zsh:
>
> $ echo whatever:/**
> whatever:/**
Except (retested after seeing related IRC msg from Austin):
$ unsetopt no_nomatch
$ echo whatever:/**
zsh: no matches found: whatever:/**
We can maybe
On Tue, Feb 04 2014, Austin Clements 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 top
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 Rob Browning on Jan 31 at 1:19 pm:
> Austin Clements 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
Quoth Jani Nikula on Feb 01 at 4:54 pm:
> On Fri, 31 Jan 2014, Austin Clements 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
Austin Clements 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, the user has
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 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
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 writes:
> However, it seems like this is overloading one prefix for two
> meanings.
Oh, and I agree here. I think that ideally, there would be at least one
very-literal way to identify a specific directory (or tree, perhaps via
**), and then some other less-precise, but more
Austin Clements 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
folder:foo/bar to
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
Dear Jani
> That is the unicorn... many of the query improvements I have in mind
> depend on a custom query parser. So I'd like to have that. And a
> pony. But in the mean time, I'm left wondering whether I should pursue
> folder: as a boolean prefix, or try to figure out if there are
>
Quoth Jani Nikula on Jan 25 at 5:38 pm:
> On Sat, 25 Jan 2014, Jani Nikula 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 Wed, 29 Jan 2014, Carl Worth wrote:
> Austin Clements 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 semantics for trailing '/' and
>
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 wrote:
> Jani Nikula 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
Quoth Carl Worth on Jan 29 at 11:32 am:
> Jani Nikula 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
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 Sat, 25 Jan 2014, David Bremner wrote:
> Jani Nikula writes:
>
>> On Sat, 25 Jan 2014, Jani Nikula 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
On Sat, 25 Jan 2014, Jani Nikula 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 *all* use
On Sat, Jan 25 2014, Jani Nikula wrote:
> On Sat, 25 Jan 2014, Tomi Ollila wrote:
>> On Sat, Jan 25 2014, Jani Nikula 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
On Sat, 25 Jan 2014, Tomi Ollila wrote:
> On Sat, Jan 25 2014, Jani Nikula 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
Jani Nikula writes:
> On Sat, 25 Jan 2014, Jani Nikula 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
>>
On Sat, Jan 25 2014, Jani Nikula wrote:
> On Fri, 24 Jan 2014, Austin Clements wrote:
>> On Thu, 09 Jan 2014, Jani Nikula 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
On Fri, 24 Jan 2014, Austin Clements wrote:
> On Thu, 09 Jan 2014, Jani Nikula 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
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
Austin Clements writes:
> On Thu, 09 Jan 2014, Jani Nikula 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 "folder" of a piece of
> mail
On Thu, 09 Jan 2014, Jani Nikula 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 cur/new
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
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 cur/new component, if any. Examples:
folder:cur
44 matches
Mail list logo
