Hello all!
My question -- rather a curiosity -- is if one could easily
implement an alternative message store instead of maildir. (I actually
have in mind a KV store like BerkeleyDB, or even a database like
CouchDB...) (I'm not also implying the same for the index, which I'm
aware is based
On Sat, Aug 11, 2012 at 12:46 PM, Vladimir Marek
wrote:
> Hi,
>
> I have objections against maildir too,
Just for the record I have nothing against maildir (or at least
when compared to mbox format). On the contrary I find it quite easy to
fiddle with...
My problem with it is that it doe
On Sat, Aug 11, 2012 at 11:50 PM, Jameson Graef Rollins
wrote:
> On Sat, Aug 11 2012, Ciprian Dorin Craciun wrote:
>> My problem with it is that it doesn't scale... And I don't mean
>> this in a theoretical sense, I mean it in the concrete one: I have
>> ab
On Tue, Aug 14, 2012 at 7:04 PM, Vladimir Marek
wrote:
>> > - fuse zip stores all changes in memory until unmounted
>> > - fuse zip (and libzip for that matter) creates new temporary file when
>> >updating archive, which takes considerable time when the archive is
>> >very big.
>>
>> Thi
On Tue, Aug 14, 2012 at 7:50 PM, Vladimir Marek
wrote:
>> On the other hand I strongly sustain having a more optimized
>> backend for emails, especially for such cases. For example a
>> BerkeleyDB would perfectly fit such a use case, especially if we store
>> the body and the headers in separa
Hello all!
First congratulations for the nice software! I hardly wait for a
notmuch native (i.e. libnotmuch) and curses client (like `ner`) to
become more stable, and thus I'll be able to ditch GMail. :) But until
then a small glitch...
While upgrading from notmuch 0.4 to 0.5, I've re
On Tue, Nov 16, 2010 at 21:09, Carl Worth wrote:
> On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun"
> wrote:
>> So my question is: is this behaviour (of deleting the file and
>> creating a new one) deliberate? If not, could it be fixed (I could
>&g
On Tue, Nov 16, 2010 at 22:37, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>> P.S.: I say "pseudo" atomic because only the rename is atomic,
>> thus in order to override file `a` for the target file `b` which
>> exists, w
On Tue, Nov 16, 2010 at 22:42, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:37 PM, Daniel Kahn Gillmor wrote:
>> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>>> So in the light of the above quoted "glitches", my question is:
>>> due to the s
Hello all! (Sorry for the long email.)
I'm "struggling" for some time to get rid of the current
"de-facto" email solutions (i.e. GMail, Zimbra), and I've passively
observed for some time the notmuch project and community.
Although I've forwarded all my email to a single account, and I
Hello all!
Quick question: why isn't it reasonable to export a **single**
email in JSON format (by using the `show` sub-command)? (I mean I
understand that in order to be able to correctly parse the output we
need only one "object" (i.e. a list of threads, containing a list of
emails, etc.
On Sat, Dec 10, 2011 at 22:15, Jameson Graef Rollins
wrote:
> On Sat, 10 Dec 2011 20:32:22 +0200, Ciprian Dorin Craciun
> wrote:
>> Quick question: why isn't it reasonable to export a **single**
>> email in JSON format (by using the `show` sub-command)? (I mean I
>
On Sun, Dec 11, 2011 at 01:19, Jameson Graef Rollins
wrote:
> On Sun, 11 Dec 2011 00:46:51 +0200, Ciprian Dorin Craciun
> wrote:
>> * in my use-case I would need each line of the output to be a
>> standalone JSON object of an individual message; (thus I can script
>
Hello all!
First congratulations for the nice software! I hardly wait for a
notmuch native (i.e. libnotmuch) and curses client (like `ner`) to
become more stable, and thus I'll be able to ditch GMail. :) But until
then a small glitch...
While upgrading from notmuch 0.4 to 0.5, I've re
On Tue, Nov 16, 2010 at 21:09, Carl Worth wrote:
> On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun" at gmail.com> wrote:
>> ? ? So my question is: is this behaviour (of deleting the file and
>> creating a new one) deliberate? If not, could it be fixed (I
On Tue, Nov 16, 2010 at 22:37, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>> ? ? P.S.: I say "pseudo" atomic because only the rename is atomic,
>> thus in order to override file `a` for the target file `b` which
>> exists, w
On Tue, Nov 16, 2010 at 22:42, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:37 PM, Daniel Kahn Gillmor wrote:
>> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>>> ? ? So in the light of the above quoted "glitches", my question is:
>>> due to the s
Hello all! (Sorry for the long email.)
I'm "struggling" for some time to get rid of the current
"de-facto" email solutions (i.e. GMail, Zimbra), and I've passively
observed for some time the notmuch project and community.
Although I've forwarded all my email to a single account, and I
Hello all!
Quick question: why isn't it reasonable to export a **single**
email in JSON format (by using the `show` sub-command)? (I mean I
understand that in order to be able to correctly parse the output we
need only one "object" (i.e. a list of threads, containing a list of
emails, etc.
On Sat, Dec 10, 2011 at 22:15, Jameson Graef Rollins
wrote:
> On Sat, 10 Dec 2011 20:32:22 +0200, Ciprian Dorin Craciun gmail.com> wrote:
>> ? ? Quick question: why isn't it reasonable to export a **single**
>> email in JSON format (by using the `show` sub-command)? (I me
On Sun, Dec 11, 2011 at 01:19, Jameson Graef Rollins
wrote:
> On Sun, 11 Dec 2011 00:46:51 +0200, Ciprian Dorin Craciun gmail.com> wrote:
>> ? ? * in my use-case I would need each line of the output to be a
>> standalone JSON object of an individual message; (thus I can s
[Sorry if I'm double reporting this. I've tried my best to search for
previous discussions.]
I've tried to manually edit my `~/.notmuch-config`, and I've seen that
the field `tags` was written as `tags=unread;inbox;`. In order to
increase readability I've decided to update my configuration file
[Again sorry for double reporting. BTW, where should I search for
previous bugs? I've currently tried the mailing list archive.]
Trying to play with `notmuch` from a wrapper, I've stumbled upon the
following command line flags handling bug:
notmuch show --format json --entire-thread true
On Mon, Apr 27, 2020 at 9:21 PM Tomi Ollila wrote:
> > On Mon 2020-04-27 14:53:07 -0300, David Bremner wrote:
> >> Quoting notmuch(1)
> >>
> >>OPTION SYNTAX
> >>All options accepting an argument can be used with '='
> >>or ':' as a separator. For the cases where it's not ambigu
On Wed, Apr 29, 2020 at 6:39 PM David Bremner wrote:
> I guess I'm a bit leery of removing UI features that presumably at least
> some people rely on. It's pretty upsetting to have sofware break one's
> muscle memory.
I think there are two complete different use-cases for the `notmuch` binary:
*
According to the `devel/schemata` the message object doesn't contain
the thread identifier to which it was assigned in the database.
Sometimes, for example in an UI that displays a search result at
message level, it would be useful to know the thread each message
belongs to, so the user can easily
I've searched the mailing list archives about the `List-Id` feature:
* https://www.mail-archive.com/notmuch@notmuchmail.org/msg43214.html
* https://www.mail-archive.com/notmuch@notmuchmail.org/msg22092.html
* https://www.mail-archive.com/notmuch@notmuchmail.org/msg14146.html
I've also read the FAQ
On Wed, Apr 29, 2020 at 8:08 PM David Bremner wrote:
> > I've also read the FAQ:
> > * https://notmuchmail.org/faq/#index8h2
>
> Oops, that needs to be updated.
>
> It is implemented. See notmuch-config(1), under "index.header"
That's perfect. However the `search-terms` man pages doesn't say ho
On Fri, May 1, 2020 at 3:09 PM David Bremner wrote:
> Ciprian Dorin Craciun writes:
> > I know that one can use `thread:{id:MESSAGE_ID}` to achieve the same
> > result, however:
> > * it is somewhat cumbersome for the integrator;
>
> Out of curiousity, what is harder
In a previous email (about `thread:...` field in JSON output of
`notmuch show`), I described one of my use-cases for notmuch.
Now extending upon that, if one would to implement an email client
that provides the user with search, there are two approaches:
* use `notmuch search -- {query}` and base
Hello all!
My question -- rather a curiosity -- is if one could easily
implement an alternative message store instead of maildir. (I actually
have in mind a KV store like BerkeleyDB, or even a database like
CouchDB...) (I'm not also implying the same for the index, which I'm
aware is based
On Sat, Aug 11, 2012 at 12:46 PM, Vladimir Marek
wrote:
> Hi,
>
> I have objections against maildir too,
Just for the record I have nothing against maildir (or at least
when compared to mbox format). On the contrary I find it quite easy to
fiddle with...
My problem with it is that it doe
On Sat, Aug 11, 2012 at 11:50 PM, Jameson Graef Rollins
wrote:
> On Sat, Aug 11 2012, Ciprian Dorin Craciun
> wrote:
>> My problem with it is that it doesn't scale... And I don't mean
>> this in a theoretical sense, I mean it in the concrete one: I have
>>
On Tue, Aug 14, 2012 at 7:04 PM, Vladimir Marek
wrote:
>> > - fuse zip stores all changes in memory until unmounted
>> > - fuse zip (and libzip for that matter) creates new temporary file when
>> >updating archive, which takes considerable time when the archive is
>> >very big.
>>
>> Thi
On Tue, Aug 14, 2012 at 7:50 PM, Vladimir Marek
wrote:
>> On the other hand I strongly sustain having a more optimized
>> backend for emails, especially for such cases. For example a
>> BerkeleyDB would perfectly fit such a use case, especially if we store
>> the body and the headers in separa
35 matches
Mail list logo