Quoth Sascha Silbe on Jun 26 at 12:13 am:
> Austin Clements writes:
> > On Sun, 24 Jun 2012, Sascha Silbe wrote:
>
> ["notmuch new" listing every directory, even if it's unchanged]
> > I haven't looked over your patches yet, but this result surprises me.
> > Could you explain your setup a little
Quoth Sascha Silbe on Jun 26 at 12:13 am:
> Austin Clements writes:
> > On Sun, 24 Jun 2012, Sascha Silbe wrote:
>
> ["notmuch new" listing every directory, even if it's unchanged]
> > I haven't looked over your patches yet, but this result surprises me.
> > Could you explain your setup a little
A lot of code is duplicated from maildir, I don't think I handled all
those errors correctly, and I didn't report any progress.
Signed-off-by: Ethan Glasser-Camp
---
notmuch-new.c | 299 +++--
1 file changed, 289 insertions(+), 10 deletions(-)
These need to be improved, rather than hard-coding byte offsets.
Signed-off-by: Ethan Glasser-Camp
---
test/mbox | 59 +
test/notmuch-test |1 +
2 files changed, 60 insertions(+)
create mode 100755 test/mbox
diff --git a/test/mb
Signed-off-by: Ethan Glasser-Camp
---
lib/mailstore.c | 85 +++
1 file changed, 85 insertions(+)
diff --git a/lib/mailstore.c b/lib/mailstore.c
index ae02c12..e8d9bc1 100644
--- a/lib/mailstore.c
+++ b/lib/mailstore.c
@@ -19,6 +19,7 @@
*/
This is part of notmuch-new refactor phase 1: make add_files stuff
safe for other backends. add_files_recursive is essentially a
maildir-crawling function that periodically adds files to the database
or adds filenames to remove_files or remove_directory lists. I don't
see an easy way to adapt add_f
This is just a quick hack to get started on adding an mbox backend.
The fact that the default maildir is scanned "automagically" is a
little weird, but it doesn't do any harm unless you decide to put mail
there that you really don't want indexed.
Signed-off-by: Ethan Glasser-Camp
---
notmuch-cl
Instead of assuming that the mailstore doesn't store its absolute
filenames, we use a symlink that can change back and forth. As long as
filenames contain this symlink, they can work in either the real
database, or the current snapshot.
Signed-off-by: Ethan Glasser-Camp
---
test/atomicity |
corpus.mail has already been processed by notmuch-new, so it seems
like a good target to cache, but since filenames are no longer being
stored relative to the database, it isn't. Recopy on each test, or
else filenames from other tests will show up.
Signed-off-by: Ethan Glasser-Camp
---
test/test
This fixes all tests except atomicity, which should be next.
Signed-off-by: Ethan Glasser-Camp
---
test/emacs |2 +-
test/json|4 ++--
test/maildir-sync|7 ---
test/multipart |4 ++--
test/new
A better fix would probably be based on scheme.
Signed-off-by: Ethan Glasser-Camp
---
lib/message.cc | 51 ++-
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index c9857f5..8ecec71 100644
--- a/lib/
This commit breaks a bunch of tests; fixes follow.
Signed-off-by: Ethan Glasser-Camp
---
notmuch-new.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 938ae29..1f11b2c 100644
--- a/notmuch-new.c
+++ b/notmuch-
_notmuch_message_ensure_filename_list converts "relative" paths, such
as those stored in Xapian until now, to "absolute" paths. However,
URLs are already absolute, and prepending the database path will just
confuse matters.
Signed-off-by: Ethan Glasser-Camp
---
lib/message.cc | 14 +++-
No code uses this yet.
Signed-off-by: Ethan Glasser-Camp
---
lib/mailstore.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/lib/mailstore.c b/lib/mailstore.c
index 48acd47..ae02c12 100644
--- a/lib/mailstore.c
+++ b/lib/mailstore.c
@@
Seeing as there is no glib-standard way to parse URIs, an external
library is needed. This commit introduces another program in compat/
and a stanza in ./configure to test if uriparser is there.
Signed-off-by: Ethan Glasser-Camp
---
Makefile.local |2 +-
compat/have_uriparser.c |
This commit introduces the mailstore module which provides two
functions, notmuch_mailstore_open and notmuch_mailstore_close. These
functions are currently just stub calls to fopen and fclose, but later
can be made more complex in order to support mail storage systems
where one message might not be
Hi guys,
Sorry for dropping off the mailing list after I sent my last patch series
(http://notmuchmail.org/pipermail/notmuch/2012/009470.html). I haven't had the
time or a stable enough email address to really follow notmuch development :)
I signed onto #notmuch a week or two ago and asked what
Austin Clements writes:
> On Sun, 24 Jun 2012, Sascha Silbe wrote:
["notmuch new" listing every directory, even if it's unchanged]
> I haven't looked over your patches yet, but this result surprises me.
> Could you explain your setup a little more? How much mail do you have
> and across how ma
On Sun, 24 Jun 2012, Sascha Silbe wrote:
> All the time I thought what makes "notmuch new" so abysmally slow is the
> stat() for each maildir. But as it continued to be slow even after I
> moved most mails out of 'new' (into 'new-20120624'), I strace'd notmuch
> and noticed it listed even unchange
I've noticed a problem related to handling of ical attachments. I'm
using Notmuch 0.13 on Emacs 23.3.1. I've done some basic
troubleshooting.
The problem arises with emails from Concur that include an ical
attachment being viewed with the notmuch message viewer. The problems
are:
1. When openi
Dear All,
someone can give an advice? I have many emails containing
attachment. This is typically an output of copy-machine, which fragments
a scan into multiple attachments.
I'd like to extract those attached files in a one batch into a specific
directory. Is there any way how to programmatical
On Sun, 24 Jun 2012, Sascha Silbe wrote:
> All the time I thought what makes "notmuch new" so abysmally slow is the
> stat() for each maildir. But as it continued to be slow even after I
> moved most mails out of 'new' (into 'new-20120624'), I strace'd notmuch
> and noticed it listed even unchange
I've noticed a problem related to handling of ical attachments. I'm
using Notmuch 0.13 on Emacs 23.3.1. I've done some basic
troubleshooting.
The problem arises with emails from Concur that include an ical
attachment being viewed with the notmuch message viewer. The problems
are:
1. When openi
On Mon, Jun 25 2012, Jameson Graef Rollins wrote:
> I hacked up something simple below that will extract parts from messages
> matching a search term into the current directory (tested).
Improved/bug fixed version attached.
jamie.
jnotmuch-extract-parts
Description: Binary data
pgpJ9MjqSSAJ
chment was scrubbed...
Name: jnotmuch-extract-parts
Type: application/octet-stream
Size: 1046 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20120625/cfab64bf/attachment.obj>
-- next part --
A non-text attachment was scrubbed.
On Mon, Jun 25 2012, David Belohrad wrote:
> someone can give an advice? I have many emails containing
> attachment. This is typically an output of copy-machine, which fragments
> a scan into multiple attachments.
>
> I'd like to extract those attached files in a one batch into a specific
> direct
nter += 1
print filename
with open(filename, 'wb') as f:
f.write(part.get_payload(decode=True))
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20120625/e5b2a3de/attachment.pgp>
Tomi Ollila writes:
> Some C compilers are stricter when it comes to (tentative) definition
> of a variable -- in those compilers introducing variable without 'extern'
> keyword always allocates new 'storage' to the variable and linking all
> these modules fails due to duplicate symbols.
LGTM
Dear All,
someone can give an advice? I have many emails containing
attachment. This is typically an output of copy-machine, which fragments
a scan into multiple attachments.
I'd like to extract those attached files in a one batch into a specific
directory. Is there any way how to programmatical
Tomi Ollila writes:
> Some C compilers are stricter when it comes to (tentative) definition
> of a variable -- in those compilers introducing variable without 'extern'
> keyword always allocates new 'storage' to the variable and linking all
> these modules fails due to duplicate symbols.
LGTM
_
2012/6/24 Tomi Ollila :
> Some C compilers are stricter when it comes to (tentative) definition
> of a variable -- in those compilers introducing variable without 'extern'
> keyword always allocates new 'storage' to the variable and linking all
> these modules fails due to duplicate symbols.
>
> Th
The NAME section in manpages generally doesn't start with capital
letter (unless the word is 'proper noun') and doesn't end with
period. Notmuch manual pages now matches that "format".
---
See http://notmuchmail.org/manpages/ for reference.
man/man1/notmuch-config.1 |2 +-
man/man1/no
32 matches
Mail list logo
