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
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
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
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 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
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
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
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.
--
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
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
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
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.
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
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
-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
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
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
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
-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
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. ;)
>
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
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
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
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 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,
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
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
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,
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.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
[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
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
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
> > stated be
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
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
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
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
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
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
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;
[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
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
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
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,
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
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 */
+
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
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
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
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
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
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
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
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
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
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
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
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
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.
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 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
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
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
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
-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
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
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!
-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
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
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 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
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
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:/
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
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
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
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
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
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
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
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 |
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
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
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,
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
>
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
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
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
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
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
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
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
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
>
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
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
1 - 100 of 117 matches
Mail list logo
