[notmuch] Introducing notmuchsync

2010-01-20 Thread Tassilo Horn
Jameson Rollins  writes:

Hi Jameson,

> That said, I have vasilated just a bit on this, as to whether notmuch
> should touch the mail at all, or just process it.  But having thought
> about it a bit, I think that notmuch really *is* an MUA, or at least
> the mail processing part of a MUA (MUA minus message reader), and
> should therefore do the appropriate things with the maildir.

I don't care if notmuch would somehow manipulate mail, but at least,
there has to be an option to avoid that.  I use it only as indexer and
search utility, and wrote some custom code to jump from notmuch buffers
to the right message in Gnus.  Notmuch indexes the mails directly in the
mail storage of my local IMAP server, which is not maildir, and I'm
pretty sure, my IMAP server wouldn't like someone modifying files in its
guts.

Bye,
Tassilo


Re: [notmuch] Introducing notmuchsync

2010-01-20 Thread Tassilo Horn
Jameson Rollins jroll...@finestructure.net writes:

Hi Jameson,

 That said, I have vasilated just a bit on this, as to whether notmuch
 should touch the mail at all, or just process it.  But having thought
 about it a bit, I think that notmuch really *is* an MUA, or at least
 the mail processing part of a MUA (MUA minus message reader), and
 should therefore do the appropriate things with the maildir.

I don't care if notmuch would somehow manipulate mail, but at least,
there has to be an option to avoid that.  I use it only as indexer and
search utility, and wrote some custom code to jump from notmuch buffers
to the right message in Gnus.  Notmuch indexes the mails directly in the
mail storage of my local IMAP server, which is not maildir, and I'm
pretty sure, my IMAP server wouldn't like someone modifying files in its
guts.

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


[notmuch] modifying emacs keymap

2009-12-28 Thread Tassilo Horn
Jameson Graef Rollins  writes:

Hi Jameson,

> (add-hook 'notmuch-search-mode
>   (define-key notmuch-search-mode-map "A" 
> 'notmuch-show-mark-read-then-archive-thread)
> )

`notmuch-search-mode' is no hook, and even if it was, you couldn't add
what you like, because that's no function.  You would need to define a
function that doesn that or wrap it in a lambda function.

Anyway, this should do the trick:

(define-key notmuch-search-mode-map "A" 
'notmuch-show-mark-read-then-archive-thread)

Bye,
Tassilo


[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer

2009-11-27 Thread Tassilo Horn
Carl Worth  writes:

Hi Carl,

> On Tue, 24 Nov 2009 09:02:46 +0100, Tassilo Horn  
> wrote:
>> I'm a Gnus user and use notmuch mostly for searching.  When I want to
>> reply to a message, I need to get back to Gnus, so that my Gnus
>> posting styles (gcc into that group, right email address, correct
>> signature,...)  are applied.
>
> Oh, good. I've been hoping to be able to get some advice from gnus
> users. I want to figure out how to get gnus support for viewing
> encrypted messages, etc.

Oh, I don't have any clue about encryption.  EasyPG is a keyword, that I
can provide, though.

> Do you happen to know some good documentation for how to get started
> with gnus for reading mail? I'd be happy even with the bare minimum to
> just get gnus to view one single message from out of my mail
> store. (Which is something I tried to figure out from the gnus manual,
> but I never succeeded at.)

Well, if you only want to have a look at a maildir or mbox, and don't
want to make the group permanent and let gnus fetch mail, then this
should do the trick.

  M-x gnus RET ;; brings you into the *Group* buffer, and then

,[ (info "(gnus)Foreign Groups") ]
| `G m'
|  Make a new group (`gnus-group-make-group').  Gnus will prompt you
|  for a name, a method and possibly an "address".  For an easier way
|  to subscribe to NNTP groups (*note Browse Foreign Server::).
`

>> Therefore, I created this small snippet.  Now C-c C-c inside some
>> message in the *notmuch-show* buffer opens this article in a Gnus
>> *Summary* buffer, where I can reply to it, forward it, ...
>
> And this would be exactly the thing I would want for exploring gnus,
> if only I could get it working.

This does only work if the group already exists inside Gnus.  So you
might consider setting it up properly, although it's a bit first-time
effort.

> If I just try to run it, I get:
>
>   Symbol's function definition is void: org-gnus-follow-link

Do you use Emacs 23?  If yes, put a (require 'org-gnus) before the
call.  If not, you have to install org-mode manually.

> And I suppose that's expected since I don't have gnus "running". If I
> try to start gnus with "M-x gnus", I get:
>
>   Unable to open server nntp+news, go offline? (y or n) 

Hm, I can reproduce that with "emacs -Q".  Looks wrong to me, probably a
bug...  Normally, an unconfigured Gnus should start having one nndoc
server providing some groups with static Gnus infos (FAQ and stuff).

> What's the simplest way for me to tell gnus that I won't be using it
> in any other way than with the "nnimap+" folder I can tell you're
> using in your snippet?

Here's a quick walkthrough my .gnus.el with only the basics (getting
mail/news).

--8<---cut here---start->8---
;; Gnus has the concept of one select method, and a list of so-called
;; secondary select methods.  I set the former to a do-nothing backend
;; and only use the secondary ones, so that it's a bit more uniformly.

(setq gnus-select-method '(nnnil))

;; Fetch news from my university's nntp server
(add-to-list 'gnus-secondary-select-methods
 '(nntp "Uni"
(nntp-address "news.uni-koblenz.de")
(nntp-open-connection-function nntp-open-tls-stream)
(nntp-port-number 563)))

;; Fetch mail from some POP3 accounts and split them according to
;; address

;; The mails are stored in an nnml group at the given directory
(add-to-list 'gnus-secondary-select-methods
 '(nnml "Popmail"
(nnml-directory   "~/Mail/Popmail")
(nnml-active-file "~/Mail/Popmail/active")))

;; Here the mails are fetched
(setq mail-sources `((pop :server "pop.gmx.de"
  :user "x at gmx.de"
  :password ,th-gnus-gmx-password)
 (pop :server "pop3.freenet.de"
  :user "x at freenet.de"
  :password ,th-gnus-freenet-password)))

;; Split them into the groups nnml+Popmail:gmx, freenet, and misc
(setq nnmail-split-methods 'nnmail-split-fancy
  nnmail-split-fancy
  '(| (any "x at gmx.de" "gmx")
  (any "x at freenet.de" "freenet")
  "misc"))

;; Get mail from my local Dovecot IMAP server which I sync with my
;; different accounts using OfflineIMAP
(add-to-list 'gnus-secondary-select-methods
 '(nnimap "Fastmail"
  (nnimap-address "localhost")
  (nnimap-stream network)
  (nnimap-authenticator login)))

(add-to-list 'gnus-secondary-select-methods
 '(nnimap "Uni"
  (nnimap-address "localhost")
  (nnimap-stream network)
  (nnimap-authenticator login)))
--8<---cut here---end--->8---

HTH,
Tassilo


[notmuch] [PATCH] Return unpropertized strings for filename and message-id

2009-11-27 Thread Tassilo Horn
Carl Worth  writes:

Hi Carl,

>> Here's my first patch.  It changes that notmuch-show-get-filename and
>> notmuch-show-get-message-id return simple strings and not propertited
>> strings.
>
> Thanks, Tassilo!
>
> It's great to have a contribution from you in notmuch. I've pushed
> this out now.

I guess it won't be the last one.  There are some byte-compiler warnings
with notmuch.el, that I'd like to remove.

> Two things with regards to your patch:
>
>   1. It's most convenient (for me) to apply emailed patches by sending
>  directly to "git am". And "git am" just happens to want to see the
>  complete commit message as the first thing in the mail message,
>  (continuing the summary of the commit which comes from the
>  subject).
>
>  So to satisfy "git am", introductory and explanatory portions of
>  the email, ("Hi!" and "Here's my first patch"), have to be
>  relegated to past the "---" divider).

So an email looking like this would be correct?

--8<---cut here---start->8---
From: Tassilo Horn <tass...@member.fsf.org>
To: Carl Worth 
Cc: notmuch at notmuchmail.org
Date: Fri, 27 Nov 2009 08:54:41 +0100
Subject: [PATCH] Remove preprocessor code

Don't define RUNNING_ON_VALGRIND, so that notmuch is probably broken.
---
 debugger.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/debugger.c b/debugger.c
index e8b9378..f32cdc9 100644
--- a/debugger.c
+++ b/debugger.c
@@ -24,8 +24,6 @@

 #if HAVE_VALGRIND
 #include 
-#else
-#define RUNNING_ON_VALGRIND 0
 #endif

 notmuch_bool_t
-- 
1.6.5.3

Hi Carl,

this patch is completely wrong.  Please don't apply it. :-)

And thanks again for the great work.

Bye,
Tassilo
--8<---cut here---end--->8---

>   2. Maybe I'll undermine my point above, but the commit here really
>  *does* need a commit message beyond the first line.
>
>  I've described this before as the one-line summary giving the
>  "what" and the rest of the commit message giving the "why".

Makes sense.

>  And this is a perfect case of that. I can see exactly what the
>  patch does, and it makes sense. But I tried to write the rest of
>  the commit message and found I couldn't. In what cases did the
>  presence of text properties cause a problem? I don't know, and
>  that's what the commit message should have said.

Normally it causes almost never any problems, but IMO it's just bad
style.  When a user wants to get the Message-id, he most probably only
wants to do some calculations on that (e.g. jump to that message in Gnus
or rmail), or insert it somewhere else.  In the first case, text
properties aren't needed, and in the second case, it's most unlikely
that he wants to have exactly the same properties there, especially if
there are properties different from faces.

> I'd said before that I would bounce patches with only a one-line
> summary. I guess I'm still too soft, but do expect me to be more
> strict on this in the future. :-)

Yes, that all makes perfect sense, and because there are so many people
and patches for notmuch (which is great!), there have to be some strict
guidelines.

But instead of mailing each first-time committer a mail, you might
consider putting those guidelines on the notmuch homepage. :-)

Bye,
Tassilo


[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer

2009-11-24 Thread Tassilo Horn
Hi all,

I'm a Gnus user and use notmuch mostly for searching.  When I want to
reply to a message, I need to get back to Gnus, so that my Gnus posting
styles (gcc into that group, right email address, correct signature,...)
are applied.

Therefore, I created this small snippet.  Now C-c C-c inside some
message in the *notmuch-show* buffer opens this article in a Gnus
*Summary* buffer, where I can reply to it, forward it, ...

Of course, the translation from file name to Gnus group name is
something that is different for any user.  The essence of this code is
the call to the org-gnus.el function `org-gnus-follow-link', which takes
the group name and the message-id.  It's included in Emacsen >= 23.

--8<---cut here---start->8---
(require 'notmuch)

(defun th-notmuch-file-to-group (file)
  "Calculate the Gnus group name from the given file name.

Example:

  IN: /home/horn/Mail/Dovecot/uni/INBOX/dbox-Mails/u.4075
  OUT: nnimap+Uni:INBOX"
  (concat "nnimap+"
  (replace-regexp-in-string 
   "^\\([^/]+\\)/" "\\1:"
   (replace-regexp-in-string 
"/dbox-Mails/.*" ""
(replace-regexp-in-string
 "/home/horn/Mail/Dovecot/" "" file)

(defun th-notmuch-goto-message-in-gnus ()
  "Open a summary buffer containing the current notmuch
article."
  (interactive)
  (let ((group (th-notmuch-file-to-group (notmuch-show-get-filename)))
(message-id (replace-regexp-in-string
 "^id:" "" (notmuch-show-get-message-id
(message "G: %s, mid: %s" group message-id)
(if (and group message-id)
(org-gnus-follow-link group message-id)
  (message "Couldn't get relevant infos for switching to Gnus."

(define-key notmuch-show-mode-map (kbd "C-c C-c") 
'th-notmuch-goto-message-in-gnus)
--8<---cut here---end--->8---

BTW, why does `notmuch-show-get-message-id' prefix the message-id with
"id:"?

Bye,
Tassilo


[notmuch] [PATCH] Return unpropertized strings for filename and message-id

2009-11-23 Thread Tassilo Horn
Hi!

Here's my first patch.  It changes that notmuch-show-get-filename and
notmuch-show-get-message-id return simple strings and not propertited
strings.

Bye,
Tassilo

---
 notmuch.el |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 0cabbe2..c2839c0 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -169,7 +169,7 @@ Unlike builtin `next-line' this version accepts no 
arguments."
 (if (not (looking-at notmuch-show-message-begin-regexp))
(re-search-backward notmuch-show-message-begin-regexp))
 (re-search-forward notmuch-show-id-regexp)
-(buffer-substring (match-beginning 1) (match-end 1
+(buffer-substring-no-properties (match-beginning 1) (match-end 1

 (defun notmuch-show-get-filename ()
   (save-excursion
@@ -177,7 +177,7 @@ Unlike builtin `next-line' this version accepts no 
arguments."
 (if (not (looking-at notmuch-show-message-begin-regexp))
(re-search-backward notmuch-show-message-begin-regexp))
 (re-search-forward notmuch-show-filename-regexp)
-(buffer-substring (match-beginning 1) (match-end 1
+(buffer-substring-no-properties (match-beginning 1) (match-end 1

 (defun notmuch-show-set-tags (tags)
   (save-excursion
-- 
1.6.5.3


[notmuch] Notmuch doesn't index new mails when mail location contains symlinks

2009-11-23 Thread Tassilo Horn
Tassilo Horn  writes:

Hi Mikhail,

>>  TH> Whenever I delete those symlinks and created them anew, the new
>>  TH> mails get indexed with the next "notmuch new".  Of course, I could
>>  TH> create a script that does exactly that, but there should be a
>>  TH> better way, right?
>>
>> Probably mail does not get indexed due to mtime checks. Please try
>> whether touch'ing directory with mailboxes makes it work.
>
> No, it seems that doesn't help either.

Ah, I'm stupid!  I don't have to touch the symlinks or the directories
inside the locations the symlinks point to, but instead I have to touch
the top-level directory where the symlinks are contained in.  Then it
works as expected, AFAICT.

Thanks a lot,
Tassilo


[notmuch] Notmuch doesn't index new mails when mail location contains symlinks

2009-11-23 Thread Tassilo Horn
Mikhail Gusarov  writes:

Hi Mikhail,

>  TH> Whenever I delete those symlinks and created them anew, the new
>  TH> mails get indexed with the next "notmuch new".  Of course, I could
>  TH> create a script that does exactly that, but there should be a
>  TH> better way, right?
>
> Probably mail does not get indexed due to mtime checks. Please try
> whether touch'ing directory with mailboxes makes it work.

No, it seems that doesn't help either.

First, I only touched the two symlinks.  This didn't help.  Then I used
"find . -type d | xargs touch" to touch all directories inside the
directories the symlinks point to.  But still no luck.  Finally, I
deleted the symlinks and created them anew, and then it indexed the 12
new mails that arrived in the meantime.

Bye,
Tassilo


[notmuch] Notmuch doesn't index new mails when mail location contains symlinks (was: Notmuch doesn't index new mails)

2009-11-23 Thread Tassilo Horn
Tassilo Horn  writes:

Hi all,

I've investigated a bit further.

> [notmuch doesn't index new mails although all directories and files
> are readable and writable.]

In my config, I have:

--8<---cut here---start->8---
[database]
path=/home/horn/Mail/Dovecot
--8<---cut here---end--->8---

In that directory, there are two symlinks pointing to the real mail
location in /var/spool/mail:

--8<---cut here---start->8---
[horn at localhost][~/Mail/Dovecot][0][5213]
[:)] % ll
total 0
lrwxrwxrwx 1 horn horn 34 Nov 23 14:49 fastmail -> 
/var/spool/mail/fastmail/mailboxes
lrwxrwxrwx 1 horn horn 29 Nov 23 14:49 uni -> /var/spool/mail/uni/mailboxes
--8<---cut here---end--->8---

Whenever I delete those symlinks and created them anew, the new mails
get indexed with the next "notmuch new".  Of course, I could create a
script that does exactly that, but there should be a better way, right?

Bye,
Tassilo


[notmuch] Notmuch doesn't index new mails

2009-11-23 Thread Tassilo Horn
Hi all,

after setting up notmuch, initially indexing all my mail, and removing
the inbox and unread tags thereafter, now I recognize that notmuch
doesn't index new mail.

--8<---cut here---start->8---
% notmuch new --verbose
No new mail---and that's not much.
--8<---cut here---end--->8---

I did check that there's really new mail.

In the man page, it is mentioned, that notmuch skips directories that
are read-only.  So now all my folders are "drwxrwxr-x mail mail", and I
am in the mail group.

But still, notmuch doesn't index new mails.

I assumed that the mail files also have to be writable.  So I changed
them to "-rw-rw-r-- mail mail", but still no luck.

Any ideas what might be the problem?

Bye,
Tassilo


[notmuch] How to index /var/spool/mail with notmuch

2009-11-23 Thread Tassilo Horn
Carl Worth  writes:

Hi Carl,

>> Unfortunately, there are some dovecot internal files, which should
>> neither be indexed by notmuch, and which have 600 permissions for the
>> mail user.  And that's where notmuch errors and stops indexing. :-(
>
> Hi Tassilo, welcome to notmuch!
>
> I'm glad you found a workaround for this problem, (thanks Jed!).

Trying out notmuch already cashed out. ;-)

> But perhaps these errors should be made into warnings instead? Any
> thoughts on that anyone?

I think so.  For other dovecot internal index files it already says
something like "Ignoring non-mail file foobar.idx" and simply skips that
file.  I think that's the right thing to do for files where it has no
read permissions for, too.

>> All "real" mail files are named "u.", so it would be cool if
>> I could provide a pattern to notmuch matching all files I'd like to
>> index.  And maybe the other way round (a blacklist pattern) would be
>> useful, too.
>
> I've been planning on having a blacklist pattern for a while.
> Originally, the only difficulty in implementing it was that we had
> nowhere to store configuration information.  But we have a
> configuration file now, so this would be a pretty easy thing to
> implement.
>
> It's not as obvious that a whitelist pattern would be as widely
> useful, but it would be possible too.

Well, for dovecot users using the dbox format, a whitelist pattern would
be much simpler because of the coherent mail file naming.  But I could
live with a blacklist pattern, too.

Bye,
Tassilo


[notmuch] Catching up unread messages

2009-11-22 Thread Tassilo Horn
Hi!

I got notmuch running, and it's absolutely incredible.  It's so damn
fast and the results are very good.  So thanks a lot for creating this
nice piece of software. :-)

Ok, so new the question: I indexed all my 63.000 mails, and because it
was a first-time indexing, all my mail now has the tags inbox and
unread.  Of course, I don't want to SPC through all threads (using the
great emacs interface) to remove the unread status.  So is there some
catchup command, which marks all messages in the buffer as read?

BTW, what's the intention of the inbox tag?  When I've read a thread,
both inbox as well as unread disappear, so I don't get the difference
between them.

Bye,
Tassilo


[notmuch] How to index /var/spool/mail with notmuch

2009-11-22 Thread Tassilo Horn
Jed Brown  writes:

Hi Jed,

>>   - I run a local IMAP server (dovecot) and access it using Gnus
>>   - Dovecot stores its mails in /var/spool/mail/ in some one file per
>> message format
>
> How about
>
> $ mkdir -p ~/mail/spool
> $ ln -s /var/spool/mail/$USER/{cur,new,tmp} ~/mail/spool
>
> and point notmuch at ~/mail (or specifically ~/mail/spool).

Brilliant idea.  :-)

Ok, now it's indexing my 63000 mails.  10 minutes to go.

Bye,
Tassilo


[notmuch] How to index /var/spool/mail with notmuch

2009-11-22 Thread Tassilo Horn
Hi all,

I'd like to try out notmuch.  My mail setup is as follows:

  - I run a local IMAP server (dovecot) and access it using Gnus
  - Dovecot stores its mails in /var/spool/mail/ in some one file per
message format

But I get some permission problems when trying to index /var/spool/mail.
I was able to create a .notmuch/ directory in there with permissions set
to 700 for my user.  All mail files are readable for my user.

Unfortunately, there are some dovecot internal files, which should
neither be indexed by notmuch, and which have 600 permissions for the
mail user.  And that's where notmuch errors and stops indexing. :-(

All "real" mail files are named "u.", so it would be cool if I
could provide a pattern to notmuch matching all files I'd like to index.
And maybe the other way round (a blacklist pattern) would be useful,
too.

Any thoughts?  Maybe there's a better approach for what I'm trying to
do?

Bye,
Tassilo