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>

Re: [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


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]

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] 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


pgpCCBjkxdq5R.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  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.


pgpVjRi7vyqPJ.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]

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!


pgpK53wq0ATxA.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]

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


pgpX9G6Mw19vJ.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: 

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

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>

Re: [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.


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

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

[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: 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@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

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: [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  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  
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: 

Re: [PATCH v2]: contrib/notmuch-mutt

[James Vasile]

I can't wait to give this a try.  Thanks much!


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

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 
 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.

Re: 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@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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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

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

[PATCH] Do not query on notmuch-search exit

[James Vasile]

Thanks for this, Michal.  I've applied it to my local tree.

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: 

Re: [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.

>From d0421e4308473347b31f5537eaec93b137084060 Mon Sep 17 00:00:00 2001
From: James Vasile 
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 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 
 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

[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!

Re: [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!

___
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 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.

Re: [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---
___
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  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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[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 &optional 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 = &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_messag

[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 &optional 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

___
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_sear

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 
 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.
___
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 
 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.

___
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

Re: 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@softwarefreedom.org>
Message-ID: <87fwqmfr2x@softwarefreedom.org>

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

[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

[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





malformed_subject
Description: Binary data
___
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]

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:
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: python documentation

[James Vasile]

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

Thanks,
James
___
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 
 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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

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

Re: 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
___
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 
 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] 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.

#!/usr/bin/python

from cnotmuch import notmuch
import notmuch_addresses

def get_matching_messages(self):
notmuch_db = notmuch.Database(self.db_path)
query_string = "(from:" + self.email

for addr in self.other_emails:
query_string += (" OR from:" + addr)

query_string += ")"

query = notmuch.Query(notmuch_db, query_string)
return query.search_messages()
notmuch_addresses._get_matching_messages = get_matching_messages


matcher = notmuch_addresses.NotmuchAddressMatcher('')
matcher.generate_matches()

print """
(defun bbdb-snarf-email-alias (name email)
  "Import email alias into bbdb"
  (condition-case nil 
  (unless (bbdb-search-simple nil email)
	(bbdb-create-internal name nil email nil nil nil))
(error nil)))
"""

for elem in matcher.matches:
if not '@' in elem:
continue
if not '<' in elem:
print "(bbdb-snarf-email-alias \"%s\")" % elem.lower()
else:
elem = elem.replace('"', '')
elem = elem.replace(' <', '" "')
elem = elem.replace('>', '"')
if elem[0] != '"':
elem = '"%s' % elem
print "(bbdb-snarf-email-alias %s)" % elem


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

[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  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

Re: [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 "ja...@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 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 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)

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  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 "ja...@hackervisions.org")
  (message-mode-set-profile)
  user-mail-address)
(mail-profile-hv)


___
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 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 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
___
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  
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] 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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch