notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 16:59:17 -0400, Jameson Rollins  wrote:
> Hey, Darren.  Total side note, but you might be interested in the recent
> message from Kristoffer about his nice rss2message utility, "sluk", that
> works great for translating rss feeds into notmuch-indexable messages:

Thanks for the heads up Jamie - I saw this come through but at the time
it didn't seem to support most of the feeds I was reading.  I didn't
look too closely since feed2imap worked for me.  I'll check out the
latest version and see if that has changed.  I do like the idea of
notmuch-to-feed as a companion tool.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101106/9dc95f08/attachment-0001.pgp>


notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 16:12:17 -0400, Jameson Rollins  wrote:
> Notmuch is the best damn mail system there ever was and we wouldn't
> want to mess with that.  Does abstracting everything in notmuch from
> "messages" -> "documents" hurt it as a mail system?  What if just the
> back-end were abstracted, to allow for different front-ends for
> different classes of documents, i.e. "messages", "articles", "books",
> "rss feeds", etc.?  Are there any big problems with this proposal that
> I'm overlooking?
> 
> I'm very interested to hear what others think about this idea.

Absolutely 100% in agreement - the reason I use emacs for everything I
possibly can from web browsing to writing to coding to mailing is
because it's all just (occasionally arbitrarily formatted) text and all
text can be dealt with across buffers in exactly the same manner.  The
ability to use a single indexer and search interface for any of that
same text gets a big +1 from me.

I recently started using feed2imap in order to get notmuch tagging and
searching for rss, I'm sure I'm not alone.  I was just wondering how on
earth to go about adding headers to my sets of org-mode formatted notes,
for instance, so that notmuch could pick them up and index them for me.

In fact, the less of a distinction between the types of 'document' I'm
dealing with the better.  Maybe different document types get different
default keybindings - I may not want to 'reply' to an ebook but I
absolutely may want to forward it to someone?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101106/3045240e/attachment.pgp>


notmuch for documents

2010-11-06 Thread Nicolás Reynolds
El 06/11/10 04:59, Jameson Rollins dijo:
> On Sat, 06 Nov 2010 20:40:10 +, Darren McGuicken  fernseed.info> wrote:
> > I recently started using feed2imap in order to get notmuch tagging and
> > searching for rss, I'm sure I'm not alone.
> 
> Hey, Darren.  Total side note, but you might be interested in the recent
> message from Kristoffer about his nice rss2message utility, "sluk", that
> works great for translating rss feeds into notmuch-indexable messages:
> 
> http://github.com/krl/sluk/
> id:"87d3rgzdyj.fsf at rymdkoloni.se"

thanks to both of you, i was just looking for this a few weeks ago! :)


-- 
Salud!
Nicol?s Reynolds,
xmpp:fauno at kiwwwi.com.ar
omb:http://identi.ca/fauno
blog:http://selfdandi.com.ar/
gnu/linux user #455044

http://librecultivo.org.ar
http://parabolagnulinux.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101106/30fda53e/attachment.pgp>


[PATCH] emacs: Fix notmuch-show-pipe-message to use notmuch-command variable

2010-11-06 Thread Carl Worth
On Sun,  7 Nov 2010 00:09:18 +0100, Michal Sojka  wrote:
> Previously notmuch command name was hardcoded into this function,
> which made remote use of pipe command impossible.

Thanks, Michal.

As you must have noticed, I've also merged your "notmuch cat" patches,
(and subsequently renamed it to "notmuch show --format=raw").

I'm really excited about being able to run "emacs -f notmuch" with a
remote notmuch over ssh now. Thanks for that! (I also just mentioned
this feature in the NEWS file for our upcoming 0.5 release.)

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101106/1015ecd1/attachment.pgp>


notmuch for documents

2010-11-06 Thread Jameson Rollins
On Sat, 06 Nov 2010 20:40:10 +, Darren McGuicken  wrote:
> I recently started using feed2imap in order to get notmuch tagging and
> searching for rss, I'm sure I'm not alone.

Hey, Darren.  Total side note, but you might be interested in the recent
message from Kristoffer about his nice rss2message utility, "sluk", that
works great for translating rss feeds into notmuch-indexable messages:

http://github.com/krl/sluk/
id:"87d3rgzdyj.fsf at rymdkoloni.se"

jamie.
-- 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/20101106/87a4268e/attachment.pgp>


[PATCH 1/2] Don't use kill-this-buffer to kill notmuch emacs buffers

2010-11-06 Thread Jameson Rollins
kill-this-buffer appears to be a function intended specifically for
use in the menu bar, and causes problem killing notmuch buffers when
multiple frames have been used.  This patch replaces kill-this-buffer
with notmuch-kill-this-buffer, which in turn just simply calls
(kill-buffer (current-buffer)).
---
 emacs/notmuch-hello.el |2 +-
 emacs/notmuch-lib.el   |5 +
 emacs/notmuch-show.el  |4 ++--
 emacs/notmuch.el   |4 ++--
 4 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 4b6a90d..e58dd24 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -294,7 +294,7 @@ should be. Returns a cons cell `(tags-per-line width)'."
 (define-key map "v" '(lambda () "Display the notmuch version" (interactive)
(message "notmuch version %s" (notmuch-version
 (define-key map "?" 'notmuch-help)
-(define-key map "q" 'kill-this-buffer)
+(define-key map "q" 'notmuch-kill-this-buffer)
 (define-key map "=" 'notmuch-hello-update)
 (define-key map "G" 'notmuch-hello-poll-and-update)
 (define-key map (kbd "") 'widget-backward)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index abcbfa1..dfdcd05 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -87,6 +87,11 @@ the user hasn't set this variable with the old or new value."
   "Return the user.primary_email value from the notmuch configuration."
   (notmuch-config-get "user.primary_email"))

+(defun notmuch-kill-this-buffer ()
+  "Kill the current buffer."
+  (interactive)
+  (kill-buffer (current-buffer)))
+
 ;;

 ;; XXX: This should be a generic function in emacs somewhere, not
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7ec6aa5..6b2268f 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -555,7 +555,7 @@ function is used. "
 (defvar notmuch-show-mode-map
   (let ((map (make-sparse-keymap)))
(define-key map "?" 'notmuch-help)
-   (define-key map "q" 'kill-this-buffer)
+   (define-key map "q" 'notmuch-kill-this-buffer)
(define-key map (kbd "") 'widget-backward)
(define-key map (kbd "M-TAB") 'notmuch-show-previous-button)
(define-key map (kbd "") 'notmuch-show-previous-button)
@@ -1038,7 +1038,7 @@ argument, hide all of the messages."
until (not (notmuch-show-goto-message-next)))
   ;; Move to the next item in the search results, if any.
   (let ((parent-buffer notmuch-show-parent-buffer))
-(kill-this-buffer)
+(notmuch-kill-this-buffer)
 (if parent-buffer
(progn
  (switch-to-buffer parent-buffer)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 2a87ab9..4a9223e 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -232,7 +232,7 @@ For a mouse binding, return nil."
   "Exit the search buffer, calling any defined continuation function."
   (interactive)
   (let ((continuation notmuch-search-continuation))
-(kill-this-buffer)
+(notmuch-kill-this-buffer)
 (when continuation
   (funcall continuation

@@ -824,7 +824,7 @@ same relative position within the new buffer."
(target-thread (notmuch-search-find-thread-id))
(query notmuch-search-query-string)
(continuation notmuch-search-continuation))
-(kill-this-buffer)
+(notmuch-kill-this-buffer)
 (notmuch-search query oldest-first target-thread target-line continuation)
 (goto-char (point-min

-- 
1.7.2.3



notmuch for documents

2010-11-06 Thread Jameson Rollins
A little while ago on #notmuch, madduck and ojwb mentioned that they
thought notmuch was overly focused on mail.  At the time I thought this
was a silly criticism and defended notmuch as doing what it does
*really* well and that we shouldn't expect notmuch to be all things to
all people.

Yesterday, however, I had the profound realization that madduck and ojwb
are right.

Notmuch stores database entries for email messages.  However, these
messages are nothing more than simple rfc5322 [0] structured documents.
They include nothing more than headers and a text body.

Imagine now that I have a collection of ebooks, each stored in a single
rfc5322-formatted text file:


From: Italo Calvino <it...@calvino.com>
Subject: If on a winter's night a traveler
Date: 1979

You are about to begin reading Italo Calvino's new novel,
...


I store them all in a directory.  I now create a NOTMUCH_CONFIG with a
database.path that points to that directory, and run notmuch.  Notmuch
works *out of the box* (almost) perfectly to index my collection of
ebooks.  All the notmuch commands work exactly as expected.  I can
search through the bodies, search the titles, search for an author,
search for a publication date, etc.  The emacs interface even works as
expected.  Try it: it really works!  There are only a couple of very
little things that are a little funky:

  * the "headers" in my ebooks aren't exactly intuitive ("From" instead
of "Author", "Subject" instead of "Title", etc.) and there are some
missing headers ("Publisher").  I also had to format some of them in
a strange way (I had to add "" in the "From"
field in order to get it to index properly for some reason).

  * The documentation keeps referring to "messages", even though my
documents are books.  And there are some subcommands that don't seem
to make sense ("reply" to a book?).

But that's it!  Everything else works as a perfect ebook indexer.  I can
of course even add tags to my books.  Beautiful.  It's really quite
incredible how well it works for this out of the box.  The only other
issue is that my ebooks don't come in rfc5322-formatted files.  I have
to translate them for notmuch to work.

So what would have to be tweaked in notmuch to make it work even better
as an ebook indexer?

  * add some sort of translator to extract the "headers" and "body" from
my non-rfc5322-formatted ebook files

  * allow me to specify which "headers" from my ebooks I want indexed
("Author", "Publisher", etc.)

  * tweak notmuch show to just open the ebook itself in an ebook reader
instead of outputting it to stdout

  * tweak the documentation

Those are not very big changes.  And yet, with these changes notmuch can
now work for *many* other large classes of structured documents.

Another real world example:

I have hundreds of scientific journal articles on my computer.  They are
all pdf files and each has a corresponding bibtex entry in a flat text
file.  If notmuch could read the headers from the bibtex file and the
body from the text in the pdf (ps2ascii), notmuch would work *perfectly*
as an indexer for my scientific journal articles.

So what do people think about this idea?  Does it make sense to look
into extending notmuch to handle non-mail documents?  We definitely
would *not* want to compromise notmuch as a mail indexer/reader.
Notmuch is the best damn mail system there ever was and we wouldn't want
to mess with that.  Does abstracting everything in notmuch from
"messages" -> "documents" hurt it as a mail system?  What if just the
back-end were abstracted, to allow for different front-ends for
different classes of documents, i.e. "messages", "articles", "books",
"rss feeds", etc.?  Are there any big problems with this proposal that
I'm overlooking?

I'm very interested to hear what others think about this idea.

jamie.

[0] http://tools.ietf.org/html/rfc5322
------ 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/20101106/e4a0b25d/attachment.pgp>


Re: notmuch for documents

2010-11-06 Thread Jameson Rollins
On Sat, 06 Nov 2010 20:40:10 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 I recently started using feed2imap in order to get notmuch tagging and
 searching for rss, I'm sure I'm not alone.

Hey, Darren.  Total side note, but you might be interested in the recent
message from Kristoffer about his nice rss2message utility, sluk, that
works great for translating rss feeds into notmuch-indexable messages:

http://github.com/krl/sluk/
id:87d3rgzdyj@rymdkoloni.se

jamie.


pgpK9pxhFu9mJ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 1/2] Don't use kill-this-buffer to kill notmuch emacs buffers

2010-11-06 Thread Jameson Rollins
kill-this-buffer appears to be a function intended specifically for
use in the menu bar, and causes problem killing notmuch buffers when
multiple frames have been used.  This patch replaces kill-this-buffer
with notmuch-kill-this-buffer, which in turn just simply calls
(kill-buffer (current-buffer)).
---
 emacs/notmuch-hello.el |2 +-
 emacs/notmuch-lib.el   |5 +
 emacs/notmuch-show.el  |4 ++--
 emacs/notmuch.el   |4 ++--
 4 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 4b6a90d..e58dd24 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -294,7 +294,7 @@ should be. Returns a cons cell `(tags-per-line width)'.
 (define-key map v '(lambda () Display the notmuch version (interactive)
(message notmuch version %s (notmuch-version
 (define-key map ? 'notmuch-help)
-(define-key map q 'kill-this-buffer)
+(define-key map q 'notmuch-kill-this-buffer)
 (define-key map = 'notmuch-hello-update)
 (define-key map G 'notmuch-hello-poll-and-update)
 (define-key map (kbd C-tab) 'widget-backward)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index abcbfa1..dfdcd05 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -87,6 +87,11 @@ the user hasn't set this variable with the old or new value.
   Return the user.primary_email value from the notmuch configuration.
   (notmuch-config-get user.primary_email))
 
+(defun notmuch-kill-this-buffer ()
+  Kill the current buffer.
+  (interactive)
+  (kill-buffer (current-buffer)))
+
 ;;
 
 ;; XXX: This should be a generic function in emacs somewhere, not
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7ec6aa5..6b2268f 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -555,7 +555,7 @@ function is used. 
 (defvar notmuch-show-mode-map
   (let ((map (make-sparse-keymap)))
(define-key map ? 'notmuch-help)
-   (define-key map q 'kill-this-buffer)
+   (define-key map q 'notmuch-kill-this-buffer)
(define-key map (kbd C-tab) 'widget-backward)
(define-key map (kbd M-TAB) 'notmuch-show-previous-button)
(define-key map (kbd backtab) 'notmuch-show-previous-button)
@@ -1038,7 +1038,7 @@ argument, hide all of the messages.
until (not (notmuch-show-goto-message-next)))
   ;; Move to the next item in the search results, if any.
   (let ((parent-buffer notmuch-show-parent-buffer))
-(kill-this-buffer)
+(notmuch-kill-this-buffer)
 (if parent-buffer
(progn
  (switch-to-buffer parent-buffer)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 2a87ab9..4a9223e 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -232,7 +232,7 @@ For a mouse binding, return nil.
   Exit the search buffer, calling any defined continuation function.
   (interactive)
   (let ((continuation notmuch-search-continuation))
-(kill-this-buffer)
+(notmuch-kill-this-buffer)
 (when continuation
   (funcall continuation
 
@@ -824,7 +824,7 @@ same relative position within the new buffer.
(target-thread (notmuch-search-find-thread-id))
(query notmuch-search-query-string)
(continuation notmuch-search-continuation))
-(kill-this-buffer)
+(notmuch-kill-this-buffer)
 (notmuch-search query oldest-first target-thread target-line continuation)
 (goto-char (point-min
 
-- 
1.7.2.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: Fix notmuch-show-pipe-message to use notmuch-command variable

2010-11-06 Thread Michal Sojka
Previously notmuch command name was hardcoded into this function,
which made remote use of pipe command impossible.
---
 emacs/notmuch-show.el |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 3daa868..ae483dd 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -937,12 +937,13 @@ than only the current message.
   (let (shell-command)
 (if entire-thread
(setq shell-command 
- (concat notmuch show --format=mbox 
+ (concat notmuch-command  show --format=mbox 
  (shell-quote-argument
   (mapconcat 'identity 
(notmuch-show-get-message-ids-for-open-messages)  OR ))
   |  command))
   (setq shell-command
-   (concat notmuch show --format=raw  (shell-quote-argument 
(notmuch-show-get-message-id))  |  command)))
+   (concat notmuch-command  show --format=raw 
+   (shell-quote-argument (notmuch-show-get-message-id))  |  
command)))
 (start-process-shell-command notmuch-pipe-command *notmuch-pipe* 
shell-command)))
 
 (defun notmuch-show-add-tags-worker (current-tags add-tags)
-- 
1.7.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 16:12:17 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
 But that's it!  Everything else works as a perfect ebook indexer.  I
 can of course even add tags to my books.  Beautiful.  It's really
 quite incredible how well it works for this out of the box.  The only
 other issue is that my ebooks don't come in rfc5322-formatted files.
 I have to translate them for notmuch to work.

I've now had a chance to play with this a little and while indexing,
tagging and searching all seem to work as expected, I am getting the
error 'Stack overflow in regexp matcher' when I try to view any of the
ebooks which either leaves the buffer basically useless (no notmuch key
shortcuts will work) or leads to a full segfault in emacs (23.1.1).

The trace begins:

Debugger entered--Lisp error: (error Stack overflow in regexp matcher)
  re-search-forward(\\(^[^]+\\)\n nil t)
  notmuch-wash-tidy-citations(0)
  run-hook-with-args(notmuch-wash-tidy-citations 0)
  notmuch-show-insert-part-text/plain((:body ((:content The Project
  Gutenberg EBook of The Adventures of Sherlock Holmes\nby Sir Art...

The contents of the ':content' part appears to be the complete text of
the novel.


pgp5Ghu2R6pb8.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 23:28:21 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 I've now had a chance to play with this a little and while indexing,
 tagging and searching all seem to work as expected, I am getting the
 error 'Stack overflow in regexp matcher' when I try to view any of the
 ebooks which either leaves the buffer basically useless (no notmuch key
 shortcuts will work) or leads to a full segfault in emacs (23.1.1).

Hmm, looks like Michal's patch back in July fixes this behaviour:

 id:1279279955-3110-1-git-send-email-sojk...@fel.cvut.cz


pgpYjG6qnygv5.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v4 0/4] Maildir synchronization

2010-11-06 Thread Michal Sojka
On Thu, 04 Nov 2010, Carl Worth wrote:
 Meanwhile, here are some of the things I'm still thinking about in
 regards to this patch. First, the commit message describes the
 synchronization happening at notmuch new and notmuch tag/notmuch
 restore. But the implementation shows that the functionality is within
 the library, not the command-line tool above it.
 
 I think having this at the library makes sense, but as you certainly
 noticed, the library has historically been entirely unaware of any
 configuration, (which I'd like to keep). Obviously, you maintained that
 separation in your patch series, but you added a new
 notmuch_database_set_maildir_sync function so that the library can be
 informed of the desired behavior.
 
 I'm not entirely sure I like a big, global state-changing function like
 that in the library. But if we do want to have that, we need to fix the
 documentation of all functions that are affected by it to correctly
 document their current behavior.

I can imagine two other solutions. One would be to add a parameter
(probably called flags) to the following functions:

notmuch_message_add_tag()
notmuch_message_remove_tag()
notmuch_message_thaw()

Since you want to keep ABI this would require to implement second
versions of these functions to keep backward compatibility.

The other option would be to put a flag into notmuch_message_t but this
is probably not very different from having it in notmuch_database_t.

 Also, the synchronization is inherently 2-way, but the two directions
 are implemented differently in the library. One direction, (from tags to
 maildir flags), is implemented implicitly in the library (existing
 functions do the new synchronization under the influence of
 database_set_maildir_sync). But the other direction, (from maildir flags
 to tags), requires an explicit call to a new function
 (notmuch_message_maildir_to_flags). I definitely don't like this.

I think I could make notmuch_message_maildir_to_flags() private and call
it from notmuch_database_add_message() so that both directions will be
implemented in the library.
 
 Finally, the documentation for notmuch_message_maildir_to_tags (Add or
 remove tags based on the maildir flags in the file name)
 inadequate. This documentation needs to say which tags are added/removed
 in what conditions. It should also give guidance on when this function
 should be called in order to achieve some particular behavior.
 
 I recognize that in the above I don't give specific guidance on whether
 the new functionality should be implicit or explicit in the
 library. I'm not certain which is better, and I'm willing to listen to
 justification from someone who has spent some time implementing and
 testing this stuff. But I don't like the current mixed state.

I found the following what I'd like the most: Do not export
notmuch_message_maildir_to_tags() from the library and call it
implicitly from notmuch_database_add_message(). Keep
notmuch_database_set_maildir_sync() and update the documentation of the
affected functions. This sounds to me better than adding explicit flags
parameters to enable/disable synchronization to all of the affected
functions. The additional parameters would make the API harder to use.

 One other issue, how does this support deal with multiple files that
 have the same message ID (and hence a single record in the database)?
 Some bad failure modes I can imagine are cycling of tags/filenames with
 successive runs of notmuch new, or leaking[*] of tags from one filename
 to another through the database.
 
 [*] Imagine, for example, someone using an external client that
 identifies duplicate messages in the mailstore and adds the maildir flag
 corresponding to deleted to all but one of each of the
 duplicates. There's then the possibility that notmuch could propagate
 this deleted flag through the deleted tag in the database, (perhaps
 after a notmuch dump/restore cycle). And that could be a catastrophic
 result if all messages that have duplicates get flagged for deletion!
 
 What thoughts do you have on this multiple-file issue?

The current implementation renames only the file whose name is stored
first in the database. I have a TODO comment there to add a loop through
all file names, but I have never realized that deleted flag could be so
dangerous.

I will need to extend the test suite for tests with multiple messages
having the same id and during that work I'll hopefully find some sane
solution.

It will take me probably a few days until I find time to work on this.
So let me now in that time whether you have some preferences in the
above.

-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch