[notmuch] indexing mail?
On Thu, 14 Jan 2010 18:13:53 +0100, Arvid wrote: > On Thu, 14 Jan 2010 09:38:00 +0100, Arvid Picciani wrote: > > > on the first run (when no .notmuch is there yet), it finds some > > messages, but doesn't index them either. Yuk! I logged-in via Gmail's web interface and found that I have some new messages which are not being picked by Notmuch. > the offending commit is 2c4555f1a56602ff1dd55a63699810522ba4d91e > > from readdir (3): > > "Currently, only some file systems (among them: Btrfs, ext2, ext3, > and ext4) have full support returning the file >type in d_type. All applications must properly handle a return > of DT_UNKNOWN." I am using XFS, which always returns DT_UNKNOWN. Taking into account that there is a good deal of people using filesystems other than the ones you mention, and that other non-linux filesystems may also return DT_UNKNOWN, in my opinion there should be a fall-back. I will try to post a patch Anytime Soon?. Also, I have the feeling that the "d_type" field from "struct dirent" may not be available in some OSes because it is a BSD extension. Cheers, -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100114/c182949a/attachment.pgp>
Re: [notmuch] indexing mail?
On Thu, 14 Jan 2010 18:13:53 +0100, Arvid wrote: > On Thu, 14 Jan 2010 09:38:00 +0100, Arvid Picciani wrote: > > > on the first run (when no .notmuch is there yet), it finds some > > messages, but doesn't index them either. Yuk! I logged-in via Gmail's web interface and found that I have some new messages which are not being picked by Notmuch. > the offending commit is 2c4555f1a56602ff1dd55a63699810522ba4d91e > > from readdir (3): > > "Currently, only some file systems (among them: Btrfs, ext2, ext3, > and ext4) have full support returning the file >type in d_type. All applications must properly handle a return > of DT_UNKNOWN." I am using XFS, which always returns DT_UNKNOWN. Taking into account that there is a good deal of people using filesystems other than the ones you mention, and that other non-linux filesystems may also return DT_UNKNOWN, in my opinion there should be a fall-back. I will try to post a patch Anytime Soon™. Also, I have the feeling that the "d_type" field from "struct dirent" may not be available in some OSes because it is a BSD extension. Cheers, -- Adrian Perez de Castro Igalia - Free Software Engineering signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] SWIG (and particularly Python) bindings
On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote: > Regardless, I thought it might be nice to have access to the notmuch > backend from a language other than C (preferably my high-level language > of choice, python) [...] Funny, I was just doing the same: a Python binding. Haha, so now we have two just-backed Python bindings. What should we do? > [...] To this end, I took a few hours today acquainting > myself with SWIG and produced these bindings for Python. Unfortunately, > it doesn't appear that SWIG has particularly good support for > object-oriented C [...] I already used SWIG sometimes in the past (and did not like it a lot), so my binding is using Cython [*] (which is exactly like Pyrex plus some extra features), so the binding is partly manual. > While the bindings are currently in the form of a patch to notmuch > (creating a top-level swig directory in the source tree), they could > certainly be moved out-of-tree if the powers that be don't feel it > appropriate to include them. [...] Same here, see attached patch. It is currently unfinished, and I was just about to add support for iterating notmuch_threads_t and other similar structures. I can also publish a Git repo with the entire branch, just drop me a line if you want me to do that. > [...] Unfortunately, the build system is currently almost entirely > independent from the notmuch build system. If these are to be > included in-tree, I would be curious to hear people have > to say about how we might integrate it into the sup build system. ^^^ (Mmmh, I suppose you mean "notmuch build system" there :P) Mine is a little more cooked, as I have added a distutils "setup.py" script. The bad news is that Python modules need to be compiled as relocatable object files (-fPIC to teh rescue!), and the linker will refuse to link the generated code with "notmuch.a" -- so I am instructing distutils to compile *all* sources again. Not nice. BTW, I think that if more bindings start to appear, Notmuch might be built as a shared library, to avoid duplicating it everywhere. One option may be using *just* libtool but not the rest of auto-foo tools (for the record: I agree with Carl that they are slow and wicked). Regards, [*] http://www.cython.org/ -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: notmuch-python-wip.patch Type: text/x-patch Size: 16874 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091230/c367e416/attachment-0001.bin> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091230/c367e416/attachment-0001.pgp>
Re: [notmuch] SWIG (and particularly Python) bindings
On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote: > Regardless, I thought it might be nice to have access to the notmuch > backend from a language other than C (preferably my high-level language > of choice, python) [...] Funny, I was just doing the same: a Python binding. Haha, so now we have two just-backed Python bindings. What should we do? > [...] To this end, I took a few hours today acquainting > myself with SWIG and produced these bindings for Python. Unfortunately, > it doesn't appear that SWIG has particularly good support for > object-oriented C [...] I already used SWIG sometimes in the past (and did not like it a lot), so my binding is using Cython [*] (which is exactly like Pyrex plus some extra features), so the binding is partly manual. > While the bindings are currently in the form of a patch to notmuch > (creating a top-level swig directory in the source tree), they could > certainly be moved out-of-tree if the powers that be don't feel it > appropriate to include them. [...] Same here, see attached patch. It is currently unfinished, and I was just about to add support for iterating notmuch_threads_t and other similar structures. I can also publish a Git repo with the entire branch, just drop me a line if you want me to do that. > [...] Unfortunately, the build system is currently almost entirely > independent from the notmuch build system. If these are to be > included in-tree, I would be curious to hear people have > to say about how we might integrate it into the sup build system. ^^^ (Mmmh, I suppose you mean "notmuch build system" there :P) Mine is a little more cooked, as I have added a distutils "setup.py" script. The bad news is that Python modules need to be compiled as relocatable object files (-fPIC to teh rescue!), and the linker will refuse to link the generated code with "notmuch.a" -- so I am instructing distutils to compile *all* sources again. Not nice. BTW, I think that if more bindings start to appear, Notmuch might be built as a shared library, to avoid duplicating it everywhere. One option may be using *just* libtool but not the rest of auto-foo tools (for the record: I agree with Carl that they are slow and wicked). Regards, [*] http://www.cython.org/ -- Adrian Perez de Castro Igalia - Free Software Engineering Makefile |1 + python/.gitignore |2 + python/Makefile |6 + python/Makefile.local | 15 ++ python/notmuch.pyx| 397 + python/pyutil.h | 16 ++ python/setup.py | 89 +++ 7 files changed, 526 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 021fdb8..081d670 100644 --- a/Makefile +++ b/Makefile @@ -37,6 +37,7 @@ include Makefile.config include lib/Makefile.local include compat/Makefile.local +include python/Makefile.local include Makefile.local # The user has not set any verbosity, default to quiet mode and inform the diff --git a/python/.gitignore b/python/.gitignore new file mode 100644 index 000..7f0efa8 --- /dev/null +++ b/python/.gitignore @@ -0,0 +1,2 @@ +notmuch.c +build/ diff --git a/python/Makefile b/python/Makefile new file mode 100644 index 000..e1e5c43 --- /dev/null +++ b/python/Makefile @@ -0,0 +1,6 @@ + +all: python + +%: + make -C .. $@ + diff --git a/python/Makefile.local b/python/Makefile.local new file mode 100644 index 000..140a701 --- /dev/null +++ b/python/Makefile.local @@ -0,0 +1,15 @@ +dir=python + +python: $(dir)/build/.stamp + (cd $(dir) && python setup.py build) + touch $@ + +$(dir)/build/.stamp: lib/notmuch.a + +clean: clean-python + +clean-python: + $(RM) -r $(dir)/build + +.PHONY: clean-python python + diff --git a/python/notmuch.pyx b/python/notmuch.pyx new file mode 100644 index 000..f38b719 --- /dev/null +++ b/python/notmuch.pyx @@ -0,0 +1,397 @@ +#! /usr/bin/env python +# -*- coding: utf-8 -*- +# vim: fenc=utf-8 ft=pyrex +# +# Copyright © 2009 Adrian Perez +# +# Distributed under terms of the GPLv3 license. +# + +cdef extern from "talloc.h": + void* talloc_init(char *fmt, ...) + int talloc_free(void *ctx) + + +cdef extern from "pyutil.h": + # + # Utility macros + # + char** pyutil_alloc_strv(void *ctx, unsigned nitems) + + +cdef extern from "notmuch.h": + # + # Return status handling + # + ctypedef enum notmuch_status_t: + NOTMUCH_STATUS_SUCCESS + NOTMUCH_STATUS_OUT_OF_MEMORY + NOTMUCH_STATUS_READONLY_DATABASE + NOTMUCH_STATUS_XAPIAN_EXCEPTION + NOTMUCH_STATUS_FILE_ERROR + NOTMUCH_STATUS_FILE_NOT_EMAIL + NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID + NOTMUCH_STATUS_NULL_POINTER + NOTMUCH_STATUS_TAG_TOO_LONG + NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW + + char* notmuch_status_to_string(notmuch_status_t status) + + # + # notmuch_database_* -> notmuch.Database + # + ctypedef enum no
[notmuch] Requires g++, and something else?
On Tue, 1 Dec 2009 00:01:16 +, Scot wrote:
> Friends,
>
> I'm a brand new joiner to notmuch ('course so is nearly everyone).
>
> I just tried compiling, and I see:
>
> 1. g++ is also a 'dependency' though ./configure didn't catch it.
> 2. I 'make' breaks with the following error:
> .
> CXX lib/thread.o
> AR lib/notmuch.a
> CXX notmuch
> /usr/bin/ld: cannot find -lz
> collect2: ld returned 1 exit status
> make: *** [notmuch] Error 1
>
> This is a just-now git clone on a Ubuntu 9.10 machine which doesn't
> happen to have too much dev stuff loaded.
> Feel free to ignore this if it's been reported or it's otherwise 'known'
This is because you will need the development package for zlib, package
name is "zlib1g-dev", once you have the devel packages listed in the
README file plus this one you shoule be able of building NotMuch
successfully.
Good luck, and best regards,
--
Adrian Perez de Castro
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091201/2b4e110e/attachment.pgp>
Re: [notmuch] Requires g++, and something else?
On Tue, 1 Dec 2009 00:01:16 +, Scot wrote:
> Friends,
>
> I'm a brand new joiner to notmuch ('course so is nearly everyone).
>
> I just tried compiling, and I see:
>
> 1. g++ is also a 'dependency' though ./configure didn't catch it.
> 2. I 'make' breaks with the following error:
> .
> CXX lib/thread.o
> AR lib/notmuch.a
> CXX notmuch
> /usr/bin/ld: cannot find -lz
> collect2: ld returned 1 exit status
> make: *** [notmuch] Error 1
>
> This is a just-now git clone on a Ubuntu 9.10 machine which doesn't
> happen to have too much dev stuff loaded.
> Feel free to ignore this if it's been reported or it's otherwise 'known'
This is because you will need the development package for zlib, package
name is "zlib1g-dev", once you have the devel packages listed in the
README file plus this one you shoule be able of building NotMuch
successfully.
Good luck, and best regards,
--
Adrian Perez de Castro
Igalia - Free Software Engineering
signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Support for printing file paths in new command
On Mon, 23 Nov 2009 01:24:09 +0100, Carl wrote: > On Sat, 21 Nov 2009 01:17:18 +0100, Adrian Perez wrote: > > For very large mail boxes, it is desirable to know which files are being > > processed e.g. when a crash occurs to know which one was the cause. Also, > > it may be interesting to have a better idea of how the operation is > > progressing when processing mailboxes with big messages. > > > > This patch adds support for printing messages as they are processed by > > "notmuch new": > > Hey, that's pretty nice. Thanks! As a small improvement, I will send another patch in a while, which will avoid sending ANSI escapes when output is not a terminal, and print one file path per line in that case. > I've pushed this now, (and I'm almost tempted to make it the > default...). IMHO it would be nice to have the messages-per-second information as well in verbose mode before making it the default. I think I could cook up a patch for that, but printing messages-per-second would mean calling gettimeofday() for each processed file. Do you think that will be acceptable from a performance POV? (Of course using silent mode would still only call it once per second). Regards, -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091123/aba0f79c/attachment.pgp>
[notmuch] Segfault searching for tags
On Fri, 20 Nov 2009 12:32:41 +0100, Carl wrote: > On Thu, 19 Nov 2009 16:45:43 +0100, Adrian Perez de Castro igalia.com> wrote: > > The thing is that in notmuch_message_get_in_reply_to(), line 288, a NULL > > instance of Xapian::TermIterator is dereferenced. In my particular case, > > the culpript is a cache file of Claws-Mail, as seen in the following GDB > > session: > > Not quite NULL, (nor is it quite dereferencing---this is nasty C++ > overloading), but yeah, the idea is the same. We need to protect all of > our "calls" to this overloaded operator to not call it when the iterator > is equal to the value returned by termlist_end (). Well, of course you are right, it is an overloaded operator, which (unfortunately, IMHO) looks like a pointer dereference. That is exactly one of the things that I find more confusing about C++: it has features like operator overloading which look cool initially, but that in the end imply more complexity than needed. I can understand why you decided to wrap Xapian with a plain C API :) > On Thu, 19 Nov 2009 20:23:15 -0600, Jeffrey Ollie wrote: > > I straced some of the crashes, and the last file that was read before > > the crash was a malformed message. I've attached one of the messages. > > I've been using offlineimap to sync my gmail mailbox to my laptop so > > that I can use notmuch. offlineimap isn't the most stable program, > > but I'm not sure yet if offlineimap is causing the problem or if > > that's the way the message is in gmail. > > Thanks for the file. I never like to push code that I haven't tested, so > this was very helpful. > > Below is the patch that I just pushed which seems to do the trick. I can confirm that this patch avoids the segfault in my case, too. Thanks a lot for the quick fix. Best regards, -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091120/2f7e425e/attachment.pgp>
[notmuch] Segfault searching for tags
On Wed, 18 Nov 2009 12:00:10 -0600, Jeffrey wrote:
> Getting the following segfault with 306635c2 on Fedora 12. Seems to
> be happening with any 'tag:' search that returns results. For
> example, 'notmuch search tag:inbox' and 'notmuch search tag:unread'
> segfault but 'notmuch search tag:nosuchtag', 'notmuch search
> subject:logwatch' and 'notmuch search video' seem to work fine.
>
> Core was generated by `/usr/bin/notmuch search --sort=oldest-first tag:inbox'.
> Program terminated with signal 11, Segmentation fault.
> \#0 Xapian::TermIterator::operator* (this=)
> at api/omtermlistiterator.cc:78
> 78RETURN(internal->get_termname());
> Current language: auto
> The current source language is "auto; currently c++".
I have hit what I believe is exactly the same problem. In my case, some
results are printed when I execute "notmuch search tag:inbox", and then
the program crashes in the same exact place.
The thing is that in notmuch_message_get_in_reply_to(), line 288, a NULL
instance of Xapian::TermIterator is dereferenced. In my particular case,
the culpript is a cache file of Claws-Mail, as seen in the following GDB
session:
Program received signal SIGSEGV, Segmentation fault.
Xapian::TermIterator::operator* (this=) at
api/omtermlistiterator.cc:78
78 RETURN(internal->get_termname()); Current language: auto
The current source language is "auto; currently c++".
(gdb) bt
#0 Xapian::TermIterator::operator* (this=) at
api/omtermlistiterator.cc:78
#1 0x0040f611 in _notmuch_message_get_in_reply_to(message=0x76dcd0) at
lib/message.cc:288
#2 0x00412030 in _resolve_thread_relationships (thread=0x6a8b80) at
lib/thread.cc:157
#3 0x00412454 in _notmuch_thread_create (ctx=0x65f1b0,
notmuch=0x62d320, thread_id= 0x765530 "01b17ddb4479a0dc0b416bb63b92c43d",
query_string=0x65f220 "tag:inbox") at lib/thread.cc:285
#4 0x00411982 in notmuch_query_search_threads (query=0x65f1b0,
first=100, max_threads=-1) at lib/query.cc:218
#5 0x0040924d in do_search_threads (ctx=0x61f140, query=0x65f1b0,
sort=NOTMUCH_SORT_NEWEST_FIRST, first=100, max_threads=-1) at
notmuch-search.c:40
#6 0x004097ef in notmuch_search_command (ctx=0x61f140, argc=1,
argv=0x7fffe188) at notmuch-search.c:164
#7 0x004066f1 in main (argc=3, argv=0x7fffe178) at notmuch.c:400
(gdb) frame 1
#1 0x0040f611 in _notmuch_message_get_in_reply_to (message=0x76dcd0)
at lib/message.cc:288
288 in_reply_to = *i;
(gdb) p *message
$1 = {notmuch = 0x62d320, doc_id = 1, frozen = 0, message_id = 0x76db60 "",
thread_id = 0x0,
in_reply_to = 0x0, filename = 0x76dc50
"/home/aperez/.mail/inbox/.claws_cache", message_file = 0x0,
replies = 0x76d250, doc = {internal = {dest = 0x76d450}}}
As you can see, there "filename" points to a Claws-Mail cache file, which
is a binary file (I can provide a copy if needed). I suspect that this is
related to the fact that the iterator ends up being NULL somehow.
I will experiment a bit more with this issue -- maybe just avoiding adding
files whose name starts with a dot will suffice as temporary fix.
Cheers,
--
Adrian Perez de Castro
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091119/5a6cbd02/attachment.pgp>
[notmuch] Fw: Introducing myself
On Thu, 19 Nov 2009 01:32:30 +0100, Adrian wrote: > (Re-injecting this one in the list... it was my fault in reality because I > sent two copies, one to the list and another to Carl, so he replied to me > directly. It would have been enough to send my mail to the list -- I am > sorry a lot for the noise) > > Begin forwarded message: > > Date: Thu, 19 Nov 2009 00:58:38 +0100 > From: Carl Worth > To: Adrian Perez de Castro > Subject: Re: [notmuch] Introducing myself > > > On Wed, 18 Nov 2009 16:47:06 +0100, Adrian Perez de Castro > wrote: > > On Wed, 18 Nov 2009 03:15:31 -0800, Carl wrote: > > > > I tried the "notmuch.el" Emacs mode, and have just installed Emacs in > > order to be able to try it out. As I have been using Vim for the last ~9 > > years, probably that was the reason why I found it not very comfortable. > > Wow, you're brave to give it a shot. And I'm glad that you were able to > work your way through it. After trying things a bit with some copied mailboxes, I am planning now on moving away from Claws-Mail... so Emacs will be sitting here for a while :D > > I also think it would be great to have a curses-based UI, so this may > > be a good opportunity to start doing some serious coding with it in my > > spare time. > > Sounds great. I would feel just fine seeing lots of interfaces built up > around the notmuch search and tagging. Me too, and all sharing the same index. > [...] I do hope people doing custom > interfaces will consider implementing some of the things that I happen > to consider part of the "notmuch experience", (viewing an entire, nested > thread at once with citations/signatures elided---this feature comes > exactly from sup; and my magic space-bar for reading lots of mail with > only one key---though the most important part here is to not archive a > message until it is paged *off* the screen---as opposed to many emailers > that mark a message as "read" as soon as any of the message appears on > the screen). > > Of course, if you're doing your own interface, then you get to do > whatever you want. But I hope you might at least consider those ideas. I am not totally sure about the elusion of citation and signatures, but that can be an user setting. My favourite feature is not marking messages as read until one decides to do so. For the rest of the lot, I agree that they should be there as well. Best regards, [1] http://fdm.sourceforge.net/ -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091119/4b5eaf49/attachment-0001.pgp>
[notmuch] Fw: Introducing myself
(Re-injecting this one in the list... it was my fault in reality because I sent two copies, one to the list and another to Carl, so he replied to me directly. It would have been enough to send my mail to the list -- I am sorry a lot for the noise) Begin forwarded message: Date: Thu, 19 Nov 2009 00:58:38 +0100 From: Carl Worth To: Adrian Perez de Castro Subject: Re: [notmuch] Introducing myself On Wed, 18 Nov 2009 16:47:06 +0100, Adrian Perez de Castro wrote: > On Wed, 18 Nov 2009 03:15:31 -0800, Carl wrote: > > I tried the "notmuch.el" Emacs mode, and have just installed Emacs in > order to be able to try it out. As I have been using Vim for the last ~9 > years, probably that was the reason why I found it not very comfortable. Wow, you're brave to give it a shot. And I'm glad that you were able to work your way through it. > I showed the thing to my work mates this morning and most of them said > that they would like to have Mutt-like keybindings *with* Not Much's > search and tagging running behind it. Any long-time mutt users want to suggest keybindings? I've mostly been making stuff up as I go (with some influence from sup), but I think it's early enough that I could still re-train my muscles. Get your votes in now for your favorite keybindings. > I also think it would be great to have a curses-based UI, so this may > be a good opportunity to start doing some serious coding with it in my > spare time. Sounds great. I would feel just fine seeing lots of interfaces built up around the notmuch search and tagging. I do hope people doing custom interfaces will consider implementing some of the things that I happen to consider part of the "notmuch experience", (viewing an entire, nested thread at once with citations/signatures elided---this feature comes exactly from sup; and my magic space-bar for reading lots of mail with only one key---though the most important part here is to not archive a message until it is paged *off* the screen---as opposed to many emailers that mark a message as "read" as soon as any of the message appears on the screen). Of course, if you're doing your own interface, then you get to do whatever you want. But I hope you might at least consider those ideas. Happy hacking! -Carl -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091119/c9d3ac28/attachment.pgp>
[notmuch] Introducing myself
On Wed, 18 Nov 2009 03:15:31 -0800, Carl wrote: > So I'd written a bunch of functional code, only to find myself stuck at > the very last step, (hooking it up to the existing sup interface). Then > Keith suggested emacs and it all seemed pretty easy since I'd already > done all the Xapian work. So it's funny, I was only willing to commit to > this project because I wasn't consciously aware I was working on it. > Otherwise it would have seemed to overwhelming to start. :-) I tried the "notmuch.el" Emacs mode, and have just installed Emacs in order to be able to try it out. As I have been using Vim for the last ~9 years, probably that was the reason why I found it not very comfortable. Even so, I am able of searching, sending and tagging mail quite happily. Apart from it being a bit Spartan, the only issue I have found so far is that I keep pushing the Escape key a lot -- which is my fault as that is a compulsive behaviour derived of using a Vi-like editor :D (Side note: I would not like to start an editor-religion debate, I just want you to know that most probably it is my fault when I say that I am not very comfortable with the Emacs mode) I showed the thing to my work mates this morning and most of them said that they would like to have Mutt-like keybindings *with* Not Much's search and tagging running behind it. I also think it would be great to have a curses-based UI, so this may be a good opportunity to start doing some serious coding with it in my spare time. > > Also, I would like to share one idea [...] adding a "X-Tags" header > > field or by reusing the "Keywords" one. This way, the index could > > be totally recreated by re-reading the mail directories, and this > > would also allow to a tools like OfflineIMAP [1] to get the mails into a > > local maildir, tagging and indexing the mails with the e-mail reader and > > then syncing back the messages with the "X-Tags" header to the IMAP server. > > This would allow to use the mail reader from a different computer and still > > have everything tagged finely. > > It is an interesting idea. But there's also something really comforting > about the email indexed never modifying the mail files. If you're > reading the notmuch commit logs closely you'll see that I'm not actually > careful enough to be trusted with your mail (but I try). So I like that > I don't even have to trust myself---the worst that happens is that I > have to recreate my index. I already made a comment about this in another reply, I could make the modifications e.g. from a script, so no need to add this in Not Much. Moreover, I agree that if one of the goals is to never modify mailboxes, then the current behaviour is just perfect. > And as Keith mentioned, we've got the "notmuch dump; notmuch restore" > idea working exactly as it did in sup. (Though I am thinking of also > adding thread IDs to that now---more on that later.) > > The big annoyance I had with sup index creation, (I ended up having to > do it more than once too), was that it takes *forever*. Right now, > notmuch is a little bit faster, but not a lot faster. And I've got some > ideas to fix that. It would be really nice if index creation were pain > free. (And maybe it is for some user with small amounts of mail---oh, to > have only 4 messages to have to index!). Wow, that is a lot of mail. Definitely people having as much mail as you (er... I mean "_not much_ mail as you") would benefit from faster indexing. > [*] The problem here is that sup puts serialized ruby data structures > into the data field of its Xapian documents. So being compatible with > sup means being able to recreate serialized data structures for a > particular version of ruby. Scary... -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/db88b07f/attachment.pgp>
[notmuch] Introducing myself
On Tue, 17 Nov 2009 18:03:17 -0800, Keith wrote: > On Wed, 18 Nov 2009 00:20:59 +0100, Adrian Perez de Castro igalia.com> wrote: > > > Also, I would like to share one idea I had in mind, that you might find > > interesting: One thing I have found very annoying is having to re-tag my > > mail when the indexes get b0rked (it happened a couple of times to me while > > using Sup), so I was planning to mails as read/unread and adding the tags > > not just to the index, but to the mail text itself, e.g. by adding a > > "X-Tags" header field or by reusing the "Keywords" one. > > Easier than that, notmuch (and sup too), provide a 'dump' command which > just lists all of the message IDs and their associated tags. Makes > saving tags easy and doesn't involve rewriting messages. I do this once > a day just before my computer is backed up to an external drive. > > If the index is destroyed, you can reindex the messages and then reapply > all of the tags with 'notmuch restore'. I already knew about "dump" and "restore", just wanted to share my (wild) thought. I have been thinking a bit more, and if I understand correctly the philosophy of Not Much is that it will only read my mail and that it will never write to my mailboxes. So my idea makes no sense. The nice thing is that I could make a script to read the index (or the output of "notmuch dump") to add the "X-Tags" headers and mark mail :P Taking into account this and the "do one thing well" motto: there is no point in adding that to Not Much :) Regards, -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/e0ada2f2/attachment.pgp>
[notmuch] Introducing myself
Hello to all, I have just heard about Not Much today in some random Linux-related news site (LWN?), my name is Adrian Perez and I work as systems administrator (although I can do some code as well :P). I have always thought that the ideas behind Sup were great, but after some time using it, I got tired of the oddities that it has. I also do not like doing things like having to install Ruby just for reading and sorting mails. Some time ago I thought about doing something like Not Much and in fact I played a bit with the Python+Xapian and the Python+Whoosh combinations, because I find relaxing to code things in Python when I am not working and also it is installed by default on most distribution. I got to have some mailboxes indexed and basic searching working a couple of months ago. Lately I have been very busy and had no time for coding, and them... boom! Not Much appears -- and it is almost exactly what I was trying to do, but faster. I have been playing a bit with Not Much today, and I think it has potential. Also, I would like to share one idea I had in mind, that you might find interesting: One thing I have found very annoying is having to re-tag my mail when the indexes get b0rked (it happened a couple of times to me while using Sup), so I was planning to mails as read/unread and adding the tags not just to the index, but to the mail text itself, e.g. by adding a "X-Tags" header field or by reusing the "Keywords" one. This way, the index could be totally recreated by re-reading the mail directories, and this would also allow to a tools like OfflineIMAP [1] to get the mails into a local maildir, tagging and indexing the mails with the e-mail reader and then syncing back the messages with the "X-Tags" header to the IMAP server. This would allow to use the mail reader from a different computer and still have everything tagged finely. Best regards, --- [1] http://software.complete.org/software/projects/show/offlineimap -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/88190837/attachment-0001.pgp>
