also sprach martin f krafft [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 op
also sprach martin f krafft [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 op
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 goe
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 go
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
also sprach Stewart Smith [2010.02.17.1107 +0100]:
> On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith
> 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 created is not
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
>
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 d
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
>
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 d
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
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.
--
marti
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
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.
--
marti
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 to
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 to
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.
h
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.
h
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 antibiotic
-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 |
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 from
-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 |
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 antibioti
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 from
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. ;)
>What
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. ;)
>What
ers and messages. 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
`- De
ers and messages. 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
`- De
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 from
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 from
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!
also sprach Carl Worth [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, Martin!
>
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 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 client
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, bu
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
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, bu
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 being
[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 n
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 shou
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
also sprach 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 into cir
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
> > stat
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 mention
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 reason
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 chec
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 being
[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 n
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 shou
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
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
> > stat
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 mention
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 reason
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 chec
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 r
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 unread
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 r
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, "d
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 unread
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, "d
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 suggest
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 suggest
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 it
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 u
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 f
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 it
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 u
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 f
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 appropria
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 enough
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 appropria
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 enough
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
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
th
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
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. Y
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
>
also sprach David Bremner [2010.02.04.0924 +1300]:
> > PS: speaking of prefixes, how about remving the subject prefix of
> > this list in general? ;)
>
> I used to agree, but in notmuch, I actually find it convenient to have
> threads marked by mailing list. Perhaps this will change if/when my
>
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 G
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-comm...@notmuchmail.org and enable
the co
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. Yo
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
>
also sprach David Bremner [2010.02.04.0924 +1300]:
> > PS: speaking of prefixes, how about remving the subject prefix of
> > this list in general? ;)
>
> I used to agree, but in notmuch, I actually find it convenient to have
> threads marked by mailing list. Perhaps this will change if/when my
>
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 G
ned-off-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_
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 ou
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
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!
ned-off-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_
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 of
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 ou
also sprach 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 all hell broke out
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!
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 of
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 ma
also sprach Servilio Afre Puentes [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
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 | h
also sprach James Westby [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 | http://madduck.net/ | http://two.s
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 inde
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 ke
1 - 100 of 156 matches
Mail list logo
