Re: notmuch emacs interface
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
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
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
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
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] Some thoughts about notmuch sync with other agents
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
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
