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

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

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

[notmuch] Mail in git

also sprach Stewart Smith [2010.02.17.1107 +0100]: > On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith 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 (another million > > inodes being

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

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

also sprach Michal Sojka [2010.04.12.1347 +0200]: > > Wouldn't it be better to postpone synchronisation of the tags > > until after emacs is done with the message? > > Theoretically, it would be possible, but if, for some reason, the > synchronization step would not happen, then the tags in the

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

also sprach Michal Sojka [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 after emacs is

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

[notmuch] Notmuch shared library

also sprach martin f krafft [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/ a common m

[notmuch] Notmuch shared library

also sprach Michal Sojka [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 LD_LIBRARY_PATH. --

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

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

also sprach Aneesh Kumar K. V [2010.03.16.1810 +0100]: > Ext3 fsync related issue is a know problem due to the way journalling is > handled in ext3. The solution for that would be data=writeback ( with > its loss of data integrity ) or not yet upstreamed data=guarded. Another > option would be

[notmuch] Debian package

also sprach Xavier Maillard [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 nice.

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

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

also sprach Paul R [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 cage, on

[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 --- lib/index.cc |5

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

also sprach Sebastian Spaeth [2010.03.02.1337 +0100]: > Previously, we would output: 'On Thu, 25 Feb 2010 14:32:54 +0100, > Sebastian Spaeth wrote:' now it is: 'On > 2010-02-25, Sebastian Spaeth wrote:' > > In case we don't find a '<' (as indicator for 'Realname '), > we still use the whole

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

[notmuch] What's so great about notmuch?

also sprach Carl Worth [2010.02.26.2108 +0100]: >What's your favorite thing about notmuch? a. that it's an important step forward towards a completely tag-based e-mail setup b. that it is implemented with a library, a UI, and clients on top, rather than directly as a GUI. ;) >

[notmuch] Initial tagging

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

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

[notmuch] patchwork test instance

also sprach Carl Worth [2010.02.24.2008 +0100]: > I agree that in its current form it's not useful, (it seems to be just a > long list of the patches that have ever been submitted). > > I seem to recall Martin saying that patches that get accepted will be > automatically detected and removed

[notmuch] patchwork test instance

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

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,

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

also sprach Ruben Pollan [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 proper good

[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

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

also sprach Ben Gamari [2010.02.18.1810 +1300]: > Yeah, this is a bit of a bummer. This is really a stretch, but I wonder > if the git folks would accept patches/minor database semantics changes > in the name of making git more flexible as a general purpose object > database. I really doubt it,

[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

[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] 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 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)

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] 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] 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] 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.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

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] 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

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

[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] [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,

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] [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

[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] 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] 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

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

[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

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] 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

[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] 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

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

[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 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] 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 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 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] 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 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] [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] 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] 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] 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] [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

[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!

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] 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] 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 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 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] 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

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

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 |

[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] 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 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] 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 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

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] proposal for more streamlined mail flow in notmuch

also sprach Jameson Rollins jroll...@finestructure.net [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

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

[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

[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] 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] 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] 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

  1   2   >