Unison + notmuch?

[James Vasile]

I'm tempted to see if unison can keep two notmuch databases in sync.
Before I play with this concept, I was wondering if anybody with unison
experience had already tried this.  I didn't see anything in the list
archive/wiki/web.

So any advice before I accidentally destroy my database (aside from
"back it up", of course)?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Unison + notmuch?

[James Vasile]

I'm tempted to see if unison can keep two notmuch databases in sync.
Before I play with this concept, I was wondering if anybody with unison
experience had already tried this.  I didn't see anything in the list
archive/wiki/web.

So any advice before I accidentally destroy my database (aside from
back it up, of course)?


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

[PATCH] fix notmuch_database_open call in addrlookup

[James Vasile]

James Vasile  writes:
> Ethan Glasser-Camp  writes:
>
>> James Vasile  writes:
>>
>>> What's the best way to submit changes to addrlookup?  Right now, it is
>>> out of date vs the latest libnotmuch.  The addrlookup repo is vala code
>>> but the wiki [1] points to a generated c file [2].
>>>
>>> [1] 
>>> http://github.com/spaetz/vala-notmuch/raw/static-sources/src/addrlookup.c
>>> [2] http://notmuchmail.org/emacstips/
>>>
>>> At any rate, a patch to that c file is below.  If you upgraded notmuch
>>> and now addrlookup gives errors about not finding libnotmuch.so.2, this
>>> patch might be what you need.
>>
>> I'd try to contact the author of the code, perhaps by submitting an
>> issue or pull request on the github page for the project. I'm sure he'd
>> prefer a patch to the Vala source.
>>
>> Ethan
>
> Thanks, will do.  My vala is weak, so a patch to the vala source is
> unlikely to make it to the front of my queue this year.  I'll ping
> Sebastian Spaeth directly and via github.
>
> -J

Just to close the loop: I contacted Sebastian and he applied my patch.
I tested the instructions on the wiki and confirmed they are currently
correct against his tree.  He notes that he doesn't currently have time
to monitor the list closely.

Thanks,
-J
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121107/59f88738/attachment.pgp>

[PATCH] fix notmuch_database_open call in addrlookup

[James Vasile]

Ethan Glasser-Camp  writes:

> James Vasile  writes:
>
>> What's the best way to submit changes to addrlookup?  Right now, it is
>> out of date vs the latest libnotmuch.  The addrlookup repo is vala code
>> but the wiki [1] points to a generated c file [2].
>>
>> [1] http://github.com/spaetz/vala-notmuch/raw/static-sources/src/addrlookup.c
>> [2] http://notmuchmail.org/emacstips/
>>
>> At any rate, a patch to that c file is below.  If you upgraded notmuch
>> and now addrlookup gives errors about not finding libnotmuch.so.2, this
>> patch might be what you need.
>
> I'd try to contact the author of the code, perhaps by submitting an
> issue or pull request on the github page for the project. I'm sure he'd
> prefer a patch to the Vala source.
>
> Ethan

Thanks, will do.  My vala is weak, so a patch to the vala source is
unlikely to make it to the front of my queue this year.  I'll ping
Sebastian Spaeth directly and via github.

-J
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121107/9eaa6933/attachment-0001.pgp>

[PATCH] don't show x-foo tags in search view

[James Vasile]

David Bremner  writes:
> James Vasile  writes:
>
>> Austin,
>>
>> Thanks for the helpful comments.  I redid the patch to take a list of
>> regexps.  That way users can banish different kinds of tags or simply
>> list the tags themselves.  I've responded to your comments in text below
>> the patch.
>>
>
> I think the patch is probably OK now contentwise, but the commit message
> is what I quoted above, which is not ideal.  

New commit message:

This patch hides any tags in search view that match the regexps
specified in the list `notmuch-search-hide-tag-regexps`. The match is
case-insensitive.  An empty list (which is the default) will disable
hiding of tags in search view.  The list can be set via setq or the
customize interface.  To hide all tags that begin with "x-" or "X-", set
`notmuch-search-hide-tag-regexps` to "^X-".


>
> As far as being obsoleted by Damien's labeller patches, let's cross that
> bridge when we come to it.  Unless somebody objects, I'd be willing to
> push some version of this now.

Thanks.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121107/d7408da8/attachment.pgp>

Re: [PATCH] don't show x-foo tags in search view

[James Vasile]

David Bremner da...@tethera.net writes:
 James Vasile ja...@hackervisions.org writes:

 Austin,

 Thanks for the helpful comments.  I redid the patch to take a list of
 regexps.  That way users can banish different kinds of tags or simply
 list the tags themselves.  I've responded to your comments in text below
 the patch.


 I think the patch is probably OK now contentwise, but the commit message
 is what I quoted above, which is not ideal.  

New commit message:

This patch hides any tags in search view that match the regexps
specified in the list `notmuch-search-hide-tag-regexps`. The match is
case-insensitive.  An empty list (which is the default) will disable
hiding of tags in search view.  The list can be set via setq or the
customize interface.  To hide all tags that begin with x- or X-, set
`notmuch-search-hide-tag-regexps` to ^X-.



 As far as being obsoleted by Damien's labeller patches, let's cross that
 bridge when we come to it.  Unless somebody objects, I'd be willing to
 push some version of this now.

Thanks.


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

Re: [PATCH] fix notmuch_database_open call in addrlookup

[James Vasile]

Ethan Glasser-Camp ethan.glasser.c...@gmail.com writes:

 James Vasile ja...@hackervisions.org writes:

 What's the best way to submit changes to addrlookup?  Right now, it is
 out of date vs the latest libnotmuch.  The addrlookup repo is vala code
 but the wiki [1] points to a generated c file [2].

 [1] http://github.com/spaetz/vala-notmuch/raw/static-sources/src/addrlookup.c
 [2] http://notmuchmail.org/emacstips/

 At any rate, a patch to that c file is below.  If you upgraded notmuch
 and now addrlookup gives errors about not finding libnotmuch.so.2, this
 patch might be what you need.

 I'd try to contact the author of the code, perhaps by submitting an
 issue or pull request on the github page for the project. I'm sure he'd
 prefer a patch to the Vala source.

 Ethan

Thanks, will do.  My vala is weak, so a patch to the vala source is
unlikely to make it to the front of my queue this year.  I'll ping
Sebastian Spaeth directly and via github.

-J


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

Re: [PATCH] fix notmuch_database_open call in addrlookup

[James Vasile]

James Vasile ja...@hackervisions.org writes:
 Ethan Glasser-Camp ethan.glasser.c...@gmail.com writes:

 James Vasile ja...@hackervisions.org writes:

 What's the best way to submit changes to addrlookup?  Right now, it is
 out of date vs the latest libnotmuch.  The addrlookup repo is vala code
 but the wiki [1] points to a generated c file [2].

 [1] 
 http://github.com/spaetz/vala-notmuch/raw/static-sources/src/addrlookup.c
 [2] http://notmuchmail.org/emacstips/

 At any rate, a patch to that c file is below.  If you upgraded notmuch
 and now addrlookup gives errors about not finding libnotmuch.so.2, this
 patch might be what you need.

 I'd try to contact the author of the code, perhaps by submitting an
 issue or pull request on the github page for the project. I'm sure he'd
 prefer a patch to the Vala source.

 Ethan

 Thanks, will do.  My vala is weak, so a patch to the vala source is
 unlikely to make it to the front of my queue this year.  I'll ping
 Sebastian Spaeth directly and via github.

 -J

Just to close the loop: I contacted Sebastian and he applied my patch.
I tested the instructions on the wiki and confirmed they are currently
correct against his tree.  He notes that he doesn't currently have time
to monitor the list closely.

Thanks,
-J


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

[PATCH] fix notmuch_database_open call in addrlookup

[James Vasile]

What's the best way to submit changes to addrlookup?  Right now, it is
out of date vs the latest libnotmuch.  The addrlookup repo is vala code
but the wiki [1] points to a generated c file [2].

[1] http://github.com/spaetz/vala-notmuch/raw/static-sources/src/addrlookup.c
[2] http://notmuchmail.org/emacstips/

At any rate, a patch to that c file is below.  If you upgraded notmuch
and now addrlookup gives errors about not finding libnotmuch.so.2, this
patch might be what you need.





In the latest version of notmuch in git, notmuch_database_open returns a
status and takes what used to be the return value as a reference
parameter.  This patch adjusts code to pass the db pointer in a
parameter and accept the status as return value.  We don't do anything
with the status at present.

---
 addrlookup.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/addrlookup.c b/addrlookup.c
index 5f724ef..aed77e7 100644
--- a/addrlookup.c
+++ b/addrlookup.c
@@ -804,12 +804,14 @@ void address_matcher_run (AddressMatcher* self, const 
gchar* name) {
gchar** _result_;
gint _result__length1;
gint __result__size_;
+   notmuch_status_t status;
+
g_return_if_fail (self != NULL);
_tmp0_ = g_new0 (notmuch_query_t*, 0);
queries = _tmp0_;
queries_length1 = 0;
_queries_size_ = 0;
-   _tmp1_ = notmuch_database_open (self->priv->user_db_path, 
NOTMUCH_DATABASE_MODE_READ_ONLY);
+   status = notmuch_database_open (self->priv->user_db_path, 
NOTMUCH_DATABASE_MODE_READ_ONLY, &_tmp1_);
_notmuch_database_close0 (self->priv->db);
self->priv->db = _tmp1_;
_tmp2_ = g_strconcat ("tag:", self->priv->user_addrbook_tag, NULL);
-- 
1.7.10.4

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

[PATCH] fix notmuch_database_open call in addrlookup

[James Vasile]

What's the best way to submit changes to addrlookup?  Right now, it is
out of date vs the latest libnotmuch.  The addrlookup repo is vala code
but the wiki [1] points to a generated c file [2].

[1] http://github.com/spaetz/vala-notmuch/raw/static-sources/src/addrlookup.c
[2] http://notmuchmail.org/emacstips/

At any rate, a patch to that c file is below.  If you upgraded notmuch
and now addrlookup gives errors about not finding libnotmuch.so.2, this
patch might be what you need.





In the latest version of notmuch in git, notmuch_database_open returns a
status and takes what used to be the return value as a reference
parameter.  This patch adjusts code to pass the db pointer in a
parameter and accept the status as return value.  We don't do anything
with the status at present.

---
 addrlookup.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/addrlookup.c b/addrlookup.c
index 5f724ef..aed77e7 100644
--- a/addrlookup.c
+++ b/addrlookup.c
@@ -804,12 +804,14 @@ void address_matcher_run (AddressMatcher* self, const 
gchar* name) {
gchar** _result_;
gint _result__length1;
gint __result__size_;
+   notmuch_status_t status;
+
g_return_if_fail (self != NULL);
_tmp0_ = g_new0 (notmuch_query_t*, 0);
queries = _tmp0_;
queries_length1 = 0;
_queries_size_ = 0;
-   _tmp1_ = notmuch_database_open (self-priv-user_db_path, 
NOTMUCH_DATABASE_MODE_READ_ONLY);
+   status = notmuch_database_open (self-priv-user_db_path, 
NOTMUCH_DATABASE_MODE_READ_ONLY, _tmp1_);
_notmuch_database_close0 (self-priv-db);
self-priv-db = _tmp1_;
_tmp2_ = g_strconcat (tag:, self-priv-user_addrbook_tag, NULL);
-- 
1.7.10.4



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

[PATCH] don't show x-foo tags in search view

[James Vasile]

Damien Cassou  writes:
> On Mon, Oct 29, 2012 at 7:57 PM, James Vasile  
> wrote:
>> My filters create tags like x-bogotrained-spam that are for internal
>> bookkeeping.  I don't mind seeing them in the 'show' view, but I didn't
>> want them cluttering my 'search' view.  This patch omits x-foo and X-foo
>> tags from the 'search' view.
>
> what about using notmuch-labeler that let you hide whatever you want
> (or replace it by pictures)?
> https://github.com/DamienCassou/notmuch-labeler
>
> I'm working on integrating it inside notmuch
>

I wasn't aware of labeler.  It looks like it has some nice
functionality.  When it gets integrated into the trunk, I'll use it,
assuming it can match regexps and not just literal strings.

Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121030/ff95776b/attachment.pgp>

[PATCH] don't show x-foo tags in search view

[James Vasile]

Austin,

Thanks for the helpful comments.  I redid the patch to take a list of
regexps.  That way users can banish different kinds of tags or simply
list the tags themselves.  I've responded to your comments in text below
the patch.

---
 emacs/notmuch.el |   26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f9454d8..05aa114 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -775,6 +775,21 @@ non-authors is found, assume that all of the authors 
match."
  (overlay-put overlay 'isearch-open-invisible #'delete-overlay)))
   (insert padding

+  
+(defcustom notmuch-search-hide-tag-regexps '()
+  "List of regular expressionss specifying tags to hide in search view.
+
+Notmuch will hide any tags in search view that match the regexps
+specified in the list `notmuch-search-hide-tag-regexp`.  The
+match is case-insensitive.
+
+If you are not comfortable with regular expressions, a list of
+tag words will work, assuming those tags use only alphanumeric
+characters.  An empty list will disable hiding of tags in search
+view.  The list can be set via setq or the customize interface."
+  :type '(repeat  regexp)
+  :group 'notmuch-search)
+
 (defun notmuch-search-insert-field (field format-string result)
   (cond
((string-equal field "date")
@@ -793,7 +808,16 @@ non-authors is found, assume that all of the authors 
match."
 (notmuch-search-insert-authors format-string (plist-get result :authors)))

((string-equal field "tags")
-(let ((tags-str (mapconcat 'identity (plist-get result :tags) " ")))
+(let ((tags-str
+  (mapconcat 'identity
+ (let ((case-fold-search t))
+   (remove-if
+(lambda (tag)
+  (find tag notmuch-search-hide-tag-regexps
+:test (lambda (tag regexp)
+(string-match regexp tag
+(plist-get result :tags)))
+ " ")))
   (insert (propertize (format format-string tags-str)
  'face 'notmuch-tag-face))

-- 
1.7.10.4


Austin Clements  writes:
> I like it.

Thanks.

[snip]

> I have no idea why, but Emacs typically uses "regexp" instead of
> "regex".

It probably has something to do with rhyming with 'sexp'. ;) It's good
to conform to the vernacular, so I fixed it.

>
>> +
>> +Leave blank to disable hiding of tags in search view.
>
> Saying "Leave blank" supposes that the user knows what the default
> value is.  How about "An empty string disables hiding of tags in
> search view."?

I'm now using a list, but yes, "an empty list" is a good way to describe
it.

>
> Even better, though, would be to use nil to indicate this, since "" is
> a perfectly valid regexp and matches everything.  In that case, this
> should say something like "If nil, no tags will be hidden in search
> view."

"An empty list" is nil, so I think this is covered by my changes.  If
you think the defcustom text could be clearer, I'd appreciate edits.

>
>> +Note: elisp regexes are case-insensitive"
>
> Likewise, "regexps".  Also, Elisp regexps are not, in general,
> case-insensitive.  If we want to control this, we should bind
> case-fold-search to nil around the string-match below and say
> something here like "Matching is case-insensitive."

Good point.

>
>> +  :type 'string
>
> Better would be 'regexp.  Or, '(choice (const :tag "None" nil) regexp)
> to allow nil or a regexp.

Changed to 'regexp.

[snip]

> It would be simpler and more robust to use remove-if here.  What about
> something like
>
>   (let ((tags-str
>  (mapconcat 'identity
> (if notmuch-search-hide-tag-regex
> (let ((case-fold-search t))
>   (remove-if
>(apply-partially #'string-match
> notmuch-search-hide-tag-regex)
>(plist-get result :tags)))
>   (plist-get result :tags))
> " ")))

That's a good idea.  I adjusted the code to use remove-if, and it is
improved by the change.

Thanks,
James
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Re: [PATCH] don't show x-foo tags in search view

[James Vasile]

Austin,

Thanks for the helpful comments.  I redid the patch to take a list of
regexps.  That way users can banish different kinds of tags or simply
list the tags themselves.  I've responded to your comments in text below
the patch.

---
 emacs/notmuch.el |   26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f9454d8..05aa114 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -775,6 +775,21 @@ non-authors is found, assume that all of the authors 
match.
  (overlay-put overlay 'isearch-open-invisible #'delete-overlay)))
   (insert padding
 
+  
+(defcustom notmuch-search-hide-tag-regexps '()
+  List of regular expressionss specifying tags to hide in search view.
+
+Notmuch will hide any tags in search view that match the regexps
+specified in the list `notmuch-search-hide-tag-regexp`.  The
+match is case-insensitive.
+
+If you are not comfortable with regular expressions, a list of
+tag words will work, assuming those tags use only alphanumeric
+characters.  An empty list will disable hiding of tags in search
+view.  The list can be set via setq or the customize interface.
+  :type '(repeat  regexp)
+  :group 'notmuch-search)
+
 (defun notmuch-search-insert-field (field format-string result)
   (cond
((string-equal field date)
@@ -793,7 +808,16 @@ non-authors is found, assume that all of the authors 
match.
 (notmuch-search-insert-authors format-string (plist-get result :authors)))
 
((string-equal field tags)
-(let ((tags-str (mapconcat 'identity (plist-get result :tags)  )))
+(let ((tags-str
+  (mapconcat 'identity
+ (let ((case-fold-search t))
+   (remove-if
+(lambda (tag)
+  (find tag notmuch-search-hide-tag-regexps
+:test (lambda (tag regexp)
+(string-match regexp tag
+(plist-get result :tags)))
+  )))
   (insert (propertize (format format-string tags-str)
  'face 'notmuch-tag-face))
 
-- 
1.7.10.4


Austin Clements amdra...@mit.edu writes:
 I like it.

Thanks.

[snip]

 I have no idea why, but Emacs typically uses regexp instead of
 regex.

It probably has something to do with rhyming with 'sexp'. ;) It's good
to conform to the vernacular, so I fixed it.


 +
 +Leave blank to disable hiding of tags in search view.

 Saying Leave blank supposes that the user knows what the default
 value is.  How about An empty string disables hiding of tags in
 search view.?

I'm now using a list, but yes, an empty list is a good way to describe
it.


 Even better, though, would be to use nil to indicate this, since  is
 a perfectly valid regexp and matches everything.  In that case, this
 should say something like If nil, no tags will be hidden in search
 view.

An empty list is nil, so I think this is covered by my changes.  If
you think the defcustom text could be clearer, I'd appreciate edits.


 +Note: elisp regexes are case-insensitive

 Likewise, regexps.  Also, Elisp regexps are not, in general,
 case-insensitive.  If we want to control this, we should bind
 case-fold-search to nil around the string-match below and say
 something here like Matching is case-insensitive.

Good point.


 +  :type 'string

 Better would be 'regexp.  Or, '(choice (const :tag None nil) regexp)
 to allow nil or a regexp.

Changed to 'regexp.

[snip]

 It would be simpler and more robust to use remove-if here.  What about
 something like

   (let ((tags-str
  (mapconcat 'identity
 (if notmuch-search-hide-tag-regex
 (let ((case-fold-search t))
   (remove-if
(apply-partially #'string-match
 notmuch-search-hide-tag-regex)
(plist-get result :tags)))
   (plist-get result :tags))
  )))

That's a good idea.  I adjusted the code to use remove-if, and it is
improved by the change.

Thanks,
James


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

Re: [PATCH] don't show x-foo tags in search view

[James Vasile]

Damien Cassou damien.cas...@gmail.com writes:
 On Mon, Oct 29, 2012 at 7:57 PM, James Vasile ja...@hackervisions.org wrote:
 My filters create tags like x-bogotrained-spam that are for internal
 bookkeeping.  I don't mind seeing them in the 'show' view, but I didn't
 want them cluttering my 'search' view.  This patch omits x-foo and X-foo
 tags from the 'search' view.

 what about using notmuch-labeler that let you hide whatever you want
 (or replace it by pictures)?
 https://github.com/DamienCassou/notmuch-labeler

 I'm working on integrating it inside notmuch


I wasn't aware of labeler.  It looks like it has some nice
functionality.  When it gets integrated into the trunk, I'll use it,
assuming it can match regexps and not just literal strings.

Thanks!


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

[PATCH] don't show x-foo tags in search view

[James Vasile]

This patch hides any tags in search view that match the regex specified
in `notmuch-search-hide-tag-regex`.  That variable can be set via setq
or the customize interface.  To hide all tags that begin with "x-" or
"X-", set `notmuch-search-hide-tag-regex` to "^X-".

---
 emacs/notmuch.el |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f9454d8..4bff538 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -775,6 +775,14 @@ non-authors is found, assume that all of the authors 
match."
  (overlay-put overlay 'isearch-open-invisible #'delete-overlay)))
   (insert padding

+(defcustom notmuch-search-hide-tag-regex ""
+  "Regex specifying tags to hide in search view.
+
+Leave blank to disable hiding of tags in search view.
+Note: elisp regexes are case-insensitive"
+  :type 'string
+  :group 'notmuch-search)
+
 (defun notmuch-search-insert-field (field format-string result)
   (cond
((string-equal field "date")
@@ -793,7 +801,13 @@ non-authors is found, assume that all of the authors 
match."
 (notmuch-search-insert-authors format-string (plist-get result :authors)))

((string-equal field "tags")
-(let ((tags-str (mapconcat 'identity (plist-get result :tags) " ")))
+(let ((tags-str (mapconcat 'identity
+  (delq nil
+(mapcar (lambda (x) (if (and (not (equal 
notmuch-search-hide-tag-regex ""))
+ (string-match 
notmuch-search-hide-tag-regex x))
+nil
+x)) (plist-get 
result :tags)))
+  " ")))
   (insert (propertize (format format-string tags-str)
  'face 'notmuch-tag-face))

-- 
1.7.10.4

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

[PATCH] don't show x-foo tags in search view

[James Vasile]

David Bremner  writes:
> James Vasile  writes:
>
>> My filters create tags like x-bogotrained-spam that are for internal
>> bookkeeping.  I don't mind seeing them in the 'show' view, but I didn't
>> want them cluttering my 'search' view.  This patch omits x-foo and X-foo
>> tags from the 'search' view.
>
> I understand this scratches your itch, but what about something more
> customizable?
>
> d

I thought it was fairly general as is, but you're right it could be more
customizable.  I'll rewrite it with a regex the user can customize.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121029/4933c10f/attachment.pgp>

[PATCH] don't show x-foo tags in search view

[James Vasile]

My filters create tags like x-bogotrained-spam that are for internal
bookkeeping.  I don't mind seeing them in the 'show' view, but I didn't
want them cluttering my 'search' view.  This patch omits x-foo and X-foo
tags from the 'search' view.

---
 emacs/notmuch.el |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f9454d8..90fafbf 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -793,7 +793,12 @@ non-authors is found, assume that all of the authors 
match."
 (notmuch-search-insert-authors format-string (plist-get result :authors)))

((string-equal field "tags")
-(let ((tags-str (mapconcat 'identity (plist-get result :tags) " ")))
+(let ((tags-str (mapconcat 'identity
+  (delq nil
+(mapcar (lambda (x) (if (equal (upcase 
(truncate-string-to-width  x 2)) "X-")
+nil
+(identity x))) 
(plist-get result :tags)))
+  " ")))
   (insert (propertize (format format-string tags-str)
  'face 'notmuch-tag-face))

-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Notmuch search missing mail id

[James Vasile]

Tomi Ollila  writes:
> On Mon, Oct 29 2012, James Vasile  wrote:
>
>> I received the attached piece of spam telling me about an exciting
>> investment opportunity.  Notmuch pulled it in to the database, noting
>> the message id.  But then it seems to stop paying attention to the
>> message id.
>>
>> notmuch can find the mail when I search by the from field:
>>
>> $ notmuch search "from:caroline horn"
>> thread:bcb7  Today 09:29 [1/1] Caroline Horn; This Company is on 
>> the rise (hv inbox unread)
>>
>> But not by the message id:
>> $ notmuch search id:000801cdb5da$17673470$26448589 at microsof00t4ko3r
>> $
>
> Try 
>
> $ notmuch search id:'000801cdb5da$17673470$26448589 at microsof00t4ko3r'
>
> so that the $s are not expanded...
>
> note that id:"..." does not suffice as shell expands $ & ` inside double
> quotes.

Tomi, that's a good catch and one I should have noticed.  Thanks much
for the help!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121029/35aa6d42/attachment.pgp>

Notmuch search missing mail id

[James Vasile]

I received the attached piece of spam telling me about an exciting
investment opportunity.  Notmuch pulled it in to the database, noting
the message id.  But then it seems to stop paying attention to the
message id.

notmuch can find the mail when I search by the from field:

$ notmuch search "from:caroline horn"
thread:bcb7  Today 09:29 [1/1] Caroline Horn; This Company is on 
the rise (hv inbox unread)

But not by the message id:
$ notmuch search id:000801cdb5da$17673470$26448589 at microsof00t4ko3r
$

Notmuch has correctly pulled the id into the database:
$ notmuch show "from:caroline horn" | grep "id:" | sed "s/.*\(id:[^ ]*\).*/\1/"
id:000801cdb5da$17673470$26448589 at microsof00t4ko3r

If notmuch knows the id but won't match it in a search, that looks like
a bug to me.

On a related matter, I have a script that pulls the message id header

Notmuch search missing mail id

[James Vasile]

I received the attached piece of spam telling me about an exciting
investment opportunity.  Notmuch pulled it in to the database, noting
the message id.  But then it seems to stop paying attention to the
message id.

notmuch can find the mail when I search by the from field:

$ notmuch search from:caroline horn
thread:bcb7  Today 09:29 [1/1] Caroline Horn; This Company is on 
the rise (hv inbox unread)

But not by the message id:
$ notmuch search id:000801cdb5da$17673470$26448589@microsof00t4ko3r
$

Notmuch has correctly pulled the id into the database:
$ notmuch show from:caroline horn | grep id: | sed s/.*\(id:[^ ]*\).*/\1/
id:000801cdb5da$17673470$26448589@microsof00t4ko3r

If notmuch knows the id but won't match it in a search, that looks like
a bug to me.

On a related matter, I have a script that pulls the message id header
From a mail file and then uses notmuch tag id:foo to tag that file.  But
if notmuch sometimes fails to find the id, maybe there is there a better
way to do it?

Thanks,
James



binDCNcXFt8Bc.bin
Description: spam mail


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

Re: Notmuch search missing mail id

[James Vasile]

Tomi Ollila tomi.oll...@iki.fi writes:
 On Mon, Oct 29 2012, James Vasile ja...@hackervisions.org wrote:

 I received the attached piece of spam telling me about an exciting
 investment opportunity.  Notmuch pulled it in to the database, noting
 the message id.  But then it seems to stop paying attention to the
 message id.

 notmuch can find the mail when I search by the from field:

 $ notmuch search from:caroline horn
 thread:bcb7  Today 09:29 [1/1] Caroline Horn; This Company is on 
 the rise (hv inbox unread)

 But not by the message id:
 $ notmuch search id:000801cdb5da$17673470$26448589@microsof00t4ko3r
 $

 Try 

 $ notmuch search id:'000801cdb5da$17673470$26448589@microsof00t4ko3r'

 so that the $s are not expanded...

 note that id:... does not suffice as shell expands $  ` inside double
 quotes.

Tomi, that's a good catch and one I should have noticed.  Thanks much
for the help!


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

[PATCH] don't show x-foo tags in search view

[James Vasile]

My filters create tags like x-bogotrained-spam that are for internal
bookkeeping.  I don't mind seeing them in the 'show' view, but I didn't
want them cluttering my 'search' view.  This patch omits x-foo and X-foo
tags from the 'search' view.

---
 emacs/notmuch.el |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f9454d8..90fafbf 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -793,7 +793,12 @@ non-authors is found, assume that all of the authors 
match.
 (notmuch-search-insert-authors format-string (plist-get result :authors)))
 
((string-equal field tags)
-(let ((tags-str (mapconcat 'identity (plist-get result :tags)  )))
+(let ((tags-str (mapconcat 'identity
+  (delq nil
+(mapcar (lambda (x) (if (equal (upcase 
(truncate-string-to-width  x 2)) X-)
+nil
+(identity x))) 
(plist-get result :tags)))
+   )))
   (insert (propertize (format format-string tags-str)
  'face 'notmuch-tag-face))
 
-- 
1.7.10.4


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

Re: [PATCH] don't show x-foo tags in search view

[James Vasile]

David Bremner da...@tethera.net writes:
 James Vasile ja...@hackervisions.org writes:

 My filters create tags like x-bogotrained-spam that are for internal
 bookkeeping.  I don't mind seeing them in the 'show' view, but I didn't
 want them cluttering my 'search' view.  This patch omits x-foo and X-foo
 tags from the 'search' view.

 I understand this scratches your itch, but what about something more
 customizable?

 d

I thought it was fairly general as is, but you're right it could be more
customizable.  I'll rewrite it with a regex the user can customize.


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

Re: [PATCH] don't show x-foo tags in search view

[James Vasile]

This patch hides any tags in search view that match the regex specified
in `notmuch-search-hide-tag-regex`.  That variable can be set via setq
or the customize interface.  To hide all tags that begin with x- or
X-, set `notmuch-search-hide-tag-regex` to ^X-.

---
 emacs/notmuch.el |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f9454d8..4bff538 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -775,6 +775,14 @@ non-authors is found, assume that all of the authors 
match.
  (overlay-put overlay 'isearch-open-invisible #'delete-overlay)))
   (insert padding
 
+(defcustom notmuch-search-hide-tag-regex 
+  Regex specifying tags to hide in search view.
+
+Leave blank to disable hiding of tags in search view.
+Note: elisp regexes are case-insensitive
+  :type 'string
+  :group 'notmuch-search)
+
 (defun notmuch-search-insert-field (field format-string result)
   (cond
((string-equal field date)
@@ -793,7 +801,13 @@ non-authors is found, assume that all of the authors 
match.
 (notmuch-search-insert-authors format-string (plist-get result :authors)))
 
((string-equal field tags)
-(let ((tags-str (mapconcat 'identity (plist-get result :tags)  )))
+(let ((tags-str (mapconcat 'identity
+  (delq nil
+(mapcar (lambda (x) (if (and (not (equal 
notmuch-search-hide-tag-regex ))
+ (string-match 
notmuch-search-hide-tag-regex x))
+nil
+x)) (plist-get 
result :tags)))
+   )))
   (insert (propertize (format format-string tags-str)
  'face 'notmuch-tag-face))
 
-- 
1.7.10.4



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

Re: [ANN] notmuch-labeler: Improves notmuch way of displaying labels

[James Vasile]

+1 for merging this upstream.

Thanks.


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

[ANN] notmuch-labeler: Improves notmuch way of displaying labels

[James Vasile]

+1 for merging this upstream.

Thanks.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

JSON readtable error when replying

[James Vasile]

It's a JSON parsing error.  I don't know if it's a known error, but it's
not one I've seen chatter about on this list.  I've gotten it too and
haven't really looked into it.  I suspect it is a bug in the Emacs JSON
parsing function. but that I can only support that suspicion with
hunches and slander.  

Just to round out my "me too" report: I sometimes get that error on
opening a thread from the search view.  It seems to be intermittent in
that a thread will open just fine and then I'll select it again and I'll
get the error.  But that observation might be faulty memory.

Best regards,
James
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Re: JSON readtable error when replying

[James Vasile]

It's a JSON parsing error.  I don't know if it's a known error, but it's
not one I've seen chatter about on this list.  I've gotten it too and
haven't really looked into it.  I suspect it is a bug in the Emacs JSON
parsing function. but that I can only support that suspicion with
hunches and slander.  

Just to round out my me too report: I sometimes get that error on
opening a thread from the search view.  It seems to be intermittent in
that a thread will open just fine and then I'll select it again and I'll
get the error.  But that observation might be faulty memory.

Best regards,
James


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

Why not tags inside messages?

[James Vasile]

On Sat, 07 Apr 2012 18:46:03 +0200, David Belohrad  wrote:
> Dear all,
> 
> I'd love to use notmuch with offline imap ?to work rather on local
> copy of messages, than using remote notmuch, which is slightly slower
> due to bandwidth limitation of my vdsl line. There is however
> fundamental problem of syncing flags between two instances of
> notmuch. So my question is, whether it would be possible, when tagging
> message, to store the tag as well in the message itself. Might this
> help to sync across multiple instances?

Re: Why not tags inside messages?

[James Vasile]

On Sat, 07 Apr 2012 18:46:03 +0200, David Belohrad da...@belohrad.ch wrote:
 Dear all,
 
 I'd love to use notmuch with offline imap  to work rather on local
 copy of messages, than using remote notmuch, which is slightly slower
 due to bandwidth limitation of my vdsl line. There is however
 fundamental problem of syncing flags between two instances of
 notmuch. So my question is, whether it would be possible, when tagging
 message, to store the tag as well in the message itself. Might this
 help to sync across multiple instances?

From my POV, there are two problems here.  

First is that storing tags in multiple places (one in db and once in
each message copy) leads to the question of which set of tags is
authoritative.  Syncing those tags is additional complexity.  And as a
mail moves to another system with a different notmuch db, what happens
to the tags?

Second is that your tags might then be public because
forwarding/replying to a message will, depending on your mail client,
also get included.

 
 Another thing is, that I'd love to have native android app working
 over remote notmuch to work as my email agent. Is there anything like
 this? I guess not...

Not that I'm aware of, but if anybody is working on this, I'd love to
know and see if I can help.


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

Passwordless multi-account SMTP

[James Vasile]

On Tue, 3 Apr 2012 17:29:07 +0200, Jacek Generowicz  wrote:
> Hello,
> 
> I'm trying to use notmuch from Emacs. I have a number of SMTP accounts
> through which I would need to send mail. Suggested solutions I have
> found fall into 3 categories:
> 
> + Gnus posting styles. (I'd rather stay clear of gnus, at present.)
> 
> + Writing plaintext passwords in the MSMTP config files. (I'm rather
>   relutctant to leave plaintext passwords lying around.)
> 
> + Emacs' own SMTP library. (I don't understand how to get it to deal
>   with many accounts in a non-gnus based way. It also seems to be
>   undergoing an interface change in the transition from Emacs 23 to
>   24, and it was already confusing enough without that complication.)
> 
> To further complicate matters, I'm looking for a solution which queues
> any messages which are sent while the machine is offline. (It seems
> that MSMTP and Emacs SMTP library do offer some help in those
> respects.)
> 
> Hints gratefully received.


I use a slightly modified msmtpq for queuing and I have some hooks that
run profiles to choose SMTP server and other options based on
sender/receiver/last search.  Passwords are plain text but my fs is
encrypted.  If you want, you could encrypt the password file with gpg
and use gpg-agent to grab the password as needed from the file.

Good luck.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Re: Passwordless multi-account SMTP

[James Vasile]

On Tue, 3 Apr 2012 17:29:07 +0200, Jacek Generowicz jacek.generow...@cern.ch 
wrote:
 Hello,
 
 I'm trying to use notmuch from Emacs. I have a number of SMTP accounts
 through which I would need to send mail. Suggested solutions I have
 found fall into 3 categories:
 
 + Gnus posting styles. (I'd rather stay clear of gnus, at present.)
 
 + Writing plaintext passwords in the MSMTP config files. (I'm rather
   relutctant to leave plaintext passwords lying around.)
 
 + Emacs' own SMTP library. (I don't understand how to get it to deal
   with many accounts in a non-gnus based way. It also seems to be
   undergoing an interface change in the transition from Emacs 23 to
   24, and it was already confusing enough without that complication.)
 
 To further complicate matters, I'm looking for a solution which queues
 any messages which are sent while the machine is offline. (It seems
 that MSMTP and Emacs SMTP library do offer some help in those
 respects.)
 
 Hints gratefully received.


I use a slightly modified msmtpq for queuing and I have some hooks that
run profiles to choose SMTP server and other options based on
sender/receiver/last search.  Passwords are plain text but my fs is
encrypted.  If you want, you could encrypt the password file with gpg
and use gpg-agent to grab the password as needed from the file.

Good luck.


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

[PATCH v2]: contrib/notmuch-mutt

[James Vasile]

I can't wait to give this a try.  Thanks much!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

a DoS vulnerability associated with conflated Message-IDs?

[James Vasile]

On Thu, 08 Mar 2012 11:37:09 -0500, Daniel Kahn Gillmor  wrote:
> Any ideas on how to approach this?

Treat messages with the same ID but different hashes as different?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Re: a DoS vulnerability associated with conflated Message-IDs?

[James Vasile]

On Thu, 08 Mar 2012 11:37:09 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 Any ideas on how to approach this?

Treat messages with the same ID but different hashes as different?


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

Possible bug in gpg signing replies

[James Vasile]

When using 'mml-secure-sign-pgpmime to sign one part of an email, valid
sigs get attached to new emails but not to replies.  Instead, when I
reply to a message, the signing directive seems to be inserted as plain
text and is not processed.

Switching to the 'mml-secure-message-sign-pgpmime, which signs the whole
message, appears to work for both replies and new messages.

I'm content to use the form that works, but I thought others might want
to confirm the bug and fix it if it is real.

Regards,
James
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Possible bug in gpg signing replies

[James Vasile]

When using 'mml-secure-sign-pgpmime to sign one part of an email, valid
sigs get attached to new emails but not to replies.  Instead, when I
reply to a message, the signing directive seems to be inserted as plain
text and is not processed.

Switching to the 'mml-secure-message-sign-pgpmime, which signs the whole
message, appears to work for both replies and new messages.

I'm content to use the form that works, but I thought others might want
to confirm the bug and fix it if it is real.

Regards,
James


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

[afew] announcing afew, an universal tagging solution with some fancy features

[James Vasile]

I'm tring to figure out how to use afew.  It looks interesting, but
gives me surprising results.

I did `afew --learn spam -- tag:spam` and believe this tells afew that
all the messages matching tag:spam should be classified as spam.  But if
that is right, why would `afew -c spam -- tag:spam` then show me a bunch
of messages that are tagged spam by notmuch but not classified spam by
afew?

How do I train afew when I correct it's mistakes?  Is that what `afew
update` is for?  What does "update the reference category" mean?

Thanks much,
James

Re: [afew] announcing afew, an universal tagging solution with some fancy features

[James Vasile]

I'm tring to figure out how to use afew.  It looks interesting, but
gives me surprising results.

I did `afew --learn spam -- tag:spam` and believe this tells afew that
all the messages matching tag:spam should be classified as spam.  But if
that is right, why would `afew -c spam -- tag:spam` then show me a bunch
of messages that are tagged spam by notmuch but not classified spam by
afew?

How do I train afew when I correct it's mistakes?  Is that what `afew
update` is for?  What does update the reference category mean?

Thanks much,
James
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

BiDi

[James Vasile]

On Thu, 02 Feb 2012 09:44:07 -0800, Jameson Graef Rollins  wrote:
> On Tue, 24 Jan 2012 20:08:14 +, Clint Adams  wrote:
> > I just received an email in RTL script and it was rendered incorrectly
> > in the emacs interface.  Does anyone know what to do about this?
> 
> More info please.  What is "RTL script"?  Is that "right to left"?  If
> so, yikes.  I can't even imagine what a mess that would have looked
> like.  Another argument against this crazy indenting stuff we do.  I
> hope the thread was also indenting from the right!
> 
> jamie.
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Is anybody interested in a more mutt-like single-email view with a
threaded index?  No indenting, no waiting forever for long threads to
fontify, no wading through a long thread looking for the one email you
actually want.

Displaying tags with many messages very slow in Emacs

[James Vasile]

On August 20th, I sent a message to this list (Message-ID:
<87vctrq4or.fsf at hackervisions.org>) that limits the view to a small
number threads.  You can set the number of threads (or turn it off).  I
did this because I never want to page through more than a screen or two
of threads.  If I need more results, I filter my search or choose better
search terms.  This speeds things up considerably on my (admittedly old)
machine.

When I posted the patch, Daniel Schoepe suggested a few improvements.  I
didn't make those improvements, but I suppose I should.

Best,
James

Re: Displaying tags with many messages very slow in Emacs

[James Vasile]

On August 20th, I sent a message to this list (Message-ID:
87vctrq4or@hackervisions.org) that limits the view to a small
number threads.  You can set the number of threads (or turn it off).  I
did this because I never want to page through more than a screen or two
of threads.  If I need more results, I filter my search or choose better
search terms.  This speeds things up considerably on my (admittedly old)
machine.

When I posted the patch, Daniel Schoepe suggested a few improvements.  I
didn't make those improvements, but I suppose I should.

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

[PATCH] Skip dot files in `notmuch new`

[James Vasile]

No known mail client or fetch tool stores mail in dot files, because
files that start with '.' are usually used to store metadata
(i.e. state or configuration) as opposed to subject-matter data.

Some mail fetch tools (including mbsync) and clients use dot files in
maildirs to store metadata.  Notmuch should not warn that it is
ignoring these files, since it *should* ignore them.  Indeed, it
should ignore all dot files.
---
 notmuch-new.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index 7d17793..87ee07e 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -428,6 +428,10 @@ add_files_recursive (notmuch_database_t *notmuch,
continue;
}

+   /* Don't add dot files. */
+   if (entry->d_name[0] == '.')
+   continue;
+
/* We're now looking at a regular file that doesn't yet exist
 * in the database, so add it. */
next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
-- 
1.7.5.4

Re: [PATCH] Do not query on notmuch-search exit

[James Vasile]

Thanks for this, Michal.  I've applied it to my local tree.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Return maximum of 150 results

[James Vasile]

On Fri, 19 Aug 2011 17:00:23 +0200, Michal Sojka  wrote:
> If you really want this behavior, I propose to make the default value
> of notmuch-max-results infinity.

I'm attaching a revised patch that does as you suggest.  Thanks.

-- next part --
A non-text attachment was scrubbed...
Name: 0001-Limit-number-of-threads-returned-by-search-in-emacs.patch
Type: text/x-diff
Size: 1509 bytes
Desc: not available
URL: 

[PATCH] Added --initial-index and --last-index to search/show

[James Vasile]

On Sat, 20 Aug 2011 12:21:26 +0100, Patrick Totzke  wrote:
Non-text part: multipart/mixed
> 
> 
> Hi!
> A very good idea indeed! This could become quite handy speeding up my 
> interface.
> One question: What do you (intend to) do to ensure that accumulated results
> 'add up well'? 

I intend to do nothing.  It's up to the interface to handle this, if it
needs handling at all.

> Consider the following: you query some 10 threads, the user tags one of them
> so that it doesn't macht anymore and afterwards you list the next 100 threads.
> After the tagging, the number of hits decreases, so if you query
> from hit number 101 to 200, you will not return the 100th (now 99th)
> thread at all.

The interface could keep track of threads deleted/untagged and adjust
accordingly.

Or I suppose one could also implement --initial-msgid, --last-msgid,
--num-threads, etc.  Set --initial-msgid to the last message in your
current view.  Set --num-threads to 100.  That should do it.

> 
> Ok, one could always list all threads up to the one one is interested in but 
> that
> would make refreshing the list slower and slower when you keep
> scrolling down..

Personally, I think users should be discouraged from scrolling and
scrolling.  Notmuch is a *search* tool.  If the mail you want isn't in
the first page or so, you're using the tool wrong.  

-J

Re: [PATCH] Added --initial-index and --last-index to search/show

[James Vasile]

On Sat, 20 Aug 2011 12:21:26 +0100, Patrick Totzke 
patricktot...@googlemail.com wrote:
Non-text part: multipart/mixed
 
 
 Hi!
 A very good idea indeed! This could become quite handy speeding up my 
 interface.
 One question: What do you (intend to) do to ensure that accumulated results
 'add up well'? 

I intend to do nothing.  It's up to the interface to handle this, if it
needs handling at all.

 Consider the following: you query some 10 threads, the user tags one of them
 so that it doesn't macht anymore and afterwards you list the next 100 threads.
 After the tagging, the number of hits decreases, so if you query
 from hit number 101 to 200, you will not return the 100th (now 99th)
 thread at all.

The interface could keep track of threads deleted/untagged and adjust
accordingly.

Or I suppose one could also implement --initial-msgid, --last-msgid,
--num-threads, etc.  Set --initial-msgid to the last message in your
current view.  Set --num-threads to 100.  That should do it.

 
 Ok, one could always list all threads up to the one one is interested in but 
 that
 would make refreshing the list slower and slower when you keep
 scrolling down..

Personally, I think users should be discouraged from scrolling and
scrolling.  Notmuch is a *search* tool.  If the mail you want isn't in
the first page or so, you're using the tool wrong.  

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

Re: [PATCH] Return maximum of 150 results

[James Vasile]

On Fri, 19 Aug 2011 17:00:23 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
 If you really want this behavior, I propose to make the default value
 of notmuch-max-results infinity.

I'm attaching a revised patch that does as you suggest.  Thanks.

From d0421e4308473347b31f5537eaec93b137084060 Mon Sep 17 00:00:00 2001
From: James Vasile ja...@hackervisions.org
Date: Sat, 20 Aug 2011 14:58:47 -0400
Subject: [PATCH] Limit number of threads returned by search in emacs

Set notmuch-max-results to the maximum number of results the
client should show.  Setting notmuch-max-results to 0 (the
default) does not limit search results (i.e. limits them to
infinity).

This patch requries your version of notmuch to implement the
--last-index parameter.  A patch to implement this parameter was
posted to the notmuch mailing list as
id:8739gyw0zh@opensourcematters.org.
---
 emacs/notmuch.el |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..887d696 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -882,6 +882,7 @@ characters as well as `_.+-'.
 	   (concat *notmuch-search- query *))
 	  )))
 
+(defvar notmuch-max-results 0)
 ;;;###autoload
 (defun notmuch-search (query optional oldest-first target-thread target-line continuation)
   Run \notmuch search\ with the given query string and display results.
@@ -913,6 +914,9 @@ The optional parameters are used as follows:
 	(let ((proc (start-process
 		 notmuch-search buffer
 		 notmuch-command search
+		 (if ( notmuch-max-results 0)
+			 (format --last-index=%d notmuch-max-results)
+			 )
 		 (if oldest-first
 			 --sort=oldest-first
 		   --sort=newest-first)
-- 
1.7.5.4

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

[PATCH] Added --initial-index and --last-index to search/show

[James Vasile]

On Fri, 19 Aug 2011 11:55:11 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Thu, 18 Aug 2011 23:09:54 -0400, James Vasile  
> wrote:
> > This patch implements --initial-index and --last-index as options to
> > search and show.  It lets you select the xth through the yth message
> > and receive results that pertain only to those messages.
> 
> Hi, James.  Thanks for working on this feature.  I don't have time to
> review this at the moment, but I just wanted to mention that the idea
> behind this feature has come up in the past as a way to significantly
> increase usability and performance of the VIM interface.  Since VIM does
> not support asynchronous file loading, this feature could be used to
> efficiently process large search results by only loading one page of
> results at a time.  I highly recommend that the VIM interface developers
> take this and run with it.  I'm sure this could be used to actually get
> the VIM interface over the hump to being fully functional.

As a former vim user, this makes me quite happy.  Thanks!

[PATCH] Return maximum of 150 results

[James Vasile]

On Fri, 19 Aug 2011 18:00:36 +0200, Michal Sojka  wrote:
> > On my system, I routinely do searches that return 15000+ messages
> > when I'm only interested in the first several.  When I hit Q, Emacs
> > annoyingly asks me for permission to kill the buffer because it has
> > a running process.  And emacs lags as it processes all that data.
> 
> Ahh, I almost forget about this. I use this patch to disable this.

Nice.  That's a good solution.

> 
> -Michal
> 
> --8<---cut here---start->8---
> >From 0e0ae662026f4a17b882bb33140e0bb62e8da995 Mon Sep 17 00:00:00 2001
> From: Michal Sojka 
> Date: Fri, 19 Aug 2011 17:58:40 +0200
> Subject: [PATCH] Do not query on notmuch-search exit
> 
> Emacs 23.2 queries by default about killing existing processes. Disable
> this behavior for notmuch. I'm not sure whether this works with earlier
> versions.
> ---
>  emacs/notmuch.el |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index 3d82f0d..8858f3e 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -858,7 +858,9 @@ The optional parameters are used as follows:
>  "--sort=newest-first")
>query)))
> (set-process-sentinel proc 'notmuch-search-process-sentinel)
> -   (set-process-filter proc 'notmuch-search-process-filter
> +   (set-process-filter proc 'notmuch-search-process-filter)
> +   (set-process-query-on-exit-flag proc nil)))
> +  )
>  (run-hooks 'notmuch-search-hook)))
>  
>  (defun notmuch-search-refresh-view ()
> -- 
> 1.7.5.4
> 
> --8<---cut here---end--->8---

[PATCH] Return maximum of 150 results

[James Vasile]

On Fri, 19 Aug 2011 17:00:23 +0200, Michal Sojka  wrote:
> Hi James,
> 
> On Fri, 19 Aug 2011, James Vasile wrote:
> > Display a maximum of 150 results when searching for messages.  This
> > prevents client lag when searches return thousands of results you'll
> > never look at
> 
> I would not like this feature. If I search for something I really want
> to see everything. For example, if I want to remove inbox from many
> messages, I would search for them and press "-inbox". With your
> patch I'd not be sure whether there are some more messages or not.

Ah, I do such things from the commandline, but you are right that there
is a good use for such.

> 
> > (use the Filter command to cut down results that exceed 150).
> 
> You can start filtering while the previous search is still running, so I
> do not see problem with having bug number of results.

Yes, you can filter while the search runs, but that's not the only
problem with huge search results.  On my system, I routinely do searches
that return 15000+ messages when I'm only interested in the first
several.  When I hit Q, Emacs annoyingly asks me for permission to kill
the buffer because it has a running process.  And emacs lags as it
processes all that data.

> > 
> > Number of results can be changed by setting notmuch-max-results.
> 
> If you really want this behavior, I propose to make the default value
> of notmuch-max-results infinity.

Yes, that's probably the right answer.  I'll rework the patch to do that.

[PATCH] Return maximum of 150 results

[James Vasile]

Display a maximum of 150 results when searching for messages.  This
prevents client lag when searches return thousands of results you'll
never look at (use the Filter command to cut down results that exceed
150).

Number of results can be changed by setting notmuch-max-results.

This patch depends on notmuch supporting the --last-index option, a
patch for which I emailed to the list earlier this evening.
---
 emacs/notmuch.el |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 2f36bbd..b928680 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1944,6 +1944,7 @@ characters as well as `_.+-'.
 (apply 'notmuch-enqueue-asynch "tag"
   (append action-split (list notmuch-search-query-string) nil

+(defvar notmuch-max-results 150)
 ;;;###autoload
 (defun notmuch-search (query  oldest-first target-thread target-line 
continuation)
   "Run \"notmuch search\" with the given query string and display results.
@@ -1975,6 +1976,7 @@ The optional parameters are used as follows:
(let ((proc (start-process
 "notmuch-search" buffer
 notmuch-command "search"
+(concat "--last-index=" (number-to-string 
notmuch-max-results))
 (if oldest-first
 "--sort=oldest-first"
   "--sort=newest-first")
-- 
1.7.5.4

[PATCH] Added --initial-index and --last-index to search/show

[James Vasile]

Sometimes you need to ask notmuch for just a few messages, and notmuch
supports that with date range options.  Date ranges, however, are not
sufficient for an application that is paging and just wants message x
through y, then x+d through y+d, etc.  And if you're sending the json
results of a search to a client for rendering, it makes sense to just
send the small ranges the client actually wants.

This patch implements --initial-index and --last-index as options to
search and show.  It lets you select the xth through the yth message
and receive results that pertain only to those messages.

I did not enable this option for results specifying --output=tags
since the output of a tag search isn't much data.
---
 notmuch-search.c |   48 ++--
 notmuch-show.c   |   30 ++
 notmuch.1|   32 
 notmuch.c|   18 +-
 4 files changed, 117 insertions(+), 11 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index faccaf7..f7deb4a 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -194,7 +194,9 @@ static int
 do_search_threads (const search_format_t *format,
   notmuch_query_t *query,
   notmuch_sort_t sort,
-  output_t output)
+  output_t output,
+  int initial_thread,
+  int last_thread)
 {
 notmuch_thread_t *thread;
 notmuch_threads_t *threads;
@@ -208,8 +210,15 @@ do_search_threads (const search_format_t *format,

 fputs (format->results_start, stdout);

+last_thread -= initial_thread;
+
+for (;
+initial_thread > 0 && notmuch_threads_valid (threads);
+notmuch_threads_move_to_next (threads))
+   initial_thread--;
+
 for (;
-notmuch_threads_valid (threads);
+last_thread != 0 && notmuch_threads_valid (threads);
 notmuch_threads_move_to_next (threads))
 {
int first_tag = 1;
@@ -258,6 +267,7 @@ do_search_threads (const search_format_t *format,
first_thread = 0;

notmuch_thread_destroy (thread);
+   last_thread--;
 }

 if (first_thread)
@@ -271,7 +281,9 @@ do_search_threads (const search_format_t *format,
 static int
 do_search_messages (const search_format_t *format,
notmuch_query_t *query,
-   output_t output)
+   output_t output,
+   int initial_message,
+   int last_message)
 {
 notmuch_message_t *message;
 notmuch_messages_t *messages;
@@ -284,8 +296,15 @@ do_search_messages (const search_format_t *format,

 fputs (format->results_start, stdout);

+last_message -= initial_message;
+
+for (;
+initial_message > 0 && notmuch_messages_valid (messages);   
+notmuch_messages_move_to_next (messages))
+   initial_message--;
+
 for (;
-notmuch_messages_valid (messages);
+last_message != 0 && notmuch_messages_valid (messages); 
 notmuch_messages_move_to_next (messages))
 {
message = notmuch_messages_get (messages);
@@ -318,6 +337,7 @@ do_search_messages (const search_format_t *format,
}

notmuch_message_destroy (message);
+   last_message--;
 }

 notmuch_messages_destroy (messages);
@@ -394,6 +414,8 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
 const search_format_t *format = _text;
 int i, ret;
 output_t output = OUTPUT_SUMMARY;
+int initial_index = 0;
+int last_index = -1;

 for (i = 0; i < argc && argv[i][0] == '-'; i++) {
if (strcmp (argv[i], "--") == 0) {
@@ -420,6 +442,16 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
fprintf (stderr, "Invalid value for --format: %s\n", opt);
return 1;
}
+   } else if (STRNCMP_LITERAL (argv[i], "--last-index=") == 0) {
+   opt = argv[i] + sizeof ("--last-index=") - 1;
+   last_index = atoi(opt);
+   if (last_index == 0) {
+   fprintf (stderr, "Last index set to 0.\n");
+   return 1;
+   }
+   } else if (STRNCMP_LITERAL (argv[i], "--initial-index=") == 0) {
+   opt = argv[i] + sizeof ("--initial-index=") - 1;
+   initial_index = atoi(opt);
} else if (STRNCMP_LITERAL (argv[i], "--output=") == 0) {
opt = argv[i] + sizeof ("--output=") - 1;
if (strcmp (opt, "summary") == 0) {
@@ -476,13 +508,17 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
 default:
 case OUTPUT_SUMMARY:
 case OUTPUT_THREADS:
-   ret = do_search_threads (format, query, sort, output);
+   ret = do_search_threads (format, query, sort, output, initial_index, 
last_index);
break;
 case OUTPUT_MESSAGES:
 case OUTPUT_FILES:
-   ret = do_search_messages (format, query, output);
+   ret = do_search_messages 

Re: [PATCH] Return maximum of 150 results

[James Vasile]

On Fri, 19 Aug 2011 17:00:23 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
 Hi James,
 
 On Fri, 19 Aug 2011, James Vasile wrote:
  Display a maximum of 150 results when searching for messages.  This
  prevents client lag when searches return thousands of results you'll
  never look at
 
 I would not like this feature. If I search for something I really want
 to see everything. For example, if I want to remove inbox from many
 messages, I would search for them and press -inboxret. With your
 patch I'd not be sure whether there are some more messages or not.

Ah, I do such things from the commandline, but you are right that there
is a good use for such.

 
  (use the Filter command to cut down results that exceed 150).
 
 You can start filtering while the previous search is still running, so I
 do not see problem with having bug number of results.

Yes, you can filter while the search runs, but that's not the only
problem with huge search results.  On my system, I routinely do searches
that return 15000+ messages when I'm only interested in the first
several.  When I hit Q, Emacs annoyingly asks me for permission to kill
the buffer because it has a running process.  And emacs lags as it
processes all that data.

  
  Number of results can be changed by setting notmuch-max-results.
 
 If you really want this behavior, I propose to make the default value
 of notmuch-max-results infinity.

Yes, that's probably the right answer.  I'll rework the patch to do that.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Return maximum of 150 results

[James Vasile]

On Fri, 19 Aug 2011 18:00:36 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
  On my system, I routinely do searches that return 15000+ messages
  when I'm only interested in the first several.  When I hit Q, Emacs
  annoyingly asks me for permission to kill the buffer because it has
  a running process.  And emacs lags as it processes all that data.
 
 Ahh, I almost forget about this. I use this patch to disable this.

Nice.  That's a good solution.

 
 -Michal
 
 --8---cut here---start-8---
 From 0e0ae662026f4a17b882bb33140e0bb62e8da995 Mon Sep 17 00:00:00 2001
 From: Michal Sojka sojk...@fel.cvut.cz
 Date: Fri, 19 Aug 2011 17:58:40 +0200
 Subject: [PATCH] Do not query on notmuch-search exit
 
 Emacs 23.2 queries by default about killing existing processes. Disable
 this behavior for notmuch. I'm not sure whether this works with earlier
 versions.
 ---
  emacs/notmuch.el |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/emacs/notmuch.el b/emacs/notmuch.el
 index 3d82f0d..8858f3e 100644
 --- a/emacs/notmuch.el
 +++ b/emacs/notmuch.el
 @@ -858,7 +858,9 @@ The optional parameters are used as follows:
  --sort=newest-first)
query)))
 (set-process-sentinel proc 'notmuch-search-process-sentinel)
 -   (set-process-filter proc 'notmuch-search-process-filter
 +   (set-process-filter proc 'notmuch-search-process-filter)
 +   (set-process-query-on-exit-flag proc nil)))
 +  )
  (run-hooks 'notmuch-search-hook)))
  
  (defun notmuch-search-refresh-view ()
 -- 
 1.7.5.4
 
 --8---cut here---end---8---
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Added --initial-index and --last-index to search/show

[James Vasile]

Sometimes you need to ask notmuch for just a few messages, and notmuch
supports that with date range options.  Date ranges, however, are not
sufficient for an application that is paging and just wants message x
through y, then x+d through y+d, etc.  And if you're sending the json
results of a search to a client for rendering, it makes sense to just
send the small ranges the client actually wants.

This patch implements --initial-index and --last-index as options to
search and show.  It lets you select the xth through the yth message
and receive results that pertain only to those messages.

I did not enable this option for results specifying --output=tags
since the output of a tag search isn't much data.
---
 notmuch-search.c |   48 ++--
 notmuch-show.c   |   30 ++
 notmuch.1|   32 
 notmuch.c|   18 +-
 4 files changed, 117 insertions(+), 11 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index faccaf7..f7deb4a 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -194,7 +194,9 @@ static int
 do_search_threads (const search_format_t *format,
   notmuch_query_t *query,
   notmuch_sort_t sort,
-  output_t output)
+  output_t output,
+  int initial_thread,
+  int last_thread)
 {
 notmuch_thread_t *thread;
 notmuch_threads_t *threads;
@@ -208,8 +210,15 @@ do_search_threads (const search_format_t *format,
 
 fputs (format-results_start, stdout);
 
+last_thread -= initial_thread;
+
+for (;
+initial_thread  0  notmuch_threads_valid (threads);
+notmuch_threads_move_to_next (threads))
+   initial_thread--;
+
 for (;
-notmuch_threads_valid (threads);
+last_thread != 0  notmuch_threads_valid (threads);
 notmuch_threads_move_to_next (threads))
 {
int first_tag = 1;
@@ -258,6 +267,7 @@ do_search_threads (const search_format_t *format,
first_thread = 0;
 
notmuch_thread_destroy (thread);
+   last_thread--;
 }
 
 if (first_thread)
@@ -271,7 +281,9 @@ do_search_threads (const search_format_t *format,
 static int
 do_search_messages (const search_format_t *format,
notmuch_query_t *query,
-   output_t output)
+   output_t output,
+   int initial_message,
+   int last_message)
 {
 notmuch_message_t *message;
 notmuch_messages_t *messages;
@@ -284,8 +296,15 @@ do_search_messages (const search_format_t *format,
 
 fputs (format-results_start, stdout);
 
+last_message -= initial_message;
+
+for (;
+initial_message  0  notmuch_messages_valid (messages);   
+notmuch_messages_move_to_next (messages))
+   initial_message--;
+
 for (;
-notmuch_messages_valid (messages);
+last_message != 0  notmuch_messages_valid (messages); 
 notmuch_messages_move_to_next (messages))
 {
message = notmuch_messages_get (messages);
@@ -318,6 +337,7 @@ do_search_messages (const search_format_t *format,
}
 
notmuch_message_destroy (message);
+   last_message--;
 }
 
 notmuch_messages_destroy (messages);
@@ -394,6 +414,8 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
 const search_format_t *format = format_text;
 int i, ret;
 output_t output = OUTPUT_SUMMARY;
+int initial_index = 0;
+int last_index = -1;
 
 for (i = 0; i  argc  argv[i][0] == '-'; i++) {
if (strcmp (argv[i], --) == 0) {
@@ -420,6 +442,16 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
fprintf (stderr, Invalid value for --format: %s\n, opt);
return 1;
}
+   } else if (STRNCMP_LITERAL (argv[i], --last-index=) == 0) {
+   opt = argv[i] + sizeof (--last-index=) - 1;
+   last_index = atoi(opt);
+   if (last_index == 0) {
+   fprintf (stderr, Last index set to 0.\n);
+   return 1;
+   }
+   } else if (STRNCMP_LITERAL (argv[i], --initial-index=) == 0) {
+   opt = argv[i] + sizeof (--initial-index=) - 1;
+   initial_index = atoi(opt);
} else if (STRNCMP_LITERAL (argv[i], --output=) == 0) {
opt = argv[i] + sizeof (--output=) - 1;
if (strcmp (opt, summary) == 0) {
@@ -476,13 +508,17 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
 default:
 case OUTPUT_SUMMARY:
 case OUTPUT_THREADS:
-   ret = do_search_threads (format, query, sort, output);
+   ret = do_search_threads (format, query, sort, output, initial_index, 
last_index);
break;
 case OUTPUT_MESSAGES:
 case OUTPUT_FILES:
-   ret = do_search_messages (format, query, output);
+   ret = do_search_messages (format, query, output, 

Undo tag operation?

[James Vasile]

On Wed, 20 Jul 2011 09:48:53 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza  wrote:
> > I just inadvertently removed the "todo" tag from all my "todo"-tagged
> > emails (about 60 of them going back several months, so I doubt I can
> > find them all again in my email haystack).  So I have a few questions:
> 
> Hey, Alex.  This won't help you now, and doesn't really answer your
> questions either, but you should periodically back up your tags with the
> "dump" command.  If you had a dumpfile backup of the tags you could
> restore with "restore".  hth (for the future).

I generally run my notmuch commands through notmuch-retry.  See
http://notmuch.198994.n3.nabble.com/PATCH-Add-shell-script-notmuch-retry-td417192.html

That could be easily amended to log tag commands.  You could then
restore from your most recent dump and replay all the tag commands since
that dump, minus the offending command.

Not a perfect solution, but it would work.  Maybe I'll build it if I
encounter some free time.

Re: Undo tag operation?

[James Vasile]

On Wed, 20 Jul 2011 09:48:53 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
 On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza aghi...@gmail.com wrote:
  I just inadvertently removed the todo tag from all my todo-tagged
  emails (about 60 of them going back several months, so I doubt I can
  find them all again in my email haystack).  So I have a few questions:
 
 Hey, Alex.  This won't help you now, and doesn't really answer your
 questions either, but you should periodically back up your tags with the
 dump command.  If you had a dumpfile backup of the tags you could
 restore with restore.  hth (for the future).

I generally run my notmuch commands through notmuch-retry.  See
http://notmuch.198994.n3.nabble.com/PATCH-Add-shell-script-notmuch-retry-td417192.html

That could be easily amended to log tag commands.  You could then
restore from your most recent dump and replay all the tag commands since
that dump, minus the offending command.

Not a perfect solution, but it would work.  Maybe I'll build it if I
encounter some free time.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[James Vasile]

On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins  wrote:
> On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
> wrote:
> > I sent two patches to the list on March 16.  They were a bug fix to
> > allow notmuch to correctly handle some poorly formatted email.  Nobody
> > ever replied, but I'd like to see the bug fixed nonetheless, as it
> > results in unreadable mail.  Since I've actually seen such mail in the
> > wild, I'd like to see Notmuch handle it.
> 
> Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
> notmuch search, which I think is the issue that you're patches were also
> dealing with.  Florian's patch has be pushed to my
> release-candidate/0.6.  Can you see if your issue is fixed there?  If
> not maybe you could try submitting a new patch that would apply to the
> release-candidate/0.6 head.
> 
> Thanks.

I'll take a look at it this week.  Thanks much.

Re: release-candidate/0.6

[James Vasile]

On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Fri, 06 May 2011 19:56:30 -0400, James Vasile ja...@hackervisions.org 
 wrote:
  I sent two patches to the list on March 16.  They were a bug fix to
  allow notmuch to correctly handle some poorly formatted email.  Nobody
  ever replied, but I'd like to see the bug fixed nonetheless, as it
  results in unreadable mail.  Since I've actually seen such mail in the
  wild, I'd like to see Notmuch handle it.
 
 Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
 notmuch search, which I think is the issue that you're patches were also
 dealing with.  Florian's patch has be pushed to my
 release-candidate/0.6.  Can you see if your issue is fixed there?  If
 not maybe you could try submitting a new patch that would apply to the
 release-candidate/0.6 head.
 
 Thanks.

I'll take a look at it this week.  Thanks much.

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

release-candidate/0.6

[James Vasile]

Thanks for pulling this together.

I sent two patches to the list on March 16.  They were a bug fix to
allow notmuch to correctly handle some poorly formatted email.  Nobody
ever replied, but I'd like to see the bug fixed nonetheless, as it
results in unreadable mail.  Since I've actually seen such mail in the
wild, I'd like to see Notmuch handle it.

Those messages were:

Message-ID: <87ipvifrlv.fsf at softwarefreedom.org>
Message-ID: <87fwqmfr2x.fsf at softwarefreedom.org>

Thanks,
James

[PATCH] replace null terminator in string

[James Vasile]

In order to make the prior patch work for trailing whitespace, we also need 
this one.
---
 lib/thread.cc |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 7a816ea..54fde2b 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -291,6 +291,8 @@ rectify_whitespace (char *str)
   *curr = 32; //space
   while (curr++ < last);

+  *(last+1) = 0;
+
   return str;
 }

-- 
1.7.2.3

[PATCH] Remove/replace vertical whitespace in subject header field body.

[James Vasile]

RFC 822 specifies that headers are one-liners of ASCII:

> The field-body may be composed of any ASCII characters, except CR or
> LF.  (While CR and/or LF may be present in the actual text, they are
> removed by the action of unfolding the field.)

RFC 5335 allows UTF-8 in header field bodies, but as I read the docs,
the RFC 822 specification that they end up as one-liners still applies.

RFC 5322 describes folding and unfolding as follows:

> Each header field is logically a single line of characters comprising
> the field name, the colon, and the field body. For convenience
> however, and to deal with the 998/78 character limitations per line,
> the field body portion of a header field can be split into a
> multiple-line representation; this is called "folding". The general
> rule is that wherever this specification allows for folding white
> space (not simply WSP characters), a CRLF may be inserted before any
> WSP.
...
> The process of moving from this folded multiple-line representation of
> a header field to its single line representation is called
> "unfolding". Unfolding is accomplished by simply removing any CRLF
> that is immediately followed by WSP.

Again, unfolded subjects should be one-liners.

An email was sent to me from pingg.com (I think it's a pretentious
version of evite) came with a subject of
"=?utf-8?Q?bring_small_items_for_a_pi=C3=B1ata=21=21=21=21=0A?=", which
"notmuch search" displays as "Subject: bring small items for a
pi?ata" with a \n at the end.  This befuddles the emacs UI ("Error:
Unexpected output from notmuch search:").  I've attached an email that
reproduces the error.

I don't think ending the subject with a utf-8-encoded 0x0A followed by
the usual CRLF is RFC-compliant.  Still, notmuch should surely follow
the deplorable "accept liberally/emit conservatively" doctrine.

Here is a patch that trims leading and trailing whitespace from subjects
and replaces internal non-space, non-horizontal-tab whitespace with
spaces.  It fixes the problem described in this message.
---
 lib/thread.cc |   36 
 1 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 5190a66..7a816ea 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -266,6 +266,34 @@ _thread_add_message (notmuch_thread_t *thread,
 }
 }

+/* Remove leading/trailing whitespace and replace internal vertical
+ * whitespace with spaces.
+ */
+static char *
+rectify_whitespace (char *str)
+{
+  char *last;
+  char *curr;
+
+  while (isspace (*str))
+str++;
+
+  if (*str == 0)
+return str;
+
+  last = str + strlen(str) - 1;
+  while (last > str && isspace (*last))
+last--;
+
+  curr = str;
+  do
+if ((*curr >= 10) && (*curr <= 13))
+  *curr = 32; //space
+  while (curr++ < last);
+
+  return str;
+}
+
 static void
 _thread_set_subject_from_message (notmuch_thread_t *thread,
  notmuch_message_t *message)
@@ -282,11 +310,11 @@ _thread_set_subject_from_message (notmuch_thread_t 
*thread,
(strncasecmp (subject, "Vs: ", 4) == 0) ||
(strncasecmp (subject, "Sv: ", 4) == 0)) {

-   cleaned_subject = talloc_strndup (thread,
- subject + 4,
- strlen(subject) - 4);
+  cleaned_subject = rectify_whitespace(talloc_strndup (thread,
+  subject + 4,
+  strlen(subject) - 
4));
 } else {
-   cleaned_subject = talloc_strdup (thread, subject);
+  cleaned_subject = rectify_whitespace(talloc_strdup (thread, subject));
 }

 if (thread->subject)
-- 
1.7.2.3



-- next part --
A non-text attachment was scrubbed...
Name: malformed_subject
Type: application/octet-stream
Size: 351 bytes
Desc: not available
URL: 

[PATCH] replace null terminator in string

[James Vasile]

In order to make the prior patch work for trailing whitespace, we also need 
this one.
---
 lib/thread.cc |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 7a816ea..54fde2b 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -291,6 +291,8 @@ rectify_whitespace (char *str)
   *curr = 32; //space
   while (curr++  last);
 
+  *(last+1) = 0;
+
   return str;
 }
 
-- 
1.7.2.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

python documentation

[James Vasile]

On Tue, 15 Mar 2011 11:33:19 -0700, Jameson Rollins  wrote:
> On Tue, 15 Mar 2011 14:22:55 -0400, James Vasile  
> wrote:
> > notmuch dump includes '# TODO: implement "dump "' but it
> > appears to work already.  What's missing?
> 
> Hey, James.  Is this related to the python documentation somehow?  If
> so, I'm not sure how.
> 
> If you're just referencing a completed TODO, you could definitely submit
> a patch to remove it from the TODO.
> 

Yep, just a completed TODO.  Patch below.

diff --git a/bindings/python/notmuch.py b/bindings/python/notmuch.py
index 8572612..8d11859 100755
--- a/bindings/python/notmuch.py
+++ b/bindings/python/notmuch.py
@@ -486,7 +486,6 @@ def main():
 print "\n".join([t for t in msgs.collect_tags()])
 #-
 elif sys.argv[1] == 'dump':
-# TODO: implement "dump "
 if len(sys.argv) == 2:
 f = sys.stdout
 else:

python documentation

[James Vasile]

notmuch dump includes '# TODO: implement "dump "' but it
appears to work already.  What's missing?

Thanks,
James

Re: python documentation

[James Vasile]

notmuch dump includes '# TODO: implement dump filename' but it
appears to work already.  What's missing?

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

Re: python documentation

[James Vasile]

On Tue, 15 Mar 2011 11:33:19 -0700, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Tue, 15 Mar 2011 14:22:55 -0400, James Vasile ja...@hackervisions.org 
 wrote:
  notmuch dump includes '# TODO: implement dump filename' but it
  appears to work already.  What's missing?
 
 Hey, James.  Is this related to the python documentation somehow?  If
 so, I'm not sure how.
 
 If you're just referencing a completed TODO, you could definitely submit
 a patch to remove it from the TODO.
 

Yep, just a completed TODO.  Patch below.

diff --git a/bindings/python/notmuch.py b/bindings/python/notmuch.py
index 8572612..8d11859 100755
--- a/bindings/python/notmuch.py
+++ b/bindings/python/notmuch.py
@@ -486,7 +486,6 @@ def main():
 print \n.join([t for t in msgs.collect_tags()])
 #-
 elif sys.argv[1] == 'dump':
-# TODO: implement dump filename
 if len(sys.argv) == 2:
 f = sys.stdout
 else:
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Make MBox

[James Vasile]

On Tue, 01 Mar 2011 14:06:28 -0800, Jameson Rollins  wrote:
> On Tue, 01 Mar 2011 15:54:32 -0500, James Vasile  
> wrote:
> > Sometimes I want to send a colleague a bunch of emails (for example, all
> > the emails I've tagged todo or all the emails from an awesome
> > contributor.  Although notmuch usually speaks the language of maildirs,
> > I find mboxes most convenient for attaching to emails.  Their tools can
> > usually handle it well.
> > 
> > I've put a bit of elisp and python up:
> > https://github.com/jvasile/notmuch2mbox
> 
> Hi, James.  Are you aware of the --format=mbox output option for notmuch
> show?  I think it already supports just this exact use case.  See
> "notmuch help show" for more info.

Nope, completely unaware.  This is what happens when I stop reading this
list for a while.  I go do silly things like reimplement features.  I
wonder how easy it is to remove a repo from github...

Thanks for the kind update, Jameson.

Best regards,
James

Make MBox

[James Vasile]

Sometimes I want to send a colleague a bunch of emails (for example, all
the emails I've tagged todo or all the emails from an awesome
contributor.  Although notmuch usually speaks the language of maildirs,
I find mboxes most convenient for attaching to emails.  Their tools can
usually handle it well.

I've put a bit of elisp and python up:
https://github.com/jvasile/notmuch2mbox

The python's help screen:

> Usage: 
> notmuch2mbox.py [options] [search terms]
>
> This program uses notmuch to search for the search terms, then outputs
> any found emails in mbox format.
> 
> 
> Options:
>   -h, --helpshow this help message and exit
>   -n NOTMUCH, --notmuch=NOTMUCH
> Path to notmuch binary.
>   -o OUTFILE, --outfile=OUTFILE
> Write mbox to specified path instead of stdout

The python script does a search and spits out an mbox containing
anything it finds in that search.  The emacs function performs that task
on the current search, saving the result to a file, which you can attach
to an email, open in mutt or whatever.  The elisp is in the starting
comments to the python.

I hope this is useful to somebody.  It does the trick for me in working
with mbox-dependent colleagues (e.g. mutt users).  I prefer mutt's
threaded view to notmuch's conversation view, so I've used it to browse
emails too.

Regards,
James

Re: Make MBox

[James Vasile]

On Tue, 01 Mar 2011 14:06:28 -0800, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Tue, 01 Mar 2011 15:54:32 -0500, James Vasile ja...@hackervisions.org 
 wrote:
  Sometimes I want to send a colleague a bunch of emails (for example, all
  the emails I've tagged todo or all the emails from an awesome
  contributor.  Although notmuch usually speaks the language of maildirs,
  I find mboxes most convenient for attaching to emails.  Their tools can
  usually handle it well.
  
  I've put a bit of elisp and python up:
  https://github.com/jvasile/notmuch2mbox
 
 Hi, James.  Are you aware of the --format=mbox output option for notmuch
 show?  I think it already supports just this exact use case.  See
 notmuch help show for more info.

Nope, completely unaware.  This is what happens when I stop reading this
list for a while.  I go do silly things like reimplement features.  I
wonder how easy it is to remove a repo from github...

Thanks for the kind update, Jameson.

Best regards,
James
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

DB Corruption

[James Vasile]

This email is a gentle reminder to back up your tags unless they are
100% mechanically generated.

Last night, while testing some scripts that do a bunch of notmuch new,
notmuch tag and notmuch search commands, I suddenly started getting
an error:

A Xapian exception occurred opening database: Db block overwritten -
are there multiple writers?

I hopped over to #notmuch and asked for help. ojwb asked for a directory
listing of my xapian directory and informed me my basA and baseB files
were missing.  I ended up restoring from a recent dump of the db.

I'm not sure how this happend (I only interact with that directory via
notmuch), but I suppose if it happened to me it could happen to you.  So
backup those tags.

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

DB Corruption

[James Vasile]

This email is a gentle reminder to back up your tags unless they are
100% mechanically generated.

Last night, while testing some scripts that do a bunch of "notmuch new",
"notmuch tag" and "notmuch search" commands, I suddenly started getting
an error:

"A Xapian exception occurred opening database: Db block overwritten -
are there multiple writers?"

I hopped over to #notmuch and asked for help. ojwb asked for a directory
listing of my xapian directory and informed me my basA and baseB files
were missing.  I ended up restoring from a recent dump of the db.

I'm not sure how this happend (I only interact with that directory via
notmuch), but I suppose if it happened to me it could happen to you.  So
backup those tags.

-J

Spam and mailing list filtering?

[James Vasile]

On Thu, 10 Feb 2011 12:20:55 +, Daniel Barlow  wrote:
> 1) (How) can I filter on the X-Spam-Bar header to chop out spam and
> suspected spam?

I just integrated Spambayes into my notmuch toolchain.

It's crude, but here's how it works:

My script does `find -mtime 0 | xargs grep -L
^X-Spambayes-Classification` to get all the recent files that aren't
already classified by spambayes.  It passes them to spambayes,
overwrites the mail file with the resulting mail (with spambayes header)
and then does `notmuch tag +spambayes id:$ID` for anythat come back
with "X-Spambayes-Classification: spam".

I suppose that in doing this I might leave myself open to spammers that
pre-seed emails with "X-Spambayes-Classification: ham" tags, but I
searched my mail archives and no messages came with those headers
already in place.

You could do something similar by searching for messages that aren't
tagged either spam or ham, looking in each for the header and adding the
appropriate tag.  It's clunky and maybe even brittle, but it works well
enough until notmuch gains the ability to search for arbitrary headers.

-James

social gathering during DebConf

[James Vasile]

On Fri, 23 Jul 2010 16:56:51 -0400, Jameson Rollins  wrote:
> Hey, folks.  For those of you that don't already know, David Bremner
> will be hosting a birds-of-a-feather session on notmuch during DebConf
> 10 in NYC [0] on Thursday, August 5 [1].  Even if you're not
> specifically involved with Debian but are in the NYC area, feel free to
> join.  Hopefully we can get together for drinks sometime during the
> week.  If you're around but have schedule restrictions during that week,
> let us know and maybe we can schedule a social gathering at a specific
> time.
> 
> jamie.
> 

I'll be at Debconf (along with most of the rest of the Software Freedom
Law Center).  I'll try to make that gathering.

-J

Re: social gathering during DebConf

[James Vasile]

On Fri, 23 Jul 2010 16:56:51 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
 Hey, folks.  For those of you that don't already know, David Bremner
 will be hosting a birds-of-a-feather session on notmuch during DebConf
 10 in NYC [0] on Thursday, August 5 [1].  Even if you're not
 specifically involved with Debian but are in the NYC area, feel free to
 join.  Hopefully we can get together for drinks sometime during the
 week.  If you're around but have schedule restrictions during that week,
 let us know and maybe we can schedule a social gathering at a specific
 time.
 
 jamie.
 

I'll be at Debconf (along with most of the rest of the Software Freedom
Law Center).  I'll try to make that gathering.

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

[notmuch] bbdb import notmuch addresses

[James Vasile]

I used notmuch_address.py to scrape email addresses from notmuch and
generate elisp to showve them into bbdb.  Tab completion via bbdb is
much faster than via notmuch_addresses.

Run the script, execute the results in emacs.  I didn't care enough to
do any merging, so records that clash with existing records are ignored.

-- next part --
A non-text attachment was scrubbed...
Name: scrape.py
Type: text/x-python
Size: 1195 bytes
Desc: scrape.py
URL: 

[notmuch] [PATCH] Name thread based on matching msgs instead of first msg.

[James Vasile]

On Mon, 22 Mar 2010 23:09:15 -0400, Jesse Rosenthal  
wrote:
> Reply prefixes ("Re: ", "Aw: ", "Sv: ", "Vs: ") are ignored

Just out of curiosity, what are Aw, Sv and Vs used for?  Are they just
"re" in different languages?

Thanks.

Re: [notmuch] [PATCH] Name thread based on matching msgs instead of first msg.

[James Vasile]

On Mon, 22 Mar 2010 23:09:15 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 Reply prefixes (Re: , Aw: , Sv: , Vs: ) are ignored

Just out of curiosity, what are Aw, Sv and Vs used for?  Are they just
re in different languages?

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

[notmuch] [PATCH] Change From and Bcc when creating reply draft buffer

[James Vasile]

On Fri, 12 Mar 2010 08:49:35 +0100, Michal Sojka  wrote:
> On Thu, 11 Mar 2010, James Vasile wrote:
> > On Thu, 11 Mar 2010 17:22:41 +0100, Michal Sojka  
> > wrote:
> > > thanks for clarification. It all sounds reasonable. The only problem I
> > > can see now is that if I create a new account on my machine and run
> > > emacs there, then the value of user-mail-address is @
> > > which doesn't refer to existing mailbox. I think that the header should
> > > only be rewritten if these variables are known to have valid values. Do
> > > you know how to do this?
> > > 
> > 
> > I explicitly set these in my .emacs file, so I don't do any detection.
> > If you could define "valid" I suppose you could test for such things.
> > 
> > Something like the following works for me.  I run mail-profile-foo with
> > M-x or run it automatically with profile-guessing/setting routines.
> > When I get the system ironed out, I'll emit patches and a wiki entry.
> > 
> > (defun message-mode-set-profile ()
> >   (save-excursion
> > (when (string= "message-mode" major-mode)
> >   (goto-char (point-min))
> >   (when (re-search-forward "^From: " nil t)
> > (kill-line)
> > (insert (format "%s <%s>" user-full-name user-mail-address)))
> > 
> >   (goto-char (point-min))
> >   (when (re-search-forward "^Bcc: " nil t)
> > (kill-line)
> > (insert (format "%s <%s>" user-full-name user-mail-address))
> > 
> > (defun mail-profile-hv ()
> >   (interactive)
> >   (setq mail-host-address "hackervisions.org"
> >   user-full-name "James Vasile"
> >   message-sendmail-extra-arguments '("-a" "hv")
> >   user-mail-address "james at hackervisions.org")
> >   (message-mode-set-profile)
> >   user-mail-address)
> > (mail-profile-hv)
> > 
> > 
> 
> Hmm, I understand. My worry about this approach is the following: Now it
> is very straightforward to start using notmuch. You only answer a few
> questions when you run notmuch for the first time and then it works. If
> we apply your patch, some additional configuration is needed and a
> novice might not know how to do it.

I disagree as to how much time notmuch currently takes.  To get a
workable setup, you need to answer a few questions, setup offlineimap,
write a tagging script, setup up folders, apply a bunch of patches,
etc.  

I've been telling people to wait 6 months instead of trying notmuch.
That's based on how much work it is to setup, incomplete MUA, bugs, etc.

> So at least notmuch should tell the user what and where needs to be
> configured. Or better, provide some sane default which can be overridden
> in a way you want it.
> 
> That's only my opinion. I personally would have no problem with
> additional configuration, but on the other side I like programs which do
> not steel my time if it is not necessary.

That's a fair point.  I hope notmuch gets easier over time, and one of
the things I'd like to implement is sane defaults.  As notmuch gets more
user friendly, I'd like to make the pieces I write less onerous to
configure.

For example, I have some stub code for a default profile that pulls
values from ~/.notmuch.  Then if the user doesn't do the setup, things
should be not much different than they are now.

-J

[notmuch] [PATCH] Change From and Bcc when creating reply draft buffer

[James Vasile]

On Thu, 11 Mar 2010 17:22:41 +0100, Michal Sojka  wrote:
> thanks for clarification. It all sounds reasonable. The only problem I
> can see now is that if I create a new account on my machine and run
> emacs there, then the value of user-mail-address is @
> which doesn't refer to existing mailbox. I think that the header should
> only be rewritten if these variables are known to have valid values. Do
> you know how to do this?
> 

I explicitly set these in my .emacs file, so I don't do any detection.
If you could define "valid" I suppose you could test for such things.

Something like the following works for me.  I run mail-profile-foo with
M-x or run it automatically with profile-guessing/setting routines.
When I get the system ironed out, I'll emit patches and a wiki entry.

(defun message-mode-set-profile ()
  (save-excursion
(when (string= "message-mode" major-mode)
  (goto-char (point-min))
  (when (re-search-forward "^From: " nil t)
(kill-line)
(insert (format "%s <%s>" user-full-name user-mail-address)))

  (goto-char (point-min))
  (when (re-search-forward "^Bcc: " nil t)
(kill-line)
(insert (format "%s <%s>" user-full-name user-mail-address))

(defun mail-profile-hv ()
  (interactive)
  (setq mail-host-address "hackervisions.org"
  user-full-name "James Vasile"
  message-sendmail-extra-arguments '("-a" "hv")
  user-mail-address "james at hackervisions.org")
  (message-mode-set-profile)
  user-mail-address)
(mail-profile-hv)

[notmuch] [PATCH] Change From and Bcc when creating reply draft buffer

[James Vasile]

On Thu, 11 Mar 2010 14:00:08 +0100, Michal Sojka  wrote:
> Hi James,
> 
> On Tue, 09 Mar 2010, James Vasile wrote:
> > When notmuch creates a reply buffer, it guesses the From and Bcc
> > addresses.  The client is in a better position to guess these, and this
> > patch adjusts notmuch-reply accordingly.
> > 
> > diff --git a/notmuch.el b/notmuch.el
> > index ab56f48..07f957e 100644
> > --- a/notmuch.el
> > +++ b/notmuch.el
> > @@ -436,10 +436,20 @@ buffer."
> >(message "Done"))
> >  
> >  (defun notmuch-reply (query-string)
> > +  "Prepare a reply draft buffer.
> > +
> > +Have notmuch create a reply buffer, then adjust the from and bcc
> > +headers to match our current user-full-name and
> > +user-mail-address."
> >(switch-to-buffer (generate-new-buffer "notmuch-draft"))
> >(call-process notmuch-command nil t nil "reply" query-string)
> >(message-insert-signature)
> >(goto-char (point-min))
> > +  (kill-line)
> > +  (insert (format "From: %s <%s>" user-full-name user-mail-address))
> 
> Notmuch reply contains From: address which is based on the addresses in
> .notmuch-config and the replied message. When you use multiple addresses
> (e.g. home and work address), notmuch puts there the one used in the
> replied message. It seems that your patch would break this feature.
> 
> -Michal

Yes, it does break that feature, and intentionally so.  The MUA should
select the From: address.  I have profile selection code that sets my
user-full-name and user-mail-address based on some context.  When I
reply to somebody, the correct From: address is not who they think I am
but rather who *I* think I am.

Here's my use case: I have a job in the free software world.  There's an
email address attached to that.  I also serve on the board of a free
software project.  There's another email for that.  People email me
about the project using my work email, but I always reply using the
project email, and my MUA knows that.  Notmuch doesn't.

Also: my girlfriend's family sometimes emails me at work.  I don't want
personal email at my work address, so I always reply using a personal
address.

Also: I have an old email address that I've deprecated, but old friends
still use it.  I always reply with my newer address and they eventually
start using the new one.

My profile code is usable but not complete.  It looks at folder contents
to pick the correct From: address automatically (you can override the
choice, of course), which is good when you have 400+ folders.  If
anybody wants it before it's done, I can put it in a public branch.

-J

Re: [notmuch] [PATCH] Change From and Bcc when creating reply draft buffer

[James Vasile]

On Thu, 11 Mar 2010 17:22:41 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 thanks for clarification. It all sounds reasonable. The only problem I
 can see now is that if I create a new account on my machine and run
 emacs there, then the value of user-mail-address is login@hostname
 which doesn't refer to existing mailbox. I think that the header should
 only be rewritten if these variables are known to have valid values. Do
 you know how to do this?
 

I explicitly set these in my .emacs file, so I don't do any detection.
If you could define valid I suppose you could test for such things.

Something like the following works for me.  I run mail-profile-foo with
M-x or run it automatically with profile-guessing/setting routines.
When I get the system ironed out, I'll emit patches and a wiki entry.

(defun message-mode-set-profile ()
  (save-excursion
(when (string= message-mode major-mode)
  (goto-char (point-min))
  (when (re-search-forward ^From:  nil t)
(kill-line)
(insert (format %s %s user-full-name user-mail-address)))

  (goto-char (point-min))
  (when (re-search-forward ^Bcc:  nil t)
(kill-line)
(insert (format %s %s user-full-name user-mail-address))

(defun mail-profile-hv ()
  (interactive)
  (setq mail-host-address hackervisions.org
  user-full-name James Vasile
  message-sendmail-extra-arguments '(-a hv)
  user-mail-address ja...@hackervisions.org)
  (message-mode-set-profile)
  user-mail-address)
(mail-profile-hv)

other mail-profile-foo functions
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Any idea why my emacs doesn't want to accept my notmuch-folder keymap changes?

[James Vasile]

You have a typo: mot-much-folder-mode-map should be
notmuch-folder-mode-map.  (s/motmuch/notmuch/)

On Wed, 10 Mar 2010 13:19:09 -0700, Mark R Anderson  
wrote:
> I have added several keys to the search and show keymaps in my .emacs
> file, but when my hook for notmuch-folder-mode generates warnings.
> 
> I'm not sure exactly when the error happens, it may just be the compile
> phase of reading the .emacs file, my ELisp is pretty shaky.
> 
> (add-hook 'notmuch-folder-mode
>   (define-key motmuch-folder-mode-map "k" 'notmuch-folder-previous)
>   (define-key notmuch-folder-mode-map "j" 'notmuch-folder-next)
>   (define-key notmuch-folder-mode-map "F" 'notmuch-folder)
> )
> 
> 
> emacs *Warnings*:
> --
> Warning (initialization): An error occurred while loading 
> `/home/manderso/.emacs':
> 
> Symbol's value as variable is void: motmuch-folder-mode-map
> 
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file.  Start Emacs with
> the `--debug-init' option to view a complete error backtrace.
> --
> 
> I'm not sure why this one is so different from the other modes, any
> suggestions?
> 
> Thanks,
> -Mark
> 
> 
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Any idea why my emacs doesn't want to accept my notmuch-folder keymap changes?

[James Vasile]

You have a typo: mot-much-folder-mode-map should be
notmuch-folder-mode-map.  (s/motmuch/notmuch/)

On Wed, 10 Mar 2010 13:19:09 -0700, Mark R Anderson markr.ander...@amd.com 
wrote:
 I have added several keys to the search and show keymaps in my .emacs
 file, but when my hook for notmuch-folder-mode generates warnings.
 
 I'm not sure exactly when the error happens, it may just be the compile
 phase of reading the .emacs file, my ELisp is pretty shaky.
 
 (add-hook 'notmuch-folder-mode
   (define-key motmuch-folder-mode-map k 'notmuch-folder-previous)
   (define-key notmuch-folder-mode-map j 'notmuch-folder-next)
   (define-key notmuch-folder-mode-map F 'notmuch-folder)
 )
 
 
 emacs *Warnings*:
 --
 Warning (initialization): An error occurred while loading 
 `/home/manderso/.emacs':
 
 Symbol's value as variable is void: motmuch-folder-mode-map
 
 To ensure normal operation, you should investigate and remove the
 cause of the error in your initialization file.  Start Emacs with
 the `--debug-init' option to view a complete error backtrace.
 --
 
 I'm not sure why this one is so different from the other modes, any
 suggestions?
 
 Thanks,
 -Mark
 
 
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Change From and Bcc when creating reply draft buffer

[James Vasile]

When notmuch creates a reply buffer, it guesses the From and Bcc
addresses.  The client is in a better position to guess these, and this
patch adjusts notmuch-reply accordingly.

diff --git a/notmuch.el b/notmuch.el
index ab56f48..07f957e 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -436,10 +436,20 @@ buffer."
   (message "Done"))

 (defun notmuch-reply (query-string)
+  "Prepare a reply draft buffer.
+
+Have notmuch create a reply buffer, then adjust the from and bcc
+headers to match our current user-full-name and
+user-mail-address."
   (switch-to-buffer (generate-new-buffer "notmuch-draft"))
   (call-process notmuch-command nil t nil "reply" query-string)
   (message-insert-signature)
   (goto-char (point-min))
+  (kill-line)
+  (insert (format "From: %s <%s>" user-full-name user-mail-address))
+  (re-search-forward "^Bcc: " nil t)
+  (kill-line)
+  (insert (format "%s <%s>" user-full-name user-mail-address))
   (if (re-search-forward "^$" nil t)
   (progn
(insert "--text follows this line--")

[notmuch] [PATCH] compatibility with emacs22

[James Vasile]

Emacs22 lacks apply-partially and mouse-event-p, so define them if emacs
version is less than 23.  With this change, I was able to begin using
notmuch in emacs22.

apply-partially cribbed from 
http://notmuchmail.org/pipermail/notmuch/2009/000889.html

This is an updated patch that fixes a bug in the last version.
---
 notmuch.el |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 5577dde..20e82f1 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -67,6 +67,21 @@

 (fset 'notmuch-show-stash-map notmuch-show-stash-map)

+;; Old emacs lacks apply-partially
+(when (< emacs-major-version 23)
+  (defun apply-partially (fun  args)
+  "Return a function that is a partial application of FUN to ARGS.
+ARGS is a list of the first N arguments to pass to FUN.
+The result is a new function which does the same as FUN, except that
+the first N arguments are fixed at the values with which this function
+was called."
+  (lexical-let ((fun fun) (args1 args))
+(lambda ( args2) (apply fun (append args1 args2)
+
+  (defun mouse-event-p (object)
+  "Return non-nil if OBJECT is a mouse click event."
+  (memq (event-basic-type object) '(mouse-1 mouse-2 mouse-3 mouse-movement
+
 (defvar notmuch-show-mode-map
   (let ((map (make-sparse-keymap)))
 (define-key map "?" 'notmuch-help)
-- 
1.6.3.3

[notmuch] Initial tagging

[James Vasile]

On Fri, 26 Feb 2010 23:03:34 -0500, James Vasile  
wrote:
> On Fri, 26 Feb 2010 20:33:08 -0500, micah anderson  
> wrote:
> > 
> > Hey james,
> > 
> > i really like your notmuch-retry bits, I've taken that shell script and
> > integrated it into my tagging script, thanks! I'm curious if you are
> > going to update your patch for notmuch.el ("Calls to notmuch get queued
> > and executed asynchronously") to use this, or if you are going to have
> > those two continue to be separate ways of retrying?
> 
> Ah, I updated my local version and am putting it through its paces, but
> it's already so much better that I should just send in the revised
> patch.  I'll clean it up and do that tomorrow.

Insomnia: when it comes to sleep, my loss is your gain. 

I opened a github account and the updated bits are in the retry branch
at git at github.com:jvasile/notmuch.git

Carl, if you want the retry functionality, feel free to pull from there
or request I post those patches to this list.

Note that the retry branch depends on notmuch-retry being in your path,
but 'make install' does not know about notmuch-retry.

Next step for this branch is to have all errors go to *Notmuch errors*
rather than error buffers named for the tag commands.

[notmuch] [PATCH] Add shell script notmuch-retry

[James Vasile]

On Fri, 26 Feb 2010 11:55:19 -0800, Carl Worth  wrote:
> On Fri, 26 Feb 2010 07:53:29 -0500, James Vasile  
> wrote:
> > Maybe this retry loop should be put in notmuch itself?
> 
> Perhaps it should. I've even imagined something that would queue a
> request into a daemon if the database isn't currently available.
> 
> But of course there are issues about whether the caller would want to
> know about the locking error, (or might actually need to block until the
> operation is complete). So I'm not sure about the right answer here.

--block and/or --queue?

[notmuch] Initial tagging

[James Vasile]

On Fri, 26 Feb 2010 20:33:08 -0500, micah anderson  wrote:
> 
> Hey james,
> 
> i really like your notmuch-retry bits, I've taken that shell script and
> integrated it into my tagging script, thanks! I'm curious if you are
> going to update your patch for notmuch.el ("Calls to notmuch get queued
> and executed asynchronously") to use this, or if you are going to have
> those two continue to be separate ways of retrying?

Ah, I updated my local version and am putting it through its paces, but
it's already so much better that I should just send in the revised
patch.  I'll clean it up and do that tomorrow.

> Why do you tag new mail with tags, rather than construct folder searches
> to create views? 

I do a lot of on-the-fly searching and don't want to have to remember
notmuch's email address.  I suppose I could go to my notmuch folder and
then filter from there, but right now I'm much more likely to do M-x
notmuch-search/tag:notmuch and micah.

[notmuch] Initial tagging

[James Vasile]

On Fri, 26 Feb 2010 12:14:45 -0500, micah anderson  wrote:
> On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile  
> wrote:
> This stuff should go up on the wiki! There is a "Tips and Tricks for
> using notmuch with Emacs" section, but more general things like James'
> script and other people's scripts really should be put up there so
> people who are new can figure out how to get started faster.

Good point.  I will put some stuff on the wiki.

> 0. indirectly I believe am also responsible, through 3rd party
> evangelizing, for James entering the scene as well, and I'm happy about
> that because I have been quite pleased with his enhancements, thanks
> james!. now I just need to buy him a drink and talk him into fixing the
> openpgp bits ;)

Yes, you are my upstream evangelist.  You put the bug in Karl Fogel's
ear (although he hasn't actually tried it) and he put it in mine.  Glad
you're liking my elisp.

I've spent a bunch of time thinking about mail setups (I actually
sketched out what I'd need to do to mutt to get virtual folders there),
so it's great to see people making serious strides toward getting it
right.

Notmuch isn't a mail client so much as a mail kit.  I'm happy to be
hacking on it and making my mail work the way I want.

-J

[notmuch] [PATCH] Add shell script notmuch-retry

[James Vasile]

It occurs to me that having generic ability to tell notmuch to retry
until the DB isn't locked might useful.  So I put the functionality in a
script that can sit between notmuch and various clients.  It will
simplify my emacs setup, and improve it since emacs's handling of
asynchronous processes isn't great.

This script calls notmuch and passes on all commandline arguments.  If
DB is locked, keep trying notmuch until the DB isn't locked.  Notmuch's
stdout and stderr go to stdout and stderr.  Returns notmuch's return
code.

Maybe this retry loop should be put in notmuch itself?

---
 notmuch-retry |   51 +++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100755 notmuch-retry

diff --git a/notmuch-retry b/notmuch-retry
new file mode 100755
index 000..2d7fcbc
--- /dev/null
+++ b/notmuch-retry
@@ -0,0 +1,51 @@
+#!/bin/bash
+#
+# notmuch-retry --- call notmuch and retry if DB is locked
+#
+# Calls notmuch and passes on all commandline arguments.  If DB is
+# locked, keep trying notmuch until the DB isn't locked.  Notmuch's
+# stdout and stderr go to stdout and stderr.  Returns notmuch's return
+# code.
+#
+# Copyright 2010 James Vasile
+#
+# This is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This software is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this software.  If not, see
+# <http://www.gnu.org/licenses/>.
+#
+# Authors: James Vasile 
+
+bin=`which notmuch`
+
+notmuch_retry () {
+regex="already locked"
+while [ 1 -gt 0 ]; do
+   $bin $@ 2>$err
+   retcode=$?
+   result=$(<$err)
+   if [[ $result =~ $regex ]]; then
+   sleep 2.5
+   else
+   if [ -n "$result" ]; then
+   echo $result >&2
+   fi
+   return $retcode
+   fi
+done
+}
+
+err=$(mktemp)
+notmuch_retry $@
+retcode=$?
+rm $err
+exit $retcode
-- 
1.6.3.3

[notmuch] [PATCH] Add shell script notmuch-retry

[James Vasile]

It occurs to me that having generic ability to tell notmuch to retry
until the DB isn't locked might useful.  So I put the functionality in a
script that can sit between notmuch and various clients.  It will
simplify my emacs setup, and improve it since emacs's handling of
asynchronous processes isn't great.

This script calls notmuch and passes on all commandline arguments.  If
DB is locked, keep trying notmuch until the DB isn't locked.  Notmuch's
stdout and stderr go to stdout and stderr.  Returns notmuch's return
code.

Maybe this retry loop should be put in notmuch itself?

---
 notmuch-retry |   51 +++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100755 notmuch-retry

diff --git a/notmuch-retry b/notmuch-retry
new file mode 100755
index 000..2d7fcbc
--- /dev/null
+++ b/notmuch-retry
@@ -0,0 +1,51 @@
+#!/bin/bash
+#
+# notmuch-retry --- call notmuch and retry if DB is locked
+#
+# Calls notmuch and passes on all commandline arguments.  If DB is
+# locked, keep trying notmuch until the DB isn't locked.  Notmuch's
+# stdout and stderr go to stdout and stderr.  Returns notmuch's return
+# code.
+#
+# Copyright 2010 James Vasile
+#
+# This is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This software is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this software.  If not, see
+# http://www.gnu.org/licenses/.
+#
+# Authors: James Vasile ja...@hackervisions.org
+
+bin=`which notmuch`
+
+notmuch_retry () {
+regex=already locked
+while [ 1 -gt 0 ]; do
+   $bin $@ 2$err
+   retcode=$?
+   result=$($err)
+   if [[ $result =~ $regex ]]; then
+   sleep 2.5
+   else
+   if [ -n $result ]; then
+   echo $result 2
+   fi
+   return $retcode
+   fi
+done
+}
+
+err=$(mktemp)
+notmuch_retry $@
+retcode=$?
+rm $err
+exit $retcode
-- 
1.6.3.3

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

Re: [notmuch] Initial tagging

[James Vasile]

On Fri, 26 Feb 2010 20:33:08 -0500, micah anderson mi...@riseup.net wrote:
 
 Hey james,
 
 i really like your notmuch-retry bits, I've taken that shell script and
 integrated it into my tagging script, thanks! I'm curious if you are
 going to update your patch for notmuch.el (Calls to notmuch get queued
 and executed asynchronously) to use this, or if you are going to have
 those two continue to be separate ways of retrying?

Ah, I updated my local version and am putting it through its paces, but
it's already so much better that I should just send in the revised
patch.  I'll clean it up and do that tomorrow.

 Why do you tag new mail with tags, rather than construct folder searches
 to create views? 

I do a lot of on-the-fly searching and don't want to have to remember
notmuch's email address.  I suppose I could go to my notmuch folder and
then filter from there, but right now I'm much more likely to do M-x
notmuch-search/tag:notmuch and micah.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Initial tagging

[James Vasile]

On Thu, 25 Feb 2010 17:02:08 -0800, Carl Worth  wrote:
> One distinction is that I have all of my "notmuch tag" commands operate
> globally rather than just on new messages. One of the things that really
> annoyed be about sup was that the support for automatic tagging worked
> as a hook on messages as they were processed. So I couldn't use any of
> the tags for searches prior to the time that I had added a particular
> tag rule. I definitely didn't want to replicate that bug.

Sometimes I manually override a rule-based tag.  If automatic tagging
operated on old messages, overrides could be superseded.  When I add
automatic tag rules, I first execute them manually and globally from the
command line.

> To do my "global" searches quickly, I do a similar subsetting, but it's
> much simpler. If I'm adding the "notmuch" tag I do "and not
> tag:notmuch". We've even had the proposal of making "notmuch tag" do
> that automatically.

That sounds like a good idea.  What happened with that proposal?

> Meanwhile, I'm planning on eventually moving entirely away from any tags
> that are driven entirely by searches like this. Instead, I'd like to
> just have good support for "saved searches" where we have some syntax to
> perform string expansion on configured search terms. 

Saved searches is a very good idea.  I look forward to it.

[notmuch] Initial tagging

[James Vasile]

I'm slowly groping my way to using the notmuch emacs client as my
routine MUA.  As I coerce it into tagging and displaying the way I want,
the next big question was automatically tagging things and getting them
in to notmuch.

I'm curious as to what people are doing in this regard.

My solution involves cron running a sync_email script.  Sync_email does
the correct dance to make sure it only ever runs one instance at a time.
It also logs to syslog.  The script runs offlineimap, a mail_filter
script that sorts mail in maildirs (for wanderlust, the MUA I'm hoping
to leave behind), and then finally a shell script to do notmuch new and
initial tagging.

The tagging script uses the inbox tag to identify new mail, tags it
according to criteria, then removes the inbox tag from anything it found
a match for.  Uncategorized mail keeps the inbox tag so I can inspect it
later and make rules for it (or tag it manually).

Also, prepending "tag:inbox and" to search criteria restricts the
tagging to a small subset of the db, which makes the tagging script run
fairly quickly.  My unexpurgated tagging script has almost 100 rules for
tagging, and I expect it to grow over time.

## notmuch-tag.sh 
#!/bin/bash

bin=/usr/local/bin/notmuch

function notmuch {
echo $1
while [ 1 -gt 0 ]; do
result=`$bin $1 2>&1` 
regex="already locked"

if [[ $result =~ $regex ]]; then
echo "Xapian DB busy.  Retrying in 2 seconds"
else
if [ -n "$result" ]; then
echo $result
fi
return
fi

sleep 2
done
}

function tag_new { notmuch "tag $1 tag:inbox and ($2)"; }
function blacklist { tag_new "-inbox -unread +delete" $1; }

notmuch new

blacklist "from:xxx at example.com or from yyy at example.com"

# voicemail
tag_new "-inbox +voicemail"  "from:ast at example.com"

# friends
tag_new "+friend +mathieu" "mathieu or ejm2106 or emily at example.com"
tag_new "+friend +balktick" "balktick"

# open community services
tag_new "+ocs" "open community services or opencommunityservices"

# okos
tag_new "+okos" "jim and glaser and not LinkedIn"
tag_new "+okos" "joshlevy.ny at example.com"
tag_new "+okos" "enright at example.com"

# book liberator
tag_new "+bklib" "wnf at example.com or bkrpr"

# joomla
tag_new "+osm" "from:waring or to:waring"
tag_new "+osm" "from:dave.huelsmann at example.com or to:dave.huelsmann at 
example.com"
tag_new "+osm" "james.vasile at example.com"
tag_new "+osm" "joomla"

#lists
tag_new "+list +notmuch" "to:notmuchmail.org or notmuch"
tag_new "+list +stumpwm" "to:stumpwm-devel at nongnu.org or stumpwm"
tag_new "+list +bklib" "to:bklib at googlegroups.com"

## Catchalls for sflc, hv, etc.
tag_new "+sflc" "not tag:list and not tag:friend and softwarefreedom.org and 
not tag:osm"
tag_new "+sflc" "to:firm at example.com"
tag_new "+hv" "hackervisions.org and not tag:list and not tag:friend"
tag_new "+gmail" "(to:jvasile at example.com or from:jvasile at example.com) 
and not tag:list and not tag:friend"

## Mark mine unread
tag_new "-unread" "from:james at example.com"
tag_new "-unread" "from:vasile at example.com"
tag_new "-unread" "from:james.vasile at example.com"

## Remove inbox tag
tag_new "-inbox" "tag:sflc or tag:hv or tag:list or tag:osm or tag:okos or 
tag:friend or tag:bklib"


# sync_email #
#!/bin/sh

## Sync email unless we're already in the process of syncing.

SCRIPTNAME=`basename $0`
PIDDIR=/home/vasile/var/run/${SCRIPTNAME}
PIDFILE=${PIDDIR}/${SCRIPTNAME}.pid

## Do the double-lock with a dir and a pid file
if ! mkdir ${PIDDIR} 2>/dev/null; then

   sleep 3 # give the other process time to write its pid

   if [ -f ${PIDFILE} ]; then
  #verify if the process is actually still running under this pid
  OLDPID=`cat ${PIDFILE}`
  RESULT=`ps -ef | grep ${OLDPID} | grep ${SCRIPTNAME}`  

  if [ -n "${RESULT}" ]; then
logger -s ${SCRIPTNAME} already running! Exiting
exit 255
  fi
   fi
fi

## Update pid file
PID=`ps -ef | grep ${SCRIPTNAME} | head -n1 | awk ' {print $2;} '`
echo ${PID} > ${PIDFILE}

logger -s filter done, starting offlineimap
offlineimap -l /home/vasile/.offlineimap/log
logger -s offlineimap done, starting mail filter
mairix --unlock
/home/vasile/bin/mail_filter.py
logger -s mail filter done, starting notmuch tagger
/home/vasile/bin/notmuch-tag.sh > /home/vasile/var/log/notmuch
logger -s notmuch tagger done sync_email finished

## clean up pid file and dir
if [ -f ${PIDFILE} ]; then
rm -rf ${PIDDIR}
fi

[notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

[James Vasile]

At Thu, 25 Feb 2010 11:53:14 +0100,
Sebastian Spaeth wrote:
> 
> On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins  finestructure.net> wrote:
> > > 2. It removes the "inbox" and "unread" tags while adding the tag to
> > >indicate deletion.
> > 
> > Hey, Carl.  Why is this last point important? [...]Why should it modify any 
> > other
> > tags?  A message/thread should be allowed to be both deleted and in the
> > inbox.
> 
> As long as deleted threads/messages show up in the default views, I
> don't want them to show up in my inbox or show up as unread. I agree
> that it might be possible to have "unread" yet "delete"d emails. But in
> reality, if I delete a message I don't want it to pop up in my inbox.
> 
> Feel free to apply patches however you want though, thanks to emacs,
> I'll be able to get my desired behavior nonetheless :).
> 
> > As for "unread", I think that should be handled by actually reading the
> > message, not by manually applying a state to it.
> 
> I agree, but deleting a message in my world view resets the unread tag
> (as in, I don't want to read it anymore).

This elisp might help.  I run these when deleting messages in search
or show modes.  Basically, this means I never see deleted threads
again.  I also use these to mark spam.

(defun notmuch-tags-strip-properties (tags)
  "return list of tags with emacs text properties removed

tags is a list of tags where each tag is a string with emacs text
properties
"
  (mapcar '(lambda (tag)
(set-text-properties 0 (length tag) nil tag)
tag)
  tags))

(defun notmuch-show-remove-all-tags ()
  "Remove all tags from the currently selected thread."
  (apply 'notmuch-show-remove-tag
 (notmuch-tags-strip-properties (notmuch-show-get-tags

(defun notmuch-search-remove-tags ( tags)
  "Remove multiple tags from the currently selected thread."
  (mapc 'notmuch-search-remove-tag tags))

(defun notmuch-search-remove-all-tags ()
  "Remove all tags from the currently selected thread."
  (apply 'notmuch-search-remove-tags
 (notmuch-tags-strip-properties (notmuch-search-get-tags

Re: [notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

[James Vasile]

At Thu, 25 Feb 2010 11:53:14 +0100,
Sebastian Spaeth wrote:
 
 On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins 
 jroll...@finestructure.net wrote:
   2. It removes the inbox and unread tags while adding the tag to
  indicate deletion.
  
  Hey, Carl.  Why is this last point important? [...]Why should it modify any 
  other
  tags?  A message/thread should be allowed to be both deleted and in the
  inbox.
 
 As long as deleted threads/messages show up in the default views, I
 don't want them to show up in my inbox or show up as unread. I agree
 that it might be possible to have unread yet deleted emails. But in
 reality, if I delete a message I don't want it to pop up in my inbox.
 
 Feel free to apply patches however you want though, thanks to emacs,
 I'll be able to get my desired behavior nonetheless :).
 
  As for unread, I think that should be handled by actually reading the
  message, not by manually applying a state to it.
 
 I agree, but deleting a message in my world view resets the unread tag
 (as in, I don't want to read it anymore).

This elisp might help.  I run these when deleting messages in search
or show modes.  Basically, this means I never see deleted threads
again.  I also use these to mark spam.

(defun notmuch-tags-strip-properties (tags)
  return list of tags with emacs text properties removed

tags is a list of tags where each tag is a string with emacs text
properties

  (mapcar '(lambda (tag)
(set-text-properties 0 (length tag) nil tag)
tag)
  tags))

(defun notmuch-show-remove-all-tags ()
  Remove all tags from the currently selected thread.
  (apply 'notmuch-show-remove-tag
 (notmuch-tags-strip-properties (notmuch-show-get-tags

(defun notmuch-search-remove-tags (rest tags)
  Remove multiple tags from the currently selected thread.
  (mapc 'notmuch-search-remove-tag tags))

(defun notmuch-search-remove-all-tags ()
  Remove all tags from the currently selected thread.
  (apply 'notmuch-search-remove-tags
 (notmuch-tags-strip-properties (notmuch-search-get-tags
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Initial tagging

[James Vasile]

I'm slowly groping my way to using the notmuch emacs client as my
routine MUA.  As I coerce it into tagging and displaying the way I want,
the next big question was automatically tagging things and getting them
in to notmuch.

I'm curious as to what people are doing in this regard.

My solution involves cron running a sync_email script.  Sync_email does
the correct dance to make sure it only ever runs one instance at a time.
It also logs to syslog.  The script runs offlineimap, a mail_filter
script that sorts mail in maildirs (for wanderlust, the MUA I'm hoping
to leave behind), and then finally a shell script to do notmuch new and
initial tagging.

The tagging script uses the inbox tag to identify new mail, tags it
according to criteria, then removes the inbox tag from anything it found
a match for.  Uncategorized mail keeps the inbox tag so I can inspect it
later and make rules for it (or tag it manually).

Also, prepending tag:inbox and to search criteria restricts the
tagging to a small subset of the db, which makes the tagging script run
fairly quickly.  My unexpurgated tagging script has almost 100 rules for
tagging, and I expect it to grow over time.

## notmuch-tag.sh 
#!/bin/bash

bin=/usr/local/bin/notmuch

function notmuch {
echo $1
while [ 1 -gt 0 ]; do
result=`$bin $1 21` 
regex=already locked

if [[ $result =~ $regex ]]; then
echo Xapian DB busy.  Retrying in 2 seconds
else
if [ -n $result ]; then
echo $result
fi
return
fi

sleep 2
done
}

function tag_new { notmuch tag $1 tag:inbox and ($2); }
function blacklist { tag_new -inbox -unread +delete $1; }

notmuch new

blacklist from:x...@example.com or from y...@example.com

# voicemail
tag_new -inbox +voicemail  from:a...@example.com

# friends
tag_new +friend +mathieu mathieu or ejm2106 or em...@example.com
tag_new +friend +balktick balktick

# open community services
tag_new +ocs open community services or opencommunityservices
   
# okos
tag_new +okos jim and glaser and not LinkedIn
tag_new +okos joshlevy...@example.com
tag_new +okos enri...@example.com

# book liberator
tag_new +bklib w...@example.com or bkrpr

# joomla
tag_new +osm from:waring or to:waring
tag_new +osm from:dave.huelsm...@example.com or 
to:dave.huelsm...@example.com
tag_new +osm james.vas...@example.com
tag_new +osm joomla

#lists
tag_new +list +notmuch to:notmuchmail.org or notmuch
tag_new +list +stumpwm to:stumpwm-de...@nongnu.org or stumpwm
tag_new +list +bklib to:bk...@googlegroups.com
   
## Catchalls for sflc, hv, etc.
tag_new +sflc not tag:list and not tag:friend and softwarefreedom.org and 
not tag:osm
tag_new +sflc to:f...@example.com
tag_new +hv hackervisions.org and not tag:list and not tag:friend
tag_new +gmail (to:jvas...@example.com or from:jvas...@example.com) and not 
tag:list and not tag:friend

## Mark mine unread
tag_new -unread from:ja...@example.com
tag_new -unread from:vas...@example.com
tag_new -unread from:james.vas...@example.com

## Remove inbox tag
tag_new -inbox tag:sflc or tag:hv or tag:list or tag:osm or tag:okos or 
tag:friend or tag:bklib


# sync_email #
#!/bin/sh

## Sync email unless we're already in the process of syncing.

SCRIPTNAME=`basename $0`
PIDDIR=/home/vasile/var/run/${SCRIPTNAME}
PIDFILE=${PIDDIR}/${SCRIPTNAME}.pid

## Do the double-lock with a dir and a pid file
if ! mkdir ${PIDDIR} 2/dev/null; then

   sleep 3 # give the other process time to write its pid

   if [ -f ${PIDFILE} ]; then
  #verify if the process is actually still running under this pid
  OLDPID=`cat ${PIDFILE}`
  RESULT=`ps -ef | grep ${OLDPID} | grep ${SCRIPTNAME}`  

  if [ -n ${RESULT} ]; then
logger -s ${SCRIPTNAME} already running! Exiting
exit 255
  fi
   fi
fi

## Update pid file
PID=`ps -ef | grep ${SCRIPTNAME} | head -n1 | awk ' {print $2;} '`
echo ${PID}  ${PIDFILE}

logger -s filter done, starting offlineimap
offlineimap -l /home/vasile/.offlineimap/log
logger -s offlineimap done, starting mail filter
mairix --unlock
/home/vasile/bin/mail_filter.py
logger -s mail filter done, starting notmuch tagger
/home/vasile/bin/notmuch-tag.sh  /home/vasile/var/log/notmuch
logger -s notmuch tagger done sync_email finished

## clean up pid file and dir
if [ -f ${PIDFILE} ]; then
rm -rf ${PIDDIR}
fi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Initial tagging

[James Vasile]

On Thu, 25 Feb 2010 17:02:08 -0800, Carl Worth cwo...@cworth.org wrote:
 One distinction is that I have all of my notmuch tag commands operate
 globally rather than just on new messages. One of the things that really
 annoyed be about sup was that the support for automatic tagging worked
 as a hook on messages as they were processed. So I couldn't use any of
 the tags for searches prior to the time that I had added a particular
 tag rule. I definitely didn't want to replicate that bug.

Sometimes I manually override a rule-based tag.  If automatic tagging
operated on old messages, overrides could be superseded.  When I add
automatic tag rules, I first execute them manually and globally from the
command line.

 To do my global searches quickly, I do a similar subsetting, but it's
 much simpler. If I'm adding the notmuch tag I do and not
 tag:notmuch. We've even had the proposal of making notmuch tag do
 that automatically.

That sounds like a good idea.  What happened with that proposal?

 Meanwhile, I'm planning on eventually moving entirely away from any tags
 that are driven entirely by searches like this. Instead, I'd like to
 just have good support for saved searches where we have some syntax to
 perform string expansion on configured search terms. 

Saved searches is a very good idea.  I look forward to it.

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