Re: notmuch emacs interface

2010-05-04 Thread Paul R

Carl I didn't have any specific plans. I think things like this are
Carl generally great if done by people already reading those lists.
Carl Would you like to send a note including something very much like
Carl the paragraph above along with Hey, I thought some poeple here
Carl might be interested in the recent development of notmuch. ... See
Carl the notmuch-gxuj+tv9eo5zyzon3hd...@public.gmane.org list for
Carl more.?

Sure I can do so. Let's wait for the event of a release. Given your
roadmap, are you ok with an announce for NotMuch 0.4 ?

-- 
  Paul
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


notmuch emacs interface

2010-04-28 Thread Paul R

Carl> I didn't have any specific plans. I think things like this are
Carl> generally great if done by people already reading those lists.
Carl> Would you like to send a note including something very much like
Carl> the paragraph above along with "Hey, I thought some poeple here
Carl> might be interested in the recent development of notmuch. ... See
Carl> the notmuch-gxuj+Tv9EO5zyzON3hdc1g at public.gmane.org list for
Carl> more."?

Sure I can do so. Let's wait for the event of a release. Given your
roadmap, are you ok with an announce for NotMuch 0.4 ?

-- 
  Paul


notmuch emacs interface

2010-04-27 Thread Paul R
Hello,

following the activity on this list, I've seen a recent effort toward
improving the behaviour of the Emacs frontend to notmuch, which is
a really nice thing.

I also read the main emacs development mailing list, as well as the Gnus
ML, and I haven't seen any mention of NotMuch there, or maybe just once
on the later.

I'm pretty sure most emacs hackers want notmuch thought, because it
brings a fresh, clean, responsive, reliable and efficient way of dealing
with mails from emacs. In my experience, there is no prior art in this
area (unfortunately). You could probably easily attract a handful of
core emacs developers to notmuch, therefore benefit from their amazing
emacs-fu to improve the frontend.

Do you have a plan for that ? I think announcing it on emacs devel
mailing list would be ok, even if it is slightly off topic.



-- 
  Paul


notmuch emacs interface

2010-04-27 Thread Paul R
Hello,

following the activity on this list, I've seen a recent effort toward
improving the behaviour of the Emacs frontend to notmuch, which is
a really nice thing.

I also read the main emacs development mailing list, as well as the Gnus
ML, and I haven't seen any mention of NotMuch there, or maybe just once
on the later.

I'm pretty sure most emacs hackers want notmuch thought, because it
brings a fresh, clean, responsive, reliable and efficient way of dealing
with mails from emacs. In my experience, there is no prior art in this
area (unfortunately). You could probably easily attract a handful of
core emacs developers to notmuch, therefore benefit from their amazing
emacs-fu to improve the frontend.

Do you have a plan for that ? I think announcing it on emacs devel
mailing list would be ok, even if it is slightly off topic.



-- 
  Paul
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[notmuch] an other ready-to-use store option for notmuch : CouchDB

2010-03-02 Thread Paul R
Hi,

couchDB is a document-oriented database. It stores documents, IOW
key-value pairs, under a unique ID. These documents are retrieved
through views and queries. A mail with some tags and some mime parts is
a perfect exemple of what couchdb call a "document".

CouchDB databases can be replicated and synced in both directions.
Conflicts are lazily handled.

People here often call for facilities to read mail with notmuch from
different places. An unidirectional imap-to-couchDB, plus a couchDB
backend for notmuch, should give enough flexibility to achieve this
goal. Put a couchDB replica somewhere accessible, push new IMAP mails on
it, then sync as many machines as you want with this central couchDB
store.


-- 
  Paul


[notmuch] an other ready-to-use store option for notmuch : CouchDB

2010-03-02 Thread Paul R
Hi,

couchDB is a document-oriented database. It stores documents, IOW
key-value pairs, under a unique ID. These documents are retrieved
through views and queries. A mail with some tags and some mime parts is
a perfect exemple of what couchdb call a document.

CouchDB databases can be replicated and synced in both directions.
Conflicts are lazily handled.

People here often call for facilities to read mail with notmuch from
different places. An unidirectional imap-to-couchDB, plus a couchDB
backend for notmuch, should give enough flexibility to achieve this
goal. Put a couchDB replica somewhere accessible, push new IMAP mails on
it, then sync as many machines as you want with this central couchDB
store.


-- 
  Paul
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[notmuch] Some thoughts about notmuch sync with other agents

2010-01-29 Thread Paul R


Hi,

before going into details, I'd like to tell you how much I like the
notmuch workflow, thank you for producing this nice piece of software !

Like most potential users, I can not really fully jump into notmuch
because of the current synchronisation issues with others MUA. One may
or may not like IMAP for good reasons, the fact is that it is here and
has allowed users to read mails from various places and terminals,
keeping important information synced. So I think that notmuch will have
to live with that, and provide what is required to integrate smoothly
into this environment. Redefining a new mail retrieval protocol and
a mail storing format are both really exciting projects, but they are
projects on their own that could only distract notmuch from its most
beautiful goal : giving *today* users the power to process mail in an
efficient way.

As you see, I advocate a NotMuch - IMAP synchronisation ASAP :)

At the moment, notmuch input are mail-as-file + user-defined tags.
OfflineIMAP allows to do the IMAP - mail-as-file transition, in both
directions, mail-as-file being namely MailDir. So we can simply aim at
a NotMuch - MailDir synchronisation, offlineimap will take care of
IMAP itself.

Of course, my proposal does not require to implement any MailDir
specific logic inside NotMuch, but rather describes how should notmuch
evolve to allow easy third-party-tool jobs.


Preliminary thoughts :
--

First of all, processing mail with MUA involves some simple logic that
is shared by most MUA. This is about receiving *new* mails, *reading*
mail, *replying* to mail and so on... IMHO, this really belongs to the
mail processing logic and not to the user logic. Hence my first
request :

  1: Don't use user tags space to store MUA flags.

 That means no more seen, unread, replied as tags. These are
 MUA processing *flags*, that must belong to an established set.
 Tags, on the other hand, are user-land information. So no more
 [seen, replied, grandma, important] tag sets :)

Once this is done, notmuch will know, in a robust a predictable way,
what happened to a mail. Simply put, NotMuch will store and expose MUA
flags (Passed, Replied, Seen, Trashed, Draft, and Flagged [1]). For each
flag, notmuch should associate a flag_synced flag. When changing
flag from notmuch, it should set the flag_synced bit to 0. These are
MUA mail flags.

Additionally, in a third « space », notmuch should store its « new »
bit, as well as a « missing » bit probably. Again, this is neither MUA
logic or user logic, so this should not interfer with user
classification facility provided by tags, nor with MUA flags. It,
really, is something else, let's name it status. Once this is done,
the 'notmuch new' command should find new mails and set the 'new' bit
for them, and find the missing mails and set the 'missing' bit for them.
This will allow for robust external processing.

Finally, notmuch should provide a switch to output a list of filenames
to stdout and to process a list of filenames from stdin.


NotMuch - MailDir synchronisation :
-

Provided the behaviour described above, notmuch - MailDir
synchronisation could be done fully externally, by a 'notmuch-maildir'
adapter.

Here is some pseudo code, that could be wrapped into a single
'notmuch-sync' command. The | are unix stream pipes, and everything
should be on a single line.

# 1/ Sync from NotMuch to MailDir

notmuch list flags:(seen and not seen_synced) 
  | notmuch-maildir --mark-mail seen
  | notmuch move --stdin
  | notmuch set flags:+seen_synced --stdin

The output of the first command would be a list of filenames for mails
'seen' since last sync. The second one, an external notmuch--maildir
helper, would propagate this logic to the MailDir store (easy, this is
simply a rename), and output the list of (old-name ! new-name). Then
notmuch would use this information, via a generic 'move' switch, to know
that mail has been moved, and would output the list of the new places.
Finaly, notmuch would set the seen_synced flag.

Same would apply for the Replied, Trashed, Flagged and Passed flags.

# 2/ Then lets do the MailDir - IMAP sync

 offlineimap

... done ! that was easy :)

# 3/ notmuch new

 notmuch new

At this point, notmuch should set the 'new' or the 'missing' status bit
to the mails. Let's forget how to deal with the missing bit, that should
be easy to do.

# 4/ Sync from MailDir to NotMuch

  notmuch list status:new 
   | notmuch-maildir --filter seen
   | notmuch set flags:+seen+seen_synced --stdin

First command outputs newly discovered mail. Second one reads stdin and
output only files that are already seen (again, this is as easy as
a filter based on a regular expression). Third one reads stdin and
applies the seen and seen_synced flags.

Same applies for the Replied, Trashed, Flagged and Passed flags.


Conclusion:
---

As we have seen, this would allow most IMAP - 

[notmuch] Some thoughts about notmuch sync with other agents

2010-01-27 Thread Paul R


Hi,

before going into details, I'd like to tell you how much I like the
notmuch workflow, thank you for producing this nice piece of software !

Like most potential users, I can not really fully jump into notmuch
because of the current synchronisation issues with others MUA. One may
or may not like IMAP for good reasons, the fact is that it is here and
has allowed users to read mails from various places and terminals,
keeping important information synced. So I think that notmuch will have
to live with that, and provide what is required to integrate smoothly
into this environment. Redefining a new mail retrieval protocol and
a mail storing format are both really exciting projects, but they are
projects on their own that could only distract notmuch from its most
beautiful goal : giving *today* users the power to process mail in an
efficient way.

As you see, I advocate a NotMuch <-> IMAP synchronisation ASAP :)

At the moment, notmuch input are mail-as-file + user-defined tags.
OfflineIMAP allows to do the IMAP <-> mail-as-file transition, in both
directions, mail-as-file being namely MailDir. So we can simply aim at
a NotMuch <-> MailDir synchronisation, offlineimap will take care of
IMAP itself.

Of course, my proposal does not require to implement any MailDir
specific logic inside NotMuch, but rather describes how should notmuch
evolve to allow easy third-party-tool jobs.


Preliminary thoughts :
--

First of all, processing mail with MUA involves some simple logic that
is shared by most MUA. This is about receiving *new* mails, *reading*
mail, *replying* to mail and so on... IMHO, this really belongs to the
mail processing logic and not to the user logic. Hence my first
request :

  1: Don't use user tags space to store MUA flags.

 That means no more "seen", "unread", "replied" as tags. These are
 MUA processing *flags*, that must belong to an established set.
 Tags, on the other hand, are user-land information. So no more
 [seen, replied, grandma, important] tag sets :)

Once this is done, notmuch will know, in a robust a predictable way,
what happened to a mail. Simply put, NotMuch will store and expose MUA
flags (Passed, Replied, Seen, Trashed, Draft, and Flagged [1]). For each
, notmuch should associate a _synced flag. When changing
 from notmuch, it should set the _synced bit to 0. These are
MUA mail flags.

Additionally, in a third ? space ?, notmuch should store its ? new ?
bit, as well as a ? missing ? bit probably. Again, this is neither MUA
logic or user logic, so this should not interfer with user
classification facility provided by tags, nor with MUA flags. It,
really, is something else, let's name it "status". Once this is done,
the 'notmuch new' command should find new mails and set the 'new' bit
for them, and find the missing mails and set the 'missing' bit for them.
This will allow for robust external processing.

Finally, notmuch should provide a switch to output a list of filenames
to stdout and to process a list of filenames from stdin.


NotMuch <-> MailDir synchronisation :
-

Provided the behaviour described above, notmuch <-> MailDir
synchronisation could be done fully externally, by a 'notmuch-maildir'
adapter.

Here is some pseudo code, that could be wrapped into a single
'notmuch-sync' command. The | are unix stream pipes, and everything
should be on a single line.

# 1/ Sync from NotMuch to MailDir

notmuch list flags:(seen and not seen_synced) 
  | notmuch-maildir --mark-mail seen
  | notmuch move --stdin
  | notmuch set flags:+seen_synced --stdin

The output of the first command would be a list of filenames for mails
'seen' since last sync. The second one, an external notmuch--maildir
helper, would propagate this logic to the MailDir store (easy, this is
simply a rename), and output the list of (old-name ! new-name). Then
notmuch would use this information, via a generic 'move' switch, to know
that mail has been moved, and would output the list of the new places.
Finaly, notmuch would set the seen_synced flag.

Same would apply for the Replied, Trashed, Flagged and Passed flags.

# 2/ Then lets do the MailDir <-> IMAP sync

 offlineimap

... done ! that was easy :)

# 3/ notmuch new

 notmuch new

At this point, notmuch should set the 'new' or the 'missing' status bit
to the mails. Let's forget how to deal with the missing bit, that should
be easy to do.

# 4/ Sync from MailDir to NotMuch

  notmuch list status:new 
   | notmuch-maildir --filter seen
   | notmuch set flags:+seen+seen_synced --stdin

First command outputs newly discovered mail. Second one reads stdin and
output only files that are already seen (again, this is as easy as
a filter based on a regular expression). Third one reads stdin and
applies the seen and seen_synced flags.

Same applies for the Replied, Trashed, Flagged and Passed flags.


Conclusion:
---

As we have seen, this would allow most IMAP