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 doc
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 l
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 doc
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 l
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 folder:fo
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 probabil
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 l
Austin Clements 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 maildir uses).
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 l
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 folder:fo
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 probabil
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 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
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 fri
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 .foo.bar
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 fri
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 .foo.bar
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
> improveme
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 pro
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 pro
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
> improveme
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
> "/.".
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
> "/.".
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 ther
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 s
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
"/.".
Support for any of this magic syntax would requir
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 s
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 suggest or by quoting, but is there a way to have c
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 ther
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 [1
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 cases
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 there are two new symbols, "/" and "/." but I
couldn'
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 my
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 propos
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
>> implementatio
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 t
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 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 [1
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
>> implementatio
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 cases
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 my
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 propos
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 t
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
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 tha
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 comp
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 tha
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 comp
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
folder:foo/b
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
folder:foo/b
50 matches
Mail list logo
