hello, 'automated' tagging, synchronisation

hello, 'automated' tagging, synchronisation

[David Edmondson]

Hello. I've been trying out notmuch for a few days, so far it looks very
useful. Thank you to all those who have participated in implementing
it. I have a couple of questions:

1. How do others add some 'automatic' tagging of new messages? At the
   moment I'm using a script[1] which tags messages after running
   `notmuch new`. This passes over the same data multiple times, which
   seems wasteful but may be inevitable. Combined with a small amount of
   lisp...

   (setq notmuch-folder-list '("mine" "inbox" "rss" "unread"
		     "os-xen" "os-discuss" "os-laptop" "os-network"
		     "xen-changelog" "xen-devel" "xen-users"
		     "list/fork" "list/interesting-people" "list/sun-alumni" "list/notmuch"))
   (setq notmuch-folders (mapcar
         '(lambda (f) (cons f (concat "tag:" f " AND tag:unread")))
         notmuch-folder-list))

   ...things mostly work out.

2. Sometimes it's useful to use another computer. Having the Maildir
   folders duplicated there is simple (already using offlineimap), as is
   building the search database. Missing are the tags, particularly if
   they were hand applied. So far my (unimplemented) solution for this
   is to dump/restore the tags and store the dump under version
   control. Moving from one computer to another (which I don't do very
   often) would involve:
         a$ notmuch dump >tags
         a$ git commit tags
         a$ git push
         b$ git pull
         b$ notmuch restore tags
   With appropriate amounts of conflict resolution should I update the
   tags on both a and b.

   What does everyone else do about this?

Footnotes: 
[1]  http://dme.org/tmp/run-notmuch

dme.
-- 
David Edmondson, http://dme.org

Re: hello, 'automated' tagging, synchronisation

[Jesse Rosenthal]

Hi David,

On Wed, 10 Feb 2010 11:06:13 +0000, David Edmondson <dme@dme.org> wrote:
> 2. ... So far my (unimplemented) solution for this
>    is to dump/restore the tags and store the dump under version
>    control. Moving from one computer to another (which I don't do very
>    often) would involve:
>          a$ notmuch dump >tags
>          a$ git commit tags
>          a$ git push
>          b$ git pull
>          b$ notmuch restore tags
>    With appropriate amounts of conflict resolution should I update the
>    tags on both a and b.

This seems to be the going solution. However, if you have a stable
connection and password-free ssh access to your home computer (as I do,
from my work computer) I've had good luck just using the emacs client
remotely, without even having notmuch installed on the second machine,
by pointing the emacs variable `notmuch-command' to a shell script
which, essentially, runs the following:

        ssh user@host /usr/local/bin/notmuch $@

The script is a bit more complicated, and it requires a very tiny patch
to notmuch.el (no effect on local usage, I posted it on the list
somewhere). But if you have a fast, stable connection, and you make use
of an open ssh connection, it's almost as fast as local use, and doesn't
require dumping back and forth.

Problem: It can't at the moment handle attachments and, I imagine, the
new html-inlining, which both use emacs code that refers to
(insert-file-contents). One alternative would
be to replace the (insert-file-contents) calls with TRAMP calls:

   (insert-file-contents (concat "/ssh:" host ":" file))

I'm also working on a trivial, but abstractable, solution that adds
something like "notmuch show --raw-file," which could replace all of
those emacs calls with notmuch calls, and which can therefore use the
hacked-up client-server model. In other words, the latter solution would
work in both the local and remote case, without having to alter the
emacs client.

This solution is not perfect, and it might not fit your needs, but I
wanted to mention it, in addition to the dumping-restoring, as something
that has been working well for me for a while now, when I have to use a
second computer.

Best,
Jesse