Re: [notmuch] Idea for storing tags

also sprach Carl Worth cwo...@cworth.org [2010.01.15.1124 +1300]: You might have marked a message 'read' on one machine and if the two get out of sync on another machine, you might have the same message unread there. That's a different issue though. With two databases there's clearly the

Re: [notmuch] Threading

also sprach Carl Worth cwo...@cworth.org [2010.01.15.1108 +1300]: Reading is one thing. Information storage and organisation is another. After a message is delivered (and read) to my mailbox, it's really mine and I can (and should be able) to affix it and integrate it into my

Re: [notmuch] Thoughts on notmuch and Lua

also sprach Carl Worth cwo...@cworth.org [2010.01.15.1200 +1300]: Lua has many advantages over other scripting languages when it comes to integration with a C program. It has a very clean and easy C API, the overhead of running Lua scripts is not noticable among other things. I've

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

also sprach Asheesh Laroia ashe...@asheesh.org [2010.01.21.1928 +1300]: I suppose that I never actually considered merges on the IMAP server side, but obviously the IMAP server has to work off a clone, and that means it needs to merge. It's not merge that's unsafe; that just builds a tree in

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

also sprach Asheesh Laroia ashe...@asheesh.org [2010.01.25.1819 +1300]: You say Ouch but you should know Dovecot *already* does this. I don't mind interoperating with that. See http://wiki.dovecot.org/MailboxFormat/Maildir, section Issues with the specification, subsection Locking. I term

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

also sprach Sebastian Spaeth sebast...@sspaeth.de [2010.01.26.0249 +1300]: While notmuchsync fullfils my needs, it is a kludge. It needs to call notmuch for each mail where a MailDir flag has changed (which can be quite often on an initial run, where most mails are likely to be read), this can

Re: [notmuch] Git feature branch

also sprach Carl Worth cwo...@cworth.org [2010.01.23.1010 +1300]: Anyway, I'll be on vacation for the next few days, so will likely not have much, (likely have not much?), time for patch merging. But I *am* anxious to get back to the backlog. And in the meantime, I really appreciate others

Re: [notmuch] Git feature branch

also sprach micah anderson mi...@riseup.net [2010.01.27.1124 +1300]: Couldn't all of this be done without moving the existing git repository (don't forget that transition is a cost)? Those who wish to put together these proposed branches go ahead and do so, publishing those wherever they like

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Jameson Rollins jroll...@finestructure.net [2010.01.26.1046 +1300]: For example, I might have: ~/.notmuch-config: [database] path=/home/pioto/mail ... [tags] pi...@pioto.org/INBOX.ListMail.notmuch = notmuch So, a 'tags' section, where each

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Jameson Rollins jroll...@finestructure.net [2010.01.27.0603 +1300]: This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and context-sensitive decisions be delegated to sub-processes? ala git hooks? I think this idea is

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach James Westby jw+deb...@jameswestby.net [2010.01.28.1828 +1300]: Are you trying to use thread: such that it could be passed to notmuch show to see the conversation? That's not going to work so well if so. Why not? Works fine for me with the vim plugin... -- martin |

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Servilio Afre Puentes servi...@gmail.com [2010.01.29.0132 +1300]: [tags] inbox = +inbox,+unread sent = +sent drafts = +draft archive = -inbox This proposal, on the other hand, is an interesting one, but when is it supposed to happen? It just feels wrong to make this

[notmuch] patchwork test instance (was: Git feature branch)

I investigated some patch/issue trackers over the weekend. Here's my summary/reply. The executive summary is that http://patchwork.madduck.net/project/notmuch/list/ now exists. I have not really used it for anything real, so if some of you feel inclined to give it a shot, sign up and triage away!

Re: [notmuch] Request for high-priority improvements to notmuch

also sprach sebast...@sspaeth.de sebast...@sspaeth.de [2010.02.02.0929 +1300]: YES PLEASE :-). notmuch seems designed to work in an ecosystem of surrounding scripts, feeding data in and out. But we are all currently limited to regexes for that. And heck, I hard a hard time understanding why

[notmuch] [PATCH] Enforce foldmethod=manual when showing messages in vim

-by: martin f. krafft madd...@debian.org --- vim/plugin/notmuch.vim |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim index a226f20..2f9b05c 100644 --- a/vim/plugin/notmuch.vim +++ b/vim/plugin/notmuch.vim @@ -421,6 +421,7 @@ function

Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

also sprach Servilio Afre Puentes servi...@gmail.com [2010.02.04.1714 +1300]: In the second link, the links with the text commitdiff provide it, and you have the Atom and RSS feeds at the bottom. As I see it, the feeds have links to the commitdiffs, but that's not quite the same as having the

Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

also sprach Servilio Afre Puentes servi...@gmail.com [2010.02.04.1918 +1300]: If there is indeed an RSS/Atom feed on gitweb that includes the diffs inline, please give me the URL; I can't fine ond. Can't see that even in the code. Carl, could you set up notmuch-comm...@notmuchmail.org and

[notmuch] patchwork now auto-updates patches from Git (was: Git feature branch)

also sprach martin f krafft madd...@madduck.net [2010.02.04.1650 +1300]: - … which brings me to my second point: there are certain things that patchwork can do, at least in theory: * mark patches accepted when they hit your (canonical) master branch * mark patches rfc when

Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

also sprach Carl Worth cwo...@cworth.org [2010.02.07.1156 +1300]: Sorry to burden you, but since you want to continue maintaining the infrastructure, that's just what I have to do. ;) No burden at all. I don't really care to do everything alone. I just want to ensure we keep things

Re: [notmuch] patchwork test instance

also sprach martin f krafft madd...@madduck.net [2010.02.02.1131 +1300]: I investigated some patch/issue trackers over the weekend. Here's my summary/reply. The executive summary is that http://patchwork.madduck.net/project/notmuch/list/ now exists. I have not really used it for anything

Re: [notmuch] patchwork test instance

also sprach David Bremner brem...@unb.ca [2010.02.10.2149 +1300]: I'm not sure what merging patches means here; some kind of squash operation? Anyway it seemed to me that every every patch series that I looked at was broken into individual patches. Maybe I am just unlucky, or does patchwork

Re: [notmuch] notmuch reply template

also sprach Sebastian Spaeth sebast...@sspaeth.de [2010.02.12.0254 +1300]: I've had enough of the On a sunny Sunday the 30th in timezone wurgs, male human X with mail address z hit the reply button bar microseconds after 1970 while being at latitude foo: type of reply template in

Re: [notmuch] [PATCH] notmuch: Respect maildir message flags

also sprach Stewart Smith stew...@flamingspork.com [2010.02.16.1458 +1300]: + case 'R': /* replied */ + notmuch_message_add_tag (message, answered); + break; 'r' means replied, not 'answered'. + case 'T': /* trashed */ +

Re: [notmuch] [PATCH] notmuch: Respect maildir message flags

also sprach Stewart Smith stew...@flamingspork.com [2010.02.16.1521 +1300]: What about putting them all in there except for the seen tag, with the seen tag dictating if it gets marked 'unread' or not? I cannot imagine where somebody would want this not to be the case... it was bad enough

Re: [notmuch] Mail in git

also sprach Stewart Smith stew...@flamingspork.com [2010.02.15.1329 +1300]: What about adding more mail to the archive? So the way I think is that you use a Maildir for day to day mail (e.g. delivery) and every so often you run some magic command that takes old mail out of the Maildir and

Re: [notmuch] Mail in git

also sprach Ben Gamari bgam...@gmail.com [2010.02.18.0834 +1300]: Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 2010: But if we have notmuch as a cache of the tags, then don't we already know the tree objects that need updating? Yes, we would probably need some

Re: [notmuch] Mail in git

also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1401 +1300]: If we keep ancestry though, we are reusing existing working code for backup (git-pull :) This is one of the reasons I feel it's important we keep it. And as is stated below, the storage overhead is minimal. Absolutely;

Re: [notmuch] nested tag trees (was: Mail in git)

[Taking a private message back to the list with permission] also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1620 +1300]: This is a very good point. From what I've read about the database format, I can't think of any way that reverse dependencies could be easily found, unfortunately. If

Re: [notmuch] nested tag trees (was: Mail in git)

also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1744 +1300]: I believe you would. The problem isn't the messages (well, that's a problem too), it's the fact that the tree (e.g. tab) objects which reference the messages are immutable (I believe). This presents us with the difficult

Re: [notmuch] Git ancestry and sync problems (was: Mail in git)

also sprach ra...@free.fr ra...@free.fr [2010.02.18.2134 +1300]: I don't understand the problem. Why not just letting all inbox mails in a regular Maildir, and use git only when they have been explicit archived? I don't archive my mail. I would like to be able to bring mails from the past back

[notmuch] notmuch for mutt (was: vim client)

also sprach Ruben Pollan mes...@sindominio.net [2010.02.19.2112 +0100]: 1. will there be a usable ncurses or mutt version that supports notmuch anytime soon? I started to work on that I while ago. I didn't hack on it for a while, but I hope I'll return to it soon. Anyway to create a

Re: [notmuch] patchwork test instance

also sprach Carl Worth cwo...@cworth.org [2010.02.24.2010 +0100]: Carl, would you consider bouncing messages to addresses like patchwork+rejec...@patchwork.notmuchmail.org? That would make it trivial for me to write glue to update patchwork automatically. Now you're talking my language,

Re: [notmuch] Initial tagging

might want a message associated with multiple contexts. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things

Re: [notmuch] [PATCH] notmuch-reply: Use a shorter 'On, X Y wrote:' line

also sprach Sebastian Spaeth sebast...@sspaeth.de [2010.03.02.1337 +0100]: Previously, we would output: 'On Thu, 25 Feb 2010 14:32:54 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote:' now it is: 'On 2010-02-25, Sebastian Spaeth wrote:' In case we don't find a '' (as indicator for

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

also sprach Paul R paul.r...@gmail.com [2010.03.02.1626 +0100]: CouchDB databases can be replicated and synced in both directions. Conflicts are lazily handled. What does this mean? -- martin | http://madduck.net/ | http://two.sentenc.es/ fitter, healthier, more productive like a pig, in a

[notmuch] [PATCH] Do not segfault on empty mime parts

-CRITICAL **: g_mime_message_get_mime_part: assertion `GMIME_IS_MESSAGE (message)' failed Warning: Not indexing empty mime part. This is probably a bug that should get addressed in libgmime, but for not, my patch is an acceptable workaround. Signed-off-by: martin f. krafft madd...@madduck.net --- lib

Re: [notmuch] Debian package

also sprach Xavier Maillard x...@gnu.org [2010.03.05.0611 +0100]: I am using Debian GNU/linux SID and notmuch and I'd like to be bleading edge with notmuch. So I am trying to figure out whether someone is maintaining a Debian package against notmuch git repository or not. If the former, that's

Re: [notmuch] Notmuch shared library

also sprach Michal Sojka sojk...@fel.cvut.cz [2010.04.01.1310 +0200]: this can be solved by the following patch, but I don't know how portable it is. You can see the efect of this by Please avoid rpath. The better solution is probably to create a wrapper for notmuch, which prepends to

Re: [notmuch] Notmuch shared library

also sprach martin f krafft madd...@madduck.net [2010.04.01.1324 +0200]: Please avoid rpath. The better solution is probably to create a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. E.g. http://wiki.debian.org/RpathIssue -- martin | http://madduck.net/ | http://two.sentenc.es

Re: [PATCH] Mailstore abstraction v4 - part 2 (maildir synchronization)

also sprach Michal Sojka sojk...@fel.cvut.cz [2010.04.08.1713 +0200]: I'm working on the solution - if the mailstore cannot open the message with the name passed, it tries different names with different maildir flags. Wouldn't it be better to postpone synchronisation of the tags until

Re: [notmuch] Mail in git

also sprach Stewart Smith stew...@flamingspork.com [2010.02.17.1107 +0100]: On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith stew...@flamingspork.com wrote: Using fast-import is interesting. Does it update the working tree? The big thing I wanted to avoid was creating a working tree

patchwork

Are people using http://patchwork.notmuchmail.org at all? The reason of my asking is that it receives quite a lot of spam and I do not need to invest this time for a service noone uses. -- martin | http://madduck.net/ | http://two.sentenc.es/ 'oh, that was easy,' says Man, and for an encore

Re: [notmuch] Notmuch performance (literally, in my case)

also sprach martin f krafft madd...@madduck.net [2010.03.16.1900 +0100]: I use ext4 with data=ordered, and while notmuch is writing the Xapian database, most I/O stalls on the machine: - Firefox does not get any mouse events - Vim blocks writing the viminfo file - All disk operations

[notmuch] indexing encrypted messages (was: OpenPGP support)

also sprach Jameson Graef Rollins [2009.11.26.1901 +1300]: > I would really like to start using notmuch with emacs beyond just > testing, but I really need to be able to handle/read/send mail with > PGP/MIME encoded attachments. Do folks have any suggestions on how to > handle this? Is there a

[notmuch] Quick thoughts on a notmuch daemon

also sprach Carl Worth [2009.12.08.2001 +1300]: > One concept in notmuch (compared to sup) is to (eventually) avoid people > having to go through that pain by their current mail client becoming > "notmuch enabled". For me, I had always liked composing email in emacs, > so I just have to add

[notmuch] notmuch and imap [musing, no code :)]

also sprach David Bremner [2009.12.17.0218 +1300]: > I agree that the labels-in-headers approach has some nice > advantages. I haven't thought through merging of tag lists, but > maybe that is no worse than other approaches. One thing that > worries me a bit is that notmuch updates tags often,

[notmuch] Threading

also sprach Carl Worth [2009.12.11.0639 +1300]: > On Wed, 9 Dec 2009 16:21:34 -0700, Mark Anderson > wrote: > > I was wondering if there's a way in notmuch to group un-associated > > threads into a single thread. > > There's certainly nothing like that in notmuch currently. > > Sup had

[notmuch] Quick thoughts on a notmuch daemon

also sprach Mike Hommey [2010.01.08.2106 +1300]: > I'm in \o_ (though I won't be in Wellington). I've been thinking > about a fuse filesystem on top of notmuch for a while. Grand news to see you interested! A FUSE filesystem is <25 functions to implement, and each

[notmuch] indexing encrypted messages (was: OpenPGP support)

also sprach Mike Hommey [2010.01.08.2109 +1300]: > That may leak decrypted form in the xapian index, though in > a split manner. But that'd still be a problem IMHO. Not for me, since the index is stored on encrypted media. Thus, this should be off-by-default, but

[notmuch] indexing encrypted messages (was: OpenPGP support)

also sprach Ruben Pollan [2010.01.08.2221 +1300]: > I think that would be security hole. You should not store the > encrypted messages on a decrypted database. A solution whould be > to encrypt as well the xapian DB, but I think is too complex for > the use. As I said in <20100108091216.GC735 at

[notmuch] Quick thoughts on a notmuch daemon

also sprach Mike Hommey [2010.01.08.2220 +1300]: > FYI, I have a good experience writing fuse filesystems, both with > high-level and low-level APIs. I'd avise to use the low-level API, > which allows for better performance. I don't have any experience with FUSE yet,

[notmuch] Idea for storing tags

Folks, over in #notmuch, we just floated an idea that I'd like to get out to you. We've been debating storing tags for messages. Therefore I am cross-posting. Please forgive me. So far, there are two approaches: 1. External database, which has the downside of not being synchronisable with

[notmuch] Idea for storing tags

also sprach Scott Robinson [2010.01.12.1644 +1300]: > I wrote a script to store and sync my tags. > > * One filename per message-ID. > * Line-feed seperated tags in each file. > > Then the whole structure is controlled via git. > Conflict-resolution and sync comes for free. How do you

[notmuch] Potential problem using Git for mail (was: Idea for storing tags)

also sprach Scott Robinson [2010.01.12.1644 +1300]: > Then the whole structure is controlled via git. > Conflict-resolution and sync comes for free. I've just had a good think about this, also because the idea of abandoning IMAP and using Git has been around for a while and I have not really

[notmuch] Potential problem using Git for mail (was: Idea for storing tags)

also sprach Jameson Rollins [2010.01.13.0838 +1300]: > What about if just the tag information is stored in the > repository, and not the mail itself? In that case only the user > would be pushing into the repo and you wouldn't have to worry > about the DoS scenario. I certainly would like the

[notmuch] Idea for storing tags

also sprach Scott Morrison [2010.01.12.1711 +1300]: > 1. synchronization of tag data with emails -- if they are in > a subfolder then it presents the issue of maintaining this > subfolder when managing emails (moving, deleting, duplicating etc) > and any .tag folder unaware clients are likely

[notmuch] Idea for storing tags

also sprach Scott Morrison [2010.01.13.1752 +1300]: > The problem with anything that is not universally supported is > that for a package that is to appeal to a wide userbase, most > don't know and don't care about the particulars of this IMAP > server vs that IMAP server. all they know it that

[notmuch] Idea for storing tags

also sprach Carl Worth [2010.01.14.1432 +1300]: > Yes. This approach requires some external means of synchronizing the > tags from one system to another. > > I don't understand what it would mean to have the mailstore and the > database out of synch here. This approach doesn't have the tags in

[notmuch] Potential problem using Git for mail (was: Idea for storing tags)

also sprach Asheesh Laroia [2010.01.14.2112 +1300]: > Sure. But the MDA doesn't need to do the commit immediately. Since > (presumably) we're using Maildir, the MDA on the mail receiving > server is going to generate filenames that won't cause conflicts. > So it's okay to leave the files

[notmuch] Idea for storing tags

also sprach Carl Worth [2010.01.15.1124 +1300]: > > You might have marked a message 'read' on one machine and if the two > > get out of sync on another machine, you might have the same message > > unread there. > > That's a different issue though. With two databases there's clearly the >

[notmuch] Threading

also sprach Carl Worth [2010.01.15.1108 +1300]: > > Reading is one thing. Information storage and organisation is > > another. After a message is delivered (and read) to my mailbox, > > it's really mine and I can (and should be able) to affix it and > > integrate it into my organisational scheme

[notmuch] Thoughts on notmuch and Lua

also sprach Carl Worth [2010.01.15.1200 +1300]: > > Lua has many advantages over other scripting languages when it > > comes to integration with a C program. It has a very clean and > > easy C API, the overhead of running Lua scripts is not noticable > > among other things. > > I've definitely

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

also sprach Asheesh Laroia [2010.01.21.1928 +1300]: > >I suppose that I never actually considered merges on the IMAP > >server side, but obviously the IMAP server has to work off a clone, > >and that means it needs to merge. > > It's not "merge" that's unsafe; that just builds a tree in the git

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

also sprach Asheesh Laroia [2010.01.25.1819 +1300]: > You say "Ouch" but you should know Dovecot *already* does this. I > don't mind interoperating with that. > > See http://wiki.dovecot.org/MailboxFormat/Maildir, section "Issues > with the specification", subsection "Locking". I term this theQ >

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

also sprach Sebastian Spaeth [2010.01.26.0249 +1300]: > While notmuchsync fullfils my needs, it is a kludge. It needs to > call "notmuch" for each mail where a MailDir flag has changed > (which can be quite often on an initial run, where most mails are > likely to be read), this can take a long,

[notmuch] proposal for more streamlined mail flow in notmuch

also sprach Jameson Rollins [2010.01.17.0949 +1300]: > I would like to put forth here a proposal for a couple of changes > to notmuch that I believe will considerably streamline message > handling and new message flow through notmuch. Notmuch is still > new and I believe it hasn't quite figured

[notmuch] Git feature branch

also sprach Carl Worth [2010.01.23.1010 +1300]: > Anyway, I'll be on vacation for the next few days, so will likely > not have much, (likely have not much?), time for patch merging. > > But I *am* anxious to get back to the backlog. And in the > meantime, I really appreciate others merging and

[notmuch] Git feature branch

also sprach micah anderson [2010.01.27.1124 +1300]: > Couldn't all of this be done without moving the existing git > repository (don't forget that transition is a cost)? Those who > wish to put together these proposed branches go ahead and do so, > publishing those wherever they like

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Jameson Rollins [2010.01.26.1046 +1300]: > > For example, I might have: > > > > ~/.notmuch-config: > > > > [database] > > path=/home/pioto/mail > > ... > > [tags] > > pioto at pioto.org/INBOX.ListMail.notmuch = notmuch > > > > So, a 'tags' section, where each

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Jameson Rollins [2010.01.27.0603 +1300]: > > This is getting involved. > > > > Maybe I'm missing something in this thread; but, why couldn't these complex > > and > > context-sensitive decisions be delegated to sub-processes? ala git hooks? > > I think this idea is completely

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach martin f krafft [2010.01.28.1834 +1300]: > > That's not going to work so well if so. > > Why not? Works fine for me with the vim plugin... Now I get it. I was talking about id:20100114084713.GA22273 at harikalardiyari Sorry, I *am* new to notmuch ;) -- martin | http:/

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Ben Gamari [2010.01.29.0949 +1300]: > > I guess I just dislike having to run notmuch new regularly, > > rather than integrating the database more closely with the mail > > flow. > > > Sounds like you need to add a line to crontab. It still feels like a hack. It's a bit like making

[notmuch] Some thoughts about notmuch sync with other agents

also sprach Paul R [2010.01.28.0316 +1300]: > As you see, I advocate a NotMuch <-> IMAP synchronisation ASAP :) Given the limitations of IMAP (non-transactional, non-standard keywords implementation, ?), I think chances of this are rapidly diminishing, but I'd love to be proven wrong. > First

[notmuch] patchwork test instance (was: Git feature branch)

I investigated some patch/issue trackers over the weekend. Here's my summary/reply. The executive summary is that http://patchwork.madduck.net/project/notmuch/list/ now exists. I have not really used it for anything real, so if some of you feel inclined to give it a shot, sign up and triage away!

[notmuch] Request for high-priority improvements to notmuch

also sprach sebastian at sspaeth.de [2010.02.02.0929 +1300]: > YES PLEASE :-). notmuch seems designed to work in an ecosystem of > surrounding scripts, feeding data in and out. But we are all currently > limited to regexes for that. And heck, I hard a hard time understanding > why all hell broke

[notmuch] Request for high-priority improvements to notmuch

also sprach Scott Robinson [2010.02.02.1043 +1300]: > > YES PLEASE :-). notmuch seems designed to work in an ecosystem of > > surrounding scripts, feeding data in and out. But we are all currently > > limited to regexes for that. And heck, I hard a hard time understanding > > why all hell broke

[notmuch] [PATCH] Enforce foldmethod=manual when showing messages in vim

-by: martin f. krafft --- vim/plugin/notmuch.vim |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim index a226f20..2f9b05c 100644 --- a/vim/plugin/notmuch.vim +++ b/vim/plugin/notmuch.vim @@ -421,6 +421,7 @@ function! s:NM_cmd_show(words

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

also sprach Marten Veldthuis [2010.02.04.0353 +1300]: > > Like this? http://notmuchmail.org/recentchanges/ > > No, more like this: http://git.notmuchmail.org/git/notmuch-wiki To my knowledge, neither of these two give you diffs. This is what a post-receive hook offers. It's trivial to do with

[notmuch] Git feature branch

also sprach Carl Worth [2010.02.04.1605 +1300]: > > maint/? the stable release > > master/ ? the stablising head > > next/ ? testing branch > > pu/ ? patch integration branch (proposed updates) > > I'm not a fan of this scheme, (or maybe I've just never quite understood >

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

also sprach Servilio Afre Puentes [2010.02.04.1714 +1300]: > In the second link, the links with the text "commitdiff" provide > it, and you have the Atom and RSS feeds at the bottom. As I see it, the feeds have links to the commitdiffs, but that's not quite the same as having the diffs inline.

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

also sprach Servilio Afre Puentes [2010.02.04.1918 +1300]: > > If there is indeed an RSS/Atom feed on gitweb that includes the > > diffs inline, please give me the URL; I can't fine ond. > > Can't see that even in the code. Carl, could you set up notmuch-commits at notmuchmail.org and enable

[notmuch] patchwork now auto-updates patches from Git (was: Git feature branch)

also sprach martin f krafft [2010.02.04.1650 +1300]: > - ? which brings me to my second point: there are certain things > that patchwork can do, at least in theory: > > * mark patches accepted when they hit your (canonical) master > branch > * mark patches rfc whe

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

also sprach Carl Worth [2010.02.07.1156 +1300]: > > Sorry to burden you, but since you want to continue maintaining > > the infrastructure, that's just what I have to do. ;) > > No burden at all. I don't really care to do everything alone. > I just want to ensure we keep things centralized

[notmuch] hack to retag a directory

also sprach David Bremner [2010.02.07.1238 +1300]: > I have to say that merge conflicts are not very much fun. I tend > to do a certain amount of oh, take all the changes from the > server. I wonder if the approach that someone else mentioned of > keeping a file tags/message-id with the

[notmuch] patchwork test instance

also sprach martin f krafft [2010.02.02.1131 +1300]: > I investigated some patch/issue trackers over the weekend. Here's my > summary/reply. > > The executive summary is that > http://patchwork.madduck.net/project/notmuch/list/ now exists. > I have not really used it for

[notmuch] patchwork test instance

also sprach David Bremner [2010.02.10.2149 +1300]: > I'm not sure what merging patches means here; some kind of squash > operation? Anyway it seemed to me that every every patch series > that I looked at was broken into individual patches. Maybe I am > just unlucky, or does patchwork really not

[notmuch] patchwork test instance

also sprach Sebastian Spaeth [2010.02.10.2225 +1300]: > "notmuch dump tag:notmuch and tag:patch" could be used to construct a > list of "accepted", "willnottakeit","superseded" and "pending" lists or > whatever. If that list were made accessible somewhere, this would be > super useful. At least

[notmuch] notmuch reply template

also sprach Sebastian Spaeth [2010.02.12.0254 +1300]: > I've had enough of the > > On a sunny Sunday the 30th in timezone , male human with mail > address hit the reply button microseconds after 1970 while being > at latitude : > > type of reply template in notmuch. :-) > > May I

[notmuch] [PATCH] notmuch: Respect maildir message flags

also sprach Stewart Smith [2010.02.16.1458 +1300]: > + case 'R': /* replied */ > + notmuch_message_add_tag (message, "answered"); > + break; 'r' means replied, not 'answered'. > + case 'T': /* trashed */ > + notmuch_message_add_tag (message,

[notmuch] [PATCH] notmuch: Respect maildir message flags

also sprach Stewart Smith [2010.02.16.1521 +1300]: > What about putting them all in there except for the seen tag, with > the seen tag dictating if it gets marked 'unread' or not? I cannot > imagine where somebody would want this not to be the case... it > was bad enough discovering 100,000

[notmuch] Mail in git

also sprach Stewart Smith [2010.02.15.1329 +1300]: > What about adding more mail to the archive? > > So the way I think is that you use a Maildir for day to day mail > (e.g. delivery) and every so often you run some magic command that > takes old mail out of the Maildir and stores it in the git

[notmuch] Mail in git

also sprach Ben Gamari [2010.02.18.0834 +1300]: > Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 > 2010: > > But if we have notmuch as a cache of the tags, then don't we > > already know the tree objects that need updating? Yes, we would > > probably need some consistency

[notmuch] Mail in git

also sprach Ben Gamari [2010.02.18.1339 +1300]: > Yes, it would be linear in number of tags. I suppose if messages > weren't stored in the top-level tree nodes, then it would still be > linear, although with a slope equal to the reciprocal of the fan-out. > This has the potential to be very

[notmuch] Mail in git

also sprach Ben Gamari [2010.02.18.1401 +1300]: > > If we keep ancestry though, we are reusing existing working code for > > backup (git-pull :) > > This is one of the reasons I feel it's important we keep it. And as is > stated below, the storage overhead is minimal. Absolutely; Stewart

[notmuch] Git ancestry and sync problems (was: Mail in git)

also sprach martin f krafft [2010.02.18.1500 +1300]: > > > If we keep ancestry though, we are reusing existing working code for > > > backup (git-pull :) > > > > This is one of the reasons I feel it's important we keep it. And as is > > stated be

[notmuch] nested tag trees (was: Mail in git)

also sprach Ben Gamari [2010.02.18.1519 +1300]: > > So retagging is really just writing a new tree with a modified list > > of references. > > > Certainly, however if you have a large tag (>100,000 messages), this > list of reference could easily be tens of megabytes. For this reason, it > seems

[notmuch] nested tag trees (was: Mail in git)

also sprach martin f krafft [2010.02.18.1548 +1300]: > True ? iff we find a way to enumerate trees referencing a given > blob or tree so that we can walk up the hierarchy. I could look > right now, but I am about to cross half of the globe tomorrow, so > I have other things I s

[notmuch] nested tag trees (was: Mail in git)

[Taking a private message back to the list with permission] also sprach Ben Gamari [2010.02.18.1620 +1300]: > This is a very good point. From what I've read about the database > format, I can't think of any way that reverse dependencies could be > easily found, unfortunately. If there really is

[notmuch] nested tag trees (was: Mail in git)

also sprach Ben Gamari [2010.02.18.1744 +1300]: > I believe you would. The problem isn't the messages (well, that's > a problem too), it's the fact that the tree (e.g. tab) objects > which reference the messages are immutable (I believe). This > presents us with the difficult circumstance of

[notmuch] Git ancestry and sync problems (was: Mail in git)

also sprach racin at free.fr [2010.02.18.2134 +1300]: > I don't understand the problem. Why not just letting all "inbox" > mails in a regular Maildir, and use git only when they have been > explicit archived? I don't archive my mail. I would like to be able to bring mails from the past back into

  1   2   >