[notmuch] Introducing notmuchsync
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
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] modifying emacs keymap
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
Re: [notmuch] modifying emacs keymap
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 mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer
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
Re: [notmuch] Snippet to jump to message in Gnus from notmuch-show buffer
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 "xx...@gmx.de" :password ,th-gnus-gmx-password) (pop :server "pop3.freenet.de" :user "xx...@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 "xx...@gmx.de" "gmx") (any "xx...@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") (n
[notmuch] [PATCH] Return unpropertized strings for filename and message-id
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
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
Re: [notmuch] [PATCH] Return unpropertized strings for filename and message-id
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
To: Carl Worth
Cc: notmuch@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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer
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
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
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
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)
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
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
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
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
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
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
