Re: [PATCH] emacs: More DWIM when editing messages

[Carl Worth]

On Tue, 27 Apr 2010 06:34:51 +0100, David Edmondson  wrote:
> On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel  
> wrote:
> > +(if (re-search-backward "-- " nil t)
> 
> Maybe `message-signature-separator' rather than the literal "-- "
> here.

Good catch. Dirk did say he was almost sure he had seen a variable
containing this regexp somewhere... :-)

I've pushed a fix for this.

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] emacs: More DWIM when editing messages

[Carl Worth]

On Tue, 27 Apr 2010 06:34:51 +0100, David Edmondson  wrote:
> On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel  
> wrote:
> > +(if (re-search-backward "-- " nil t)
> 
> Maybe `message-signature-separator' rather than the literal "-- "
> here.

Good catch. Dirk did say he was almost sure he had seen a variable
containing this regexp somewhere... :-)

I've pushed a fix for this.

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/7dd5d867/attachment.pgp>

Re: [PATCH] emacs: fcc should fail at the right time if it doesn't point to a maildir

[Carl Worth]

On Mon, 26 Apr 2010 20:29:27 -0400, Jesse Rosenthal  wrote:
> Throw an error after the maildir is generated but before the message
> is sent. This change allows the user to edit the maildir if it fails,
> so that it will point to a correct place.

Very nice. Just in time for 0.3, I merged this in, (and the 2
followups).

-Carl


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

[PATCH] emacs: fcc should fail at the right time if it doesn't point to a maildir

[Carl Worth]

On Mon, 26 Apr 2010 20:29:27 -0400, Jesse Rosenthal  
wrote:
> Throw an error after the maildir is generated but before the message
> is sent. This change allows the user to edit the maildir if it fails,
> so that it will point to a correct place.

Very nice. Just in time for 0.3, I merged this in, (and the 2
followups).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/a4fcd3d9/attachment.pgp>

[PATCH] emacs: Ensure that message-directory for Fcc has a trailing slash

[Jesse Rosenthal]

Use `file-name-as-directory' to ensure that message-directory has a
trailing slash so it can be combined with the notmuch-fcc-dirs
correctly.
---
 emacs/notmuch-maildir-fcc.el |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 6d75b11..ecb65e7 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -71,7 +71,9 @@
   (cdr (assoc-string (message-fetch-field "from") notmuch-fcc-dirs 
t
  (if (eq subdir nil) (setq subdir (car (car notmuch-fcc-dirs
  (unless (message-fetch-field "fcc")
-   (message-add-header (concat "Fcc: " message-directory subdir)))
+   (message-add-header (concat "Fcc: " 
+  (file-name-as-directory message-directory) 
+  subdir)))
  (let ((fcc-header (message-fetch-field "fcc")))
  (unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header)
(cond ((not (file-writable-p fcc-header))
-- 
1.6.3.3

Re: [PATCH] emacs: More DWIM when editing messages

[David Edmondson]

On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel  wrote:
> +(if (re-search-backward "-- " nil t)

Maybe `message-signature-separator' rather than the literal "-- " here.

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


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

[PATCH] emacs: add prompt to create maildir for fcc if it does not exist.

[Jesse Rosenthal]

If the user specifies a maildir that does not exist, prompt the user to
see whether a maildir should be created. This will fail, with the
relevant explanation, if the location is not writable, or if a file
already exists in that location. If the location is a dir, but not a
maildir, this will add /tmp/cur/new to it.
---
NB. This builds on the patch in the parent email:
id:87mxwpd9g8.fsf at jhu.edu

 emacs/notmuch-maildir-fcc.el |   26 ++
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 34b1915..6d75b11 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -72,10 +72,16 @@
  (if (eq subdir nil) (setq subdir (car (car notmuch-fcc-dirs
  (unless (message-fetch-field "fcc")
(message-add-header (concat "Fcc: " message-directory subdir)))
- (unless (notmuch-maildir-fcc-dir-is-maildir-p 
- (message-fetch-field "fcc"))
-   (error (format "%s is not a maildir." (message-fetch-field "fcc")))
-
+ (let ((fcc-header (message-fetch-field "fcc")))
+ (unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header)
+   (cond ((not (file-writable-p fcc-header))
+ (error (format "%s is not a maildir, but you don't have 
permission to create one." fcc-header)))
+((y-or-n-p (format "%s is not a maildir. Create it? "
+fcc-header))
+ (notmuch-maildir-fcc-create-maildir fcc-header))
+(t
+ (error "Not sending message."
+ 
 (defun notmuch-maildir-fcc-host-fixer (hostname)
   (replace-regexp-in-string "/\\|:"
'(lambda (s)
@@ -104,6 +110,18 @@
(file-exists-p (concat dir "/new/"))
(file-exists-p (concat dir "/tmp/"

+(defun notmuch-maildir-fcc-create-maildir (path)
+  (cond ((or (not (file-exists-p path)) (file-directory-p path))
+(make-directory (concat path "/cur/") t)
+(make-directory (concat path "/new/") t)
+(make-directory (concat path "/tmp/") t))
+   ((file-regular-p path)
+(error "%s is a file. Can't creat maildir." path))
+   (t
+(error "I don't know how to create a maildir here"
+
+  
+
 (defun notmuch-maildir-fcc-save-buffer-to-tmp (destdir)
   "Returns the msg id of the message written to the temp directory
 if successful, nil if not."
-- 
1.6.3.3

[PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.

[David Bremner]

On Mon, 26 Apr 2010 16:33:27 -0700, Carl Worth  wrote:
> 
> I tried to look at it a couple of times, but it was already stale then
> so I didn't look hard enough.
> 
> The couple of questions I have are:
> 
>   * How close does the generated output match what we have today?

Pretty close, I think.  Essentially I just reformatted one or two places
to make the online help easier to pull out of the man pages.

>   * What additional tools does this require for someone to build the
> tree from the git repository?

A recentish version of perl. 5.8.8 (2006) seems to have the utilities
we'd need.  I guess if people have git, they have perl. I guess in
principle we could ship the pre-processed docs in a distribution
tarball.

> > Should I rebase/rebuild this against the current docs, or not bother?
> 
> I'd be interested in taking another look, if you're willing to take
> another whack at it. I think that our command-line interface is changing
> a lot more slowly such that this won't go immediately stale this time.

Sure, I can have another go at it.  

d

bug tracking

[Arvid Picciani]

On Mon, 26 Apr 2010 11:31:05 -0700, Carl Worth  wrote:

> For example, if dme commits a fix and marks "issue #217 closed" with
> that fix, then I'd like my repository of bugs to also know to close that
> issue when I later merge his fix.

bitbucket does that, and i would bet its quite a common feature on the
large git hosters too.

--
Arvid

[PATCH] emacs: fcc should fail at the right time if it doesn't point to a maildir

[Jesse Rosenthal]

Throw an error after the maildir is generated but before the message
is sent. This change allows the user to edit the maildir if it fails,
so that it will point to a correct place.

Note that this changes the previous behavior which always overwrote
the existing Fcc line. Now, an Fcc line is only auto-generated if
there isn't one already there.

The ideal change would be to prompt to create a maildir. This should
enable a place for doing that in a future patch.
---
 emacs/notmuch-maildir-fcc.el |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 64f60bc..34b1915 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -70,8 +70,11 @@
(let ((subdir
   (cdr (assoc-string (message-fetch-field "from") notmuch-fcc-dirs 
t
  (if (eq subdir nil) (setq subdir (car (car notmuch-fcc-dirs
- (message-remove-header "Fcc")
- (message-add-header (concat "Fcc: " message-directory subdir)
+ (unless (message-fetch-field "fcc")
+   (message-add-header (concat "Fcc: " message-directory subdir)))
+ (unless (notmuch-maildir-fcc-dir-is-maildir-p 
+ (message-fetch-field "fcc"))
+   (error (format "%s is not a maildir." (message-fetch-field "fcc")))

 (defun notmuch-maildir-fcc-host-fixer (hostname)
   (replace-regexp-in-string "/\\|:"
-- 
1.6.3.3

[PATCH] emacs: Ensure that message-directory for Fcc has a trailing slash

[Jesse Rosenthal]

Use `file-name-as-directory' to ensure that message-directory has a
trailing slash so it can be combined with the notmuch-fcc-dirs
correctly.
---
 emacs/notmuch-maildir-fcc.el |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 6d75b11..ecb65e7 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -71,7 +71,9 @@
   (cdr (assoc-string (message-fetch-field "from") notmuch-fcc-dirs 
t
  (if (eq subdir nil) (setq subdir (car (car notmuch-fcc-dirs
  (unless (message-fetch-field "fcc")
-   (message-add-header (concat "Fcc: " message-directory subdir)))
+   (message-add-header (concat "Fcc: " 
+  (file-name-as-directory message-directory) 
+  subdir)))
  (let ((fcc-header (message-fetch-field "fcc")))
  (unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header)
(cond ((not (file-writable-p fcc-header))
-- 
1.6.3.3

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

Re: [PATCH] emacs: fcc should fail at the right time if it doesn't point to a maildir

[Dirk Hohndel]

On Mon, 26 Apr 2010 20:29:27 -0400, Jesse Rosenthal  wrote:
> Throw an error after the maildir is generated but before the message
> is sent. This change allows the user to edit the maildir if it fails,
> so that it will point to a correct place.
> 
> Note that this changes the previous behavior which always overwrote
> the existing Fcc line. Now, an Fcc line is only auto-generated if
> there isn't one already there.

I like this behavior
 
> The ideal change would be to prompt to create a maildir. This should
> enable a place for doing that in a future patch.

It would also be nice to catch the common mistake of not ending the
message-directory with a /

/D


-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: fcc should fail at the right time if it doesn't point to a maildir

[Dirk Hohndel]

On Mon, 26 Apr 2010 20:29:27 -0400, Jesse Rosenthal  
wrote:
> Throw an error after the maildir is generated but before the message
> is sent. This change allows the user to edit the maildir if it fails,
> so that it will point to a correct place.
> 
> Note that this changes the previous behavior which always overwrote
> the existing Fcc line. Now, an Fcc line is only auto-generated if
> there isn't one already there.

I like this behavior

> The ideal change would be to prompt to create a maildir. This should
> enable a place for doing that in a future patch.

It would also be nice to catch the common mistake of not ending the
message-directory with a /

/D


-- 
Dirk Hohndel
Intel Open Source Technology Center

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[David Edmondson]

On Mon, 26 Apr 2010 11:03:36 -0700, Carl Worth  wrote:
> Thanks. I've pushed this. Bonus points to someone who fixes it to avoid
> printing "1 matches".

It shouldn't do that:

  (let* (...
 (num-options (length options))
 (chosen (if (eq num-options 1)
 (car options)
   (completing-read (format "Address (%s matches): " 
num-options)
(cdr options) nil nil (car options)
'notmuch-address-history

Does it?

More interesting is the zero matches case...

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/7be11cdf/attachment.pgp>

Kudos! Also: +1 PGP!

[Darren McGuicken]

On Mon, 26 Apr 2010 07:16:16 -0400, Jameson Rollins  wrote:
> > In the meantime, I find myself using the snippet from Tassilo in:
> > id:87zl6cl595.fsf at thinkpad.tsdh.de
> 
> I'm interested in using this as a stop-gap, but unfortunately I'm not
> finding this message in my local store.  Can you point to url in an
> archive, or forward this to me or the list?

Absolutely, you can find the thread on gmane here:

 http://thread.gmane.org/gmane.mail.notmuch.general/778/focus=78

One other thing I'd recommend is downloading the complete archive from
the link on notmuchmail.org:

 http://notmuchmail.org/archives/notmuch.mbox

It's incredibly handy being able to search for notmuch information with
notmuch itself!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/b9de8e61/attachment.pgp>

[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[David Edmondson]

On Mon, 26 Apr 2010 13:38:37 -0400, Jameson Rollins  wrote:
> What about advanced users?  I really want my notmuch front page to just
> be a particular saved search.  The notmuch-hello looks neat, but I don't
> really see myself ever using it, since I can access all the
> functionality I need already.  All I really want from a front page is
> the main search that I look at all the time ("tag:inbox and not
> tag:deleted"), have it *not* close if I accidentally hit 'q', and a way
> to pop back to it from wherever I am.  Could we make it configurable so
> that the front page is either the hello page, or the special search page
> I describe?

Isn't something like:

(global-set-key "\C-ci" '(lambda () (interactive) (notmuch-search "tag:inbox 
and not tag:deleted" notmuch-search-oldest-first)))

all you need?

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/6fe4da75/attachment.pgp>

Re: [PATCH] emacs: More DWIM when editing messages

[Dirk Hohndel]

On Mon, 26 Apr 2010 16:39:44 -0700, Carl Worth  wrote:
> On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel  
> wrote:
> > This appears not to have gone out??? Must be that weird MUA that I'm
> > using...
> 
> Strange. I couldn't find it earlier, and now I have both versions
> here. So blame me, (or the weird MUA that I'm using...).

Nope, wasn't you - my MTA (not MUA) had stalled the message. When I
noticed, both went out at the same time (which you can see from the
headers)
 
> > The existing code inserts the signature before inserting the message
> > body (which it puts at the very end of the buffer - therefore AFTER
> > the signature). This little snippet makes us search backwards and
> > insert the message body before a signature, if it exists.
> 
> Works great. This is pushed.

Thanks

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: More DWIM when editing messages

[Dirk Hohndel]

On Mon, 26 Apr 2010 16:39:44 -0700, Carl Worth  wrote:
> On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel  
> wrote:
> > This appears not to have gone out??? Must be that weird MUA that I'm
> > using...
> 
> Strange. I couldn't find it earlier, and now I have both versions
> here. So blame me, (or the weird MUA that I'm using...).

Nope, wasn't you - my MTA (not MUA) had stalled the message. When I
noticed, both went out at the same time (which you can see from the
headers)

> > The existing code inserts the signature before inserting the message
> > body (which it puts at the very end of the buffer - therefore AFTER
> > the signature). This little snippet makes us search backwards and
> > insert the message body before a signature, if it exists.
> 
> Works great. This is pushed.

Thanks

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: [PATCH] RFC: Add From guessing when forwarding email

[Dirk Hohndel]

On Mon, 26 Apr 2010 16:27:50 -0700, Carl Worth  wrote:
> On Fri, 23 Apr 2010 15:52:15 -0700, Dirk Hohndel  
> wrote:
> > This adds a new "guess-from" option to notmuch and modifies the
> > emacs UI to use this to use the best guess from address when
> > forwarding email.
> 
> I don't want to add a new top-level command for this functionality,
> (which is fairly special-purpose), since I want to keep the notmuch
> command-line easy to learn and use by actual humans.
> 
> And an actual human would rarely have any need to call this command.
> 
> So maybe bury this under "notmuch reply --output=guess-from" or
> something like that?

That's the kind of feedback I was waiting for. No problem - will update
my patch after the 0.3 release

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] RFC: Add From guessing when forwarding email

[Dirk Hohndel]

On Mon, 26 Apr 2010 16:27:50 -0700, Carl Worth  wrote:
> On Fri, 23 Apr 2010 15:52:15 -0700, Dirk Hohndel  
> wrote:
> > This adds a new "guess-from" option to notmuch and modifies the
> > emacs UI to use this to use the best guess from address when
> > forwarding email.
> 
> I don't want to add a new top-level command for this functionality,
> (which is fairly special-purpose), since I want to keep the notmuch
> command-line easy to learn and use by actual humans.
> 
> And an actual human would rarely have any need to call this command.
> 
> So maybe bury this under "notmuch reply --output=guess-from" or
> something like that?

That's the kind of feedback I was waiting for. No problem - will update
my patch after the 0.3 release

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

[PATCH] emacs: add prompt to create maildir for fcc if it does not exist.

[Jesse Rosenthal]

If the user specifies a maildir that does not exist, prompt the user to
see whether a maildir should be created. This will fail, with the
relevant explanation, if the location is not writable, or if a file
already exists in that location. If the location is a dir, but not a
maildir, this will add /tmp/cur/new to it.
---
NB. This builds on the patch in the parent email:
id:87mxwpd9g8@jhu.edu

 emacs/notmuch-maildir-fcc.el |   26 ++
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 34b1915..6d75b11 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -72,10 +72,16 @@
  (if (eq subdir nil) (setq subdir (car (car notmuch-fcc-dirs
  (unless (message-fetch-field "fcc")
(message-add-header (concat "Fcc: " message-directory subdir)))
- (unless (notmuch-maildir-fcc-dir-is-maildir-p 
- (message-fetch-field "fcc"))
-   (error (format "%s is not a maildir." (message-fetch-field "fcc")))
-
+ (let ((fcc-header (message-fetch-field "fcc")))
+ (unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header)
+   (cond ((not (file-writable-p fcc-header))
+ (error (format "%s is not a maildir, but you don't have 
permission to create one." fcc-header)))
+((y-or-n-p (format "%s is not a maildir. Create it? "
+fcc-header))
+ (notmuch-maildir-fcc-create-maildir fcc-header))
+(t
+ (error "Not sending message."
+ 
 (defun notmuch-maildir-fcc-host-fixer (hostname)
   (replace-regexp-in-string "/\\|:"
'(lambda (s)
@@ -104,6 +110,18 @@
(file-exists-p (concat dir "/new/"))
(file-exists-p (concat dir "/tmp/"
 
+(defun notmuch-maildir-fcc-create-maildir (path)
+  (cond ((or (not (file-exists-p path)) (file-directory-p path))
+(make-directory (concat path "/cur/") t)
+(make-directory (concat path "/new/") t)
+(make-directory (concat path "/tmp/") t))
+   ((file-regular-p path)
+(error "%s is a file. Can't creat maildir." path))
+   (t
+(error "I don't know how to create a maildir here"
+
+  
+
 (defun notmuch-maildir-fcc-save-buffer-to-tmp (destdir)
   "Returns the msg id of the message written to the temp directory
 if successful, nil if not."
-- 
1.6.3.3

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

Kudos! Also: +1 PGP!

[David Edmondson]

On Mon, 26 Apr 2010 12:19:26 -0400, Jameson Rollins  wrote:
> On Mon, 26 Apr 2010 17:11:33 +0100, David Edmondson  wrote:
> > multipart/signed really needs the re-worked JSON output so that the UI
> > can know what is going on. It might be possible to kludge something
> > together with the current output, but it will be awkward.
> 
> Actually the emacs UI is current using the JSON output, since the
> bremner's reworking got merged a couple weeks ago.

Unfortunately we still need more. notmuch doesn't include the details of
how parts are related in a multipart/* message.

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/0df8a3b3/attachment.pgp>

[PATCH] emacs: `notmuch' should display the `notmuch-hello' interface

[David Edmondson]

On Mon, 26 Apr 2010 09:11:07 -0700, Dirk Hohndel  
wrote:
> This is lacking a committ message...

I wasn't sure what else to say.

> On Mon, 26 Apr 2010 16:07:04 +0100, dme at dme.org wrote:
> > From: David Edmondson 
> > --- a/emacs/notmuch-lib.el
> > +++ b/emacs/notmuch-lib.el
> > @@ -33,6 +33,11 @@
> >:type '(alist :key-type (string) :value-type (string))
> >:group 'notmuch)
> >  
> > +(defcustom notmuch-search-oldest-first t
> > +  "Show the oldest mail first when searching."
> > +  :type 'boolean
> > +  :group 'notmuch)
> > +
> 
> And this doesn't seem related to the subject...
> 
> > @@ -221,8 +222,6 @@ For a mouse binding, return nil."
> >  (defvar notmuch-search-query-string)
> >  (defvar notmuch-search-target-thread)
> >  (defvar notmuch-search-target-line)
> > -(defvar notmuch-search-oldest-first t
> > -  "Show the oldest mail first in the search-mode")
> >  (defvar notmuch-search-continuation)
> >  
> >  (defvar notmuch-search-disjunctive-regexp  "\\<[oO][rR]\\>")
> 
> ditto...

They are both due to re-arranging the relationship between notmuch.el
and notmuch-hello.el.

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/8d3d94ff/attachment-0001.pgp>

[PATCH] emacs: fcc should fail at the right time if it doesn't point to a maildir

[Jesse Rosenthal]

Throw an error after the maildir is generated but before the message
is sent. This change allows the user to edit the maildir if it fails,
so that it will point to a correct place.

Note that this changes the previous behavior which always overwrote
the existing Fcc line. Now, an Fcc line is only auto-generated if
there isn't one already there.

The ideal change would be to prompt to create a maildir. This should
enable a place for doing that in a future patch.
---
 emacs/notmuch-maildir-fcc.el |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 64f60bc..34b1915 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -70,8 +70,11 @@
(let ((subdir
   (cdr (assoc-string (message-fetch-field "from") notmuch-fcc-dirs 
t
  (if (eq subdir nil) (setq subdir (car (car notmuch-fcc-dirs
- (message-remove-header "Fcc")
- (message-add-header (concat "Fcc: " message-directory subdir)
+ (unless (message-fetch-field "fcc")
+   (message-add-header (concat "Fcc: " message-directory subdir)))
+ (unless (notmuch-maildir-fcc-dir-is-maildir-p 
+ (message-fetch-field "fcc"))
+   (error (format "%s is not a maildir." (message-fetch-field "fcc")))
 
 (defun notmuch-maildir-fcc-host-fixer (hostname)
   (replace-regexp-in-string "/\\|:"
-- 
1.6.3.3

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

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[David Edmondson]

   To: David Edmondson , notmuch at notmuchmail.org, dirk at 
yoom.home.cworth.org
   Cc: carl at ut.hh.sledj.net
   Date: Mon, 26 Apr 2010 08:21:51 -0700

Something interesting is happening here :-)

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/a44847fa/attachment.pgp>

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[David Edmondson]

On Mon, 26 Apr 2010 08:21:51 -0700, Carl Worth  wrote:
> > > Finally, though, I haven't figured out how to get more than a single
> > > match from this. If the first match isn't what I want, how do I see and
> > > choose later matches?
> > 
> > M-n to move forward in the list, M-p to move backwards (including into
> > any history you have accrued).
> 
> Ah-hah! Thanks for filling me in. I'm glad to finally have usable
> notmuch-based address completion now.
> 
>  Perhaps we could add a hint in the minibuffer prompt?
> 
>   Address (+6 more): Name Here 

Patch is sent for this, though given that it's not easy to change the
prompt as you step through, it says:

Address (7 match): Name Here 

> I'd like to come up with something more specific in that hint, but it
> gets a little long:
> 
>   Address (Use M-n/M-p or arrow keys for 6 more):

Moving through potential completions is pretty standard Emacs UI stuff,
so I'm not sure if it's necessary to explain? (Of course, that you had
to ask suggests otherwise...)

> I don't suppose it would be feasible to make Space and DEL navigate
> through the list as well would it?

Not with `completing-read', but I'll look at it after 0.3.

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/ce2a9d96/attachment.pgp>

[PATCH] emacs: Tell the user how many addresses matched when completing

[d...@dme.org]

From: David Edmondson 

When completing an address, tell the user how many addresses in the
database matched the query.
---
 emacs/notmuch-address.el |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 69a52a2..a295204 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -53,9 +53,11 @@ line."
 (orig (buffer-substring-no-properties beg end))
 (completion-ignore-case t)
 (options (notmuch-address-options orig))
-(chosen (if (eq (length options) 1)
+(num-options (length options))
+(chosen (if (eq num-options 1)
 (car options)
-  (completing-read "Address: " (cdr options) nil nil (car 
options)
+  (completing-read (format "Address (%s matches): " 
num-options 1)
+   (cdr options) nil nil (car options)
'notmuch-address-history
 (when chosen
   (push chosen notmuch-address-history)
-- 
1.7.0

[SCM] notmuch - thread-based email index, search and tagging. branch, master, updated. 0.2-191-g38c35f8

[David Edmondson]

On Mon, 26 Apr 2010 07:17:47 -0700 (PDT), notmuch-commits-sender at 
notmuchmail.org (Carl Worth) wrote:
> commit 97570954cb583cacac35b0235cbe449a07630ae3
> Author: David Edmondson 
> Date:   Thu Apr 22 13:26:06 2010 +0100
> 
> emacs: Add more functions to clean up text/plain parts
> 
> Add:
> - notmuch-wash-wrap-long-lines: Wrap lines longer than the width of
>   the current window whilst maintaining any citation prefix.
> - notmuch-wash-tidy-citations: Tidy up citations by:
>   - compress repeated otherwise blank citation lines,
>   - remove otherwise blank citation lines at the head and tail of a
> citation and remove blank lines between attribution statements and
> the citation,
> - notmuch-wash-compress-blanks: Compress repeated blank lines and
>   remove leading and trailing blank lines.
> 
> Enable `notmuch-wash-tidy-citations' and
> `notmuch-wash-compress-blanks' by default by adding them to
> `notmuch-show-insert-text/plain-hook'. `notmuch-wash-wrap-long-lines'
> is not enabled by default.
> 
> If `notmuch-wash-wrap-long-lines' is enabled, word wrapping of the
> buffer leads to an unappealing display of text, so provide a function
> to disable it and add it to the list of `notmuch-show-mode' hook
> functions.

This looks as though you took the earlier patch rather than one that I
sent today (id:1272289530-12593-1-git-send-email-dme at dme.org is the most
recent).

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/5e304264/attachment-0001.pgp>

Kudos! Also: +1 PGP!

[David Edmondson]

On Mon, 26 Apr 2010 15:52:37 +0200, "Sebastian Spaeth"  wrote:
> We were discussing on IRC whether decryption should be handled in
> notmuch show --decrypt or in emacs and I had a quick look at what it
> would take for emacs. Here is a snippet of code that outputs
> "Good signature from 5585F58CC827A062 Sebastian Spaeth (Private
> Communication)  (trust ultimate) created at
> 2010-04-26T14:27:07+0200 using DSA" in the minibuffer. I guess something
> based on this could be used to parse the email and try to decrypt via gpg
> and mark the signature status in the summary line:

Inline PGP could be handled by the text/plain washing functions. I had a
quick go at this and bremner tested, but there were some wrinkles and I
didn't finish it.

multipart/signed really needs the re-worked JSON output so that the UI
can know what is going on. It might be possible to kludge something
together with the current output, but it will be awkward.

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/a89798ba/attachment.pgp>

Re: [PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.

[David Bremner]

On Mon, 26 Apr 2010 16:33:27 -0700, Carl Worth  wrote:
> 
> I tried to look at it a couple of times, but it was already stale then
> so I didn't look hard enough.
> 
> The couple of questions I have are:
> 
>   * How close does the generated output match what we have today?

Pretty close, I think.  Essentially I just reformatted one or two places
to make the online help easier to pull out of the man pages.

>   * What additional tools does this require for someone to build the
> tree from the git repository?

A recentish version of perl. 5.8.8 (2006) seems to have the utilities
we'd need.  I guess if people have git, they have perl. I guess in
principle we could ship the pre-processed docs in a distribution
tarball.

> > Should I rebase/rebuild this against the current docs, or not bother?
> 
> I'd be interested in taking another look, if you're willing to take
> another whack at it. I think that our command-line interface is changing
> a lot more slowly such that this won't go immediately stale this time.

Sure, I can have another go at it.  

d

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

Re: "bouncing" messages

[Carl Worth]

On Wed, 21 Apr 2010 19:54:20 -0300, Fernando Carrijo  
wrote:
> micah anderson  wrote:
> > It would be great if this became a key to make this easier. In mutt,
> > that key is 'b', which prompts you who you should send the message
> > to. That key is already bound to showing the body in notmuch, but I'm
> > sure there are other options.
> 
> Carl just dropped that binding, so now we can reuse 'b' to message bouncing.

I was just about to say the same thing. I'm all for 'b' for bouncing, (I
think I first used that in pine long, long ago...)

-Carl

-- 
carl.d.wo...@intel.com


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

"bouncing" messages

[Carl Worth]

On Wed, 21 Apr 2010 19:54:20 -0300, Fernando Carrijo  
wrote:
> micah anderson  wrote:
> > It would be great if this became a key to make this easier. In mutt,
> > that key is 'b', which prompts you who you should send the message
> > to. That key is already bound to showing the body in notmuch, but I'm
> > sure there are other options.
> 
> Carl just dropped that binding, so now we can reuse 'b' to message bouncing.

I was just about to say the same thing. I'm all for 'b' for bouncing, (I
think I first used that in pine long, long ago...)

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/243a331d/attachment.pgp>

Re: [PATCH] emacs: More DWIM when editing messages

[Carl Worth]

On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel  wrote:
> This appears not to have gone out??? Must be that weird MUA that I'm
> using...

Strange. I couldn't find it earlier, and now I have both versions
here. So blame me, (or the weird MUA that I'm using...).

> The existing code inserts the signature before inserting the message
> body (which it puts at the very end of the buffer - therefore AFTER
> the signature). This little snippet makes us search backwards and
> insert the message body before a signature, if it exists.

Works great. This is pushed.

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] emacs: More DWIM when editing messages

[Carl Worth]

On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel  
wrote:
> This appears not to have gone out??? Must be that weird MUA that I'm
> using...

Strange. I couldn't find it earlier, and now I have both versions
here. So blame me, (or the weird MUA that I'm using...).

> The existing code inserts the signature before inserting the message
> body (which it puts at the very end of the buffer - therefore AFTER
> the signature). This little snippet makes us search backwards and
> insert the message body before a signature, if it exists.

Works great. This is pushed.

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/e9e719b1/attachment.pgp>

Re: [PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.

[Carl Worth]

-- 
carl.d.wo...@intel.com
On Sat, 24 Apr 2010 11:04:49 -0300, David Bremner  wrote:
> As I'm faced with writing docs for output selection, I'd like to revisit
> this idea. I didn't get any feedback, positive or negative about the
> idea of keeping the docs in pod.  I don't care much about the format,
> but I think it would be nice to avoid maintaining two copies of the
> documentation.

Sorry about the lack of feedback from me on this.

I tried to look at it a couple of times, but it was already stale then
so I didn't look hard enough.

The couple of questions I have are:

  * How close does the generated output match what we have today?

  * What additional tools does this require for someone to build the
tree from the git repository?

> Should I rebase/rebuild this against the current docs, or not bother?

I'd be interested in taking another look, if you're willing to take
another whack at it. I think that our command-line interface is changing
a lot more slowly such that this won't go immediately stale this time.

Though you could perhaps start by answering the above questions which
might be less work. :-)

-Carl


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

[PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.

[Carl Worth]

-- 
carl.d.worth at intel.com
On Sat, 24 Apr 2010 11:04:49 -0300, David Bremner  wrote:
> As I'm faced with writing docs for output selection, I'd like to revisit
> this idea. I didn't get any feedback, positive or negative about the
> idea of keeping the docs in pod.  I don't care much about the format,
> but I think it would be nice to avoid maintaining two copies of the
> documentation.

Sorry about the lack of feedback from me on this.

I tried to look at it a couple of times, but it was already stale then
so I didn't look hard enough.

The couple of questions I have are:

  * How close does the generated output match what we have today?

  * What additional tools does this require for someone to build the
tree from the git repository?

> Should I rebase/rebuild this against the current docs, or not bother?

I'd be interested in taking another look, if you're willing to take
another whack at it. I think that our command-line interface is changing
a lot more slowly such that this won't go immediately stale this time.

Though you could perhaps start by answering the above questions which
might be less work. :-)

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/c851af7e/attachment.pgp>

Re: [PATCH] RFC: Add From guessing when forwarding email

[Carl Worth]

On Fri, 23 Apr 2010 15:52:15 -0700, Dirk Hohndel  wrote:
> This adds a new "guess-from" option to notmuch and modifies the
> emacs UI to use this to use the best guess from address when
> forwarding email.

I don't want to add a new top-level command for this functionality,
(which is fairly special-purpose), since I want to keep the notmuch
command-line easy to learn and use by actual humans.

And an actual human would rarely have any need to call this command.

So maybe bury this under "notmuch reply --output=guess-from" or
something like that?

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

[PATCH] RFC: Add From guessing when forwarding email

[Carl Worth]

On Fri, 23 Apr 2010 15:52:15 -0700, Dirk Hohndel  
wrote:
> This adds a new "guess-from" option to notmuch and modifies the
> emacs UI to use this to use the best guess from address when
> forwarding email.

I don't want to add a new top-level command for this functionality,
(which is fairly special-purpose), since I want to keep the notmuch
command-line easy to learn and use by actual humans.

And an actual human would rarely have any need to call this command.

So maybe bury this under "notmuch reply --output=guess-from" or
something like that?

-Carl

[PATCH] emacs: Remove duplicate declaration of `notmuch-folders'

[d...@dme.org]

From: David Edmondson 

---
 emacs/notmuch.el |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 428ae6c..e207180 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -659,11 +659,6 @@ characters as well as `_.+-'.
 (apply 'notmuch-call-notmuch-process "tag"
   (append action-split (list notmuch-search-query-string) nil

-(defcustom notmuch-folders (quote (("inbox" . "tag:inbox") ("unread" . 
"tag:unread")))
-  "List of searches for the notmuch folder view"
-  :type '(alist :key-type (string) :value-type (string))
-  :group 'notmuch)
-
 (defun notmuch-search-buffer-title (query)
   "Returns the title for a buffer with notmuch search results."
   (let* ((folder (rassoc-if (lambda (key)
-- 
1.7.0

[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[David Edmondson]

On Fri, 23 Apr 2010 13:13:01 -0700, Carl Worth  wrote:
> Finally, I'm quite inclined to make `notmuch' invoke this mode, so think
> about that.

See id:1272294424-17363-1-git-send-email-dme at dme.org.

dme.
-- 
David Edmondson, http://dme.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/e4d69d83/attachment.pgp>

[PATCH] emacs: `notmuch' should display the `notmuch-hello' interface

[d...@dme.org]

From: David Edmondson 

---
 emacs/notmuch-hello.el |1 -
 emacs/notmuch-lib.el   |5 +
 emacs/notmuch.el   |7 +++
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 30b3a5e..bd882b8 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -24,7 +24,6 @@
 (require 'cl)

 (require 'notmuch-lib)
-(require 'notmuch)
 (require 'notmuch-mua)

 (declare-function notmuch-search "notmuch" (query &optional oldest-first 
target-thread target-line continuation))
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 47c74b9..b64aeab 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -33,6 +33,11 @@
   :type '(alist :key-type (string) :value-type (string))
   :group 'notmuch)

+(defcustom notmuch-search-oldest-first t
+  "Show the oldest mail first when searching."
+  :type 'boolean
+  :group 'notmuch)
+
 ;;

 (defun notmuch-version ()
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index eecff23..428ae6c 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -54,6 +54,7 @@
 (require 'notmuch-lib)
 (require 'notmuch-show)
 (require 'notmuch-mua)
+(require 'notmuch-hello)

 (defcustom notmuch-search-result-format
   `(("date" . "%s ")
@@ -221,8 +222,6 @@ For a mouse binding, return nil."
 (defvar notmuch-search-query-string)
 (defvar notmuch-search-target-thread)
 (defvar notmuch-search-target-line)
-(defvar notmuch-search-oldest-first t
-  "Show the oldest mail first in the search-mode")
 (defvar notmuch-search-continuation)

 (defvar notmuch-search-disjunctive-regexp  "\\<[oO][rR]\\>")
@@ -811,9 +810,9 @@ current search results AND that are tagged with the given 
tag."

 ;;;###autoload
 (defun notmuch ()
-  "Run notmuch to display all mail with tag of 'inbox'"
+  "Run notmuch and display saved searches, known tags, etc."
   (interactive)
-  (notmuch-search "tag:inbox" notmuch-search-oldest-first))
+  (notmuch-hello))

 (setq mail-user-agent 'notmuch-user-agent)

-- 
1.7.0

[PATCH] emacs: Fix `notmuch-show-rewind' in the presence of invisible text

[d...@dme.org]

From: David Edmondson 

When determining whether or not to re-align the head of the current
message with the top of the window, use `count-screen-lines' rather
than `count-lines' to allow for invisible text in the preceding
message. When comparing that number of lines against
`next-screen-context-lines', realign if the number of lines of the
previous message visible is 'smaller than or equal to' rather than
just 'smaller than' to improve usability.
---
 emacs/notmuch-show.el |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f5de8ae..eb5335f 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -833,8 +833,8 @@ any effects from previous calls to
   ;; If a small number of lines from the previous message are
   ;; visible, realign so that the top of the current message is at
   ;; the top of the screen.
-  (if (< (count-lines (window-start) (notmuch-show-message-top))
-next-screen-context-lines)
+  (if (<= (count-screen-lines (window-start) start-of-message)
+ next-screen-context-lines)
  (progn
(goto-char (notmuch-show-message-top))
(notmuch-show-message-adjust)))
-- 
1.7.0

Kudos! Also: +1 PGP!

[Sebastian Spaeth]

We were discussing on IRC whether decryption should be handled in
notmuch show --decrypt or in emacs and I had a quick look at what it
would take for emacs. Here is a snippet of code that outputs
"Good signature from 5585F58CC827A062 Sebastian Spaeth (Private
Communication)  (trust ultimate) created at
2010-04-26T14:27:07+0200 using DSA" in the minibuffer. I guess something
based on this could be used to parse the email and try to decrypt via gpg
and mark the signature status in the summary line:

(save-excursion 
  (let ((context (epg-make-context))
(signature "-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvVhpsACgkQVYX1jMgnoGJx4wCfXYKGdlc6HixqGwvWL4E+9t+M
QusAnA97NGdSLBFH6LeS3F8x3tAMd8td
=2nbO
-END PGP SIGNATURE-")
(signed-text "
teste
"))
(epg-verify-string context signature signed-text)
(let ((result (epg-context-result context)))
  (message (epg-verify-result-to-string (cdr (car result
  )))
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/80d94497/attachment.pgp>

Re: [PATCH] emacs: More DWIM when editing messages

[Dirk Hohndel]

On Mon, 26 Apr 2010 10:28:33 -0700, Carl Worth  wrote:
> On Mon, 26 Apr 2010 09:31:49 -0700, Dirk Hohndel  
> wrote:
> > On Mon, 26 Apr 2010 15:01:25 +0100, David Edmondson  wrote:
> > > For composing new messages and forwarding, leave the cursor on the
> > > 'To:' field. For replies, leave the cursor at the start of the
> > > body. In all cases, mark the buffer as not modified so that the user
> > > is not prompted if she decides to immediately kill the buffer.
> > 
> > YES! Brilliant. I didn't realize how much I wanted it till you sent
> > this. Carl, please include in 0.3
> 
> Agreed! This is *so* pleasant.
> 
> Thanks, David! This is pushed.

And here is the promised fix to get signature in the correct spot:

>From cbd9c96450f6481433877410bcf075d482b4be1b Mon Sep 17 00:00:00 2001
From: Dirk Hohndel 
Date: Mon, 26 Apr 2010 10:41:49 -0700
Subject: [PATCH] Put signatures at the very end of the message

The existing code inserts the signature before inserting the message
body (which it puts at the very end of the buffer - therefore AFTER
the signature). This little snippet makes us search backwards and
insert the message body before a signature, if it exists.

This also fixes a small indentation issue in David's code.

Signed-off-by: Dirk Hohndel 
---
 emacs/notmuch-mua.el |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index c7a9aee..9fbb94a 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -98,11 +98,16 @@ list."
  collect header)))
 (message-sort-headers)
 (message-hide-headers)
+;; insert the message body - but put it in front of the signature
+;; if one is present
 (goto-char (point-max))
+(if (re-search-backward "-- " nil t)
+ (forward-line -1)
+  (goto-char (point-max)))
 (insert body))
-(set-buffer-modified-p nil)
+  (set-buffer-modified-p nil)
 
-(message-goto-body))
+  (message-goto-body))
 
 (defun notmuch-mua-forward-message ()
   (message-forward)
-- 
1.6.6.1



-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: More DWIM when editing messages

[Dirk Hohndel]

On Mon, 26 Apr 2010 10:28:33 -0700, Carl Worth  wrote:
> On Mon, 26 Apr 2010 09:31:49 -0700, Dirk Hohndel  
> wrote:
> > On Mon, 26 Apr 2010 15:01:25 +0100, David Edmondson  wrote:
> > > For composing new messages and forwarding, leave the cursor on the
> > > 'To:' field. For replies, leave the cursor at the start of the
> > > body. In all cases, mark the buffer as not modified so that the user
> > > is not prompted if she decides to immediately kill the buffer.
> > 
> > YES! Brilliant. I didn't realize how much I wanted it till you sent
> > this. Carl, please include in 0.3
> 
> Agreed! This is *so* pleasant.
> 
> Thanks, David! This is pushed.

This appears not to have gone out??? Must be that weird MUA that I'm
using...

>From cbd9c96450f6481433877410bcf075d482b4be1b Mon Sep 17 00:00:00 2001
From: Dirk Hohndel 
Date: Mon, 26 Apr 2010 10:41:49 -0700
Subject: [PATCH] Put signatures at the very end of the message

The existing code inserts the signature before inserting the message
body (which it puts at the very end of the buffer - therefore AFTER
the signature). This little snippet makes us search backwards and
insert the message body before a signature, if it exists.

Signed-off-by: Dirk Hohndel 
---
 emacs/notmuch-mua.el |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index c7a9aee..9fbb94a 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -98,11 +98,16 @@ list."
  collect header)))
 (message-sort-headers)
 (message-hide-headers)
+;; insert the message body - but put it in front of the signature
+;; if one is present
 (goto-char (point-max))
+(if (re-search-backward "-- " nil t)
+ (forward-line -1)
+  (goto-char (point-max)))
 (insert body))
-(set-buffer-modified-p nil)
+  (set-buffer-modified-p nil)
 
-(message-goto-body))
+  (message-goto-body))
 
 (defun notmuch-mua-forward-message ()
   (message-forward)
-- 
1.6.6.1



-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: More DWIM when editing messages

[Dirk Hohndel]

On Mon, 26 Apr 2010 10:28:33 -0700, Carl Worth  wrote:
> On Mon, 26 Apr 2010 09:31:49 -0700, Dirk Hohndel  
> wrote:
> > On Mon, 26 Apr 2010 15:01:25 +0100, David Edmondson  wrote:
> > > For composing new messages and forwarding, leave the cursor on the
> > > 'To:' field. For replies, leave the cursor at the start of the
> > > body. In all cases, mark the buffer as not modified so that the user
> > > is not prompted if she decides to immediately kill the buffer.
> > 
> > YES! Brilliant. I didn't realize how much I wanted it till you sent
> > this. Carl, please include in 0.3
> 
> Agreed! This is *so* pleasant.
> 
> Thanks, David! This is pushed.

This appears not to have gone out??? Must be that weird MUA that I'm
using...

>From cbd9c96450f6481433877410bcf075d482b4be1b Mon Sep 17 00:00:00 2001
From: Dirk Hohndel 
Date: Mon, 26 Apr 2010 10:41:49 -0700
Subject: [PATCH] Put signatures at the very end of the message

The existing code inserts the signature before inserting the message
body (which it puts at the very end of the buffer - therefore AFTER
the signature). This little snippet makes us search backwards and
insert the message body before a signature, if it exists.

Signed-off-by: Dirk Hohndel 
---
 emacs/notmuch-mua.el |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index c7a9aee..9fbb94a 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -98,11 +98,16 @@ list."
  collect header)))
 (message-sort-headers)
 (message-hide-headers)
+;; insert the message body - but put it in front of the signature
+;; if one is present
 (goto-char (point-max))
+(if (re-search-backward "-- " nil t)
+ (forward-line -1)
+  (goto-char (point-max)))
 (insert body))
-(set-buffer-modified-p nil)
+  (set-buffer-modified-p nil)

-(message-goto-body))
+  (message-goto-body))

 (defun notmuch-mua-forward-message ()
   (message-forward)
-- 
1.6.6.1



-- 
Dirk Hohndel
Intel Open Source Technology Center

[PATCH] emacs: More DWIM when editing messages

[David Edmondson]

For composing new messages and forwarding, leave the cursor on the
'To:' field. For replies, leave the cursor at the start of the
body. In all cases, mark the buffer as not modified so that the user
is not prompted if she decides to immediately kill the buffer.
---
 emacs/notmuch-mua.el |   32 +++-
 1 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index bca20db..c7a9aee 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -98,21 +98,24 @@ list."
  collect header)))
 (message-sort-headers)
 (message-hide-headers)
-(save-excursion
-  (goto-char (point-max))
-  (insert body))
-(set-buffer-modified-p nil)))
+(goto-char (point-max))
+(insert body))
+(set-buffer-modified-p nil)
+
+(message-goto-body))

 (defun notmuch-mua-forward-message ()
   (message-forward)
-  (save-excursion
-(when notmuch-mua-user-agent-function
-  (let ((user-agent (funcall notmuch-mua-user-agent-function)))
-   (when (not (string= "" user-agent))
- (message-add-header (format "User-Agent: %s" user-agent)
-(message-sort-headers)
-(message-hide-headers))
-  (set-buffer-modified-p nil))
+
+  (when notmuch-mua-user-agent-function
+(let ((user-agent (funcall notmuch-mua-user-agent-function)))
+  (when (not (string= "" user-agent))
+   (message-add-header (format "User-Agent: %s" user-agent)
+  (message-sort-headers)
+  (message-hide-headers)
+  (set-buffer-modified-p nil)
+
+  (message-goto-to))

 (defun notmuch-mua-mail (&optional to subject other-headers continue
   switch-function yank-action send-actions)
@@ -126,7 +129,10 @@ list."
   (message-mail to subject other-headers continue
switch-function yank-action send-actions)
   (message-sort-headers)
-  (message-hide-headers))
+  (message-hide-headers)
+  (set-buffer-modified-p nil)
+
+  (message-goto-to))

 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
-- 
1.7.0

Re: For 0.3 - cleaned up patches rebased on origin/master

[Carl Worth]

On Mon, 26 Apr 2010 12:58:33 -0700, Dirk Hohndel  wrote:
> based on your comment on IRC I have rebased this patch to the current
> origin/master and split it in two parts, one that makes the Received: header
> special when getting headers from a message file, and one that changes the
> heuristic by which we guess the best From: header. This passes the tests that
> have been committed last week.

Fantastic. All pushed.

The test cases give me the freedom to rework the style of these patches
as I want, for example to use talloc more to avoid lots of

free (temporary);
return result;

And I can do that with the comfort of trusting the test suite to catch
any mistakes I introduce. Whether otherwise, I would be less daring to
touch it and would have pushed for more style changes before merging.

-Carl

-- 
carl.d.wo...@intel.com


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

For 0.3 - cleaned up patches rebased on origin/master

[Carl Worth]

On Mon, 26 Apr 2010 12:58:33 -0700, Dirk Hohndel  
wrote:
> based on your comment on IRC I have rebased this patch to the current
> origin/master and split it in two parts, one that makes the Received: header
> special when getting headers from a message file, and one that changes the
> heuristic by which we guess the best From: header. This passes the tests that
> have been committed last week.

Fantastic. All pushed.

The test cases give me the freedom to rework the style of these patches
as I want, for example to use talloc more to avoid lots of

free (temporary);
return result;

And I can do that with the comfort of trusting the test suite to catch
any mistakes I introduce. Whether otherwise, I would be less daring to
touch it and would have pushed for more style changes before merging.

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/7e9442ce/attachment.pgp>

[PATCH] emacs: Add more functions to clean up text/plain parts

[David Edmondson]

Add:
- notmuch-wash-wrap-long-lines: Wrap lines longer than the width of
  the current window whilst maintaining any citation prefix.
- notmuch-wash-tidy-citations: Tidy up citations by:
  - compress repeated otherwise blank citation lines,
  - remove otherwise blank citation lines at the head and tail of a
citation,
- notmuch-wash-elide-blank-lines: Compress repeated blank lines and
  remove leading and trailing blank lines.

None of these is enabled by default - add them to
`notmuch-show-insert-text/plain-hook' to use.
---

Another attempt :-)

- Functions renamed to be clearer about what they do,
- Function documentation both more concise (for display in customisation
  buffers) and more complete,
- Interaction of long line wrapping and `word-wrap' improved,
- Push `notmuch-show-pretty-hook' functions that everyone will use
  directly into the code, thus avoiding the naming dilemma.

 emacs/Makefile.local  |3 +-
 emacs/coolj.el|  145 +
 emacs/notmuch-show.el |   28 +++---
 emacs/notmuch-wash.el |   84 -
 4 files changed, 248 insertions(+), 12 deletions(-)
 create mode 100644 emacs/coolj.el

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index 7537c3d..ce37ca2 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -9,7 +9,8 @@ emacs_sources := \
$(dir)/notmuch-wash.el \
$(dir)/notmuch-hello.el \
$(dir)/notmuch-mua.el \
-   $(dir)/notmuch-address.el
+   $(dir)/notmuch-address.el \
+   $(dir)/coolj.el

 emacs_images := \
$(dir)/notmuch-logo.png
diff --git a/emacs/coolj.el b/emacs/coolj.el
new file mode 100644
index 000..60af60a
--- /dev/null
+++ b/emacs/coolj.el
@@ -0,0 +1,145 @@
+;;; coolj.el --- automatically wrap long lines  -*- coding:utf-8 -*-
+
+;; Copyright (C) 2000, 2001, 2004, 2005, 2006, 2007, 2008, 2009 Free Software 
Foundation, Inc.
+
+;; Authors:Kai Grossjohann 
+;; Alex Schroeder 
+;; Chong Yidong 
+;; Maintainer: David Edmondson 
+;; Keywords: convenience, wp
+
+;; This file is not part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see .
+
+;;; Commentary:
+
+;;; This is a simple derivative of some functionality from
+;;; `longlines.el'. The key difference is that this version will
+;;; insert a prefix at the head of each wrapped line. The prefix is
+;;; calculated from the originating long line.
+
+;;; No minor-mode is provided, the caller is expected to call
+;;; `coolj-wrap-region' to wrap the region of interest.
+
+;;; Code:
+
+(defgroup coolj nil
+  "Wrapping of long lines with prefix."
+  :group 'fill)
+
+(defcustom coolj-wrap-follows-window-size t
+  "Non-nil means wrap text to the window size.
+Otherwise respect `fill-column'."
+  :group 'coolj
+  :type 'boolean)
+
+(defcustom coolj-line-prefix-regexp "^\\(>+ \\)*"
+  "Regular expression that matches line prefixes."
+  :group 'coolj
+  :type 'regexp)
+
+(defvar coolj-wrap-point nil)
+
+(make-variable-buffer-local 'coolj-wrap-point)
+
+(defun coolj-determine-prefix ()
+  "Determine the prefix for the current line."
+  (save-excursion
+(beginning-of-line)
+(if (re-search-forward coolj-line-prefix-regexp nil t)
+   (buffer-substring (match-beginning 0) (match-end 0))
+  "")))
+
+(defun coolj-wrap-buffer ()
+  "Wrap the current buffer."
+  (coolj-wrap-region (point-min) (point-max)))
+
+(defun coolj-wrap-region (beg end)
+  "Wrap each successive line, starting with the line before BEG.
+Stop when we reach lines after END that don't need wrapping, or the
+end of the buffer."
+  (setq fill-column (if coolj-wrap-follows-window-size
+   (window-width)
+ fill-column))
+  (let ((mod (buffer-modified-p)))
+(setq coolj-wrap-point (point))
+(goto-char beg)
+(forward-line -1)
+;; Two successful coolj-wrap-line's in a row mean successive
+;; lines don't need wrapping.
+(while (null (and (coolj-wrap-line)
+ (or (eobp)
+ (and (>= (point) end)
+  (coolj-wrap-line))
+(goto-char coolj-wrap-point)
+(set-buffer-modified-p mod)))
+
+(defun coolj-wrap-line ()
+  "If the current line needs to be wrapped, wrap it and return nil.
+If wrapping is performed, point remains on the line.  If the line does
+not need to 

[wiki] emacstips: Add GPG signing tip

[Sebastian Spaeth]

I just added a short blurb to the wiki page stating how to sign/encrypt
outgoing mail conveniently. Please review and improve:
http://notmuchmail.org/emacstips/#sign_messages_gpg

Sebastian
P.S. Do note that this mail should be signed if things are working out :)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/afe5a840/attachment.pgp>

Re: [PATCH v3 1/4] Add elisp file for FCC to maildir solution

[Carl Worth]

On Mon, 26 Apr 2010 10:23:15 +0200, Sebastian Spaeth  
wrote:
>  The patch series needed rebasing as it conflicts now with some of the
>  notmuch-hello and notmuch-mua additions. Also, I integrated Dirk's proposal
>  to use assoc-string which makes the address lookup case-insensitive.

I've merged this now and pushed it out.

I did have some problems trying to use it, which would have prevented me
From pushing it out, I think, except that it's disabled by default.

But I would actually prefer to have it enabled by default. Here are
some of the things I'd like to see changed to let us do that:

  * Insert a '/' if necessary when concatenating message-directory to
the configured directory.

I was getting "/home/cworth/mailsent" instead of
"/home/cworth/mail/sent" here.

  * Make the Fcc header visible when composing a message

Otherwise it's hard to know if the Fcc code is actually getting
invoked.

And we do enough magic here, (the above concatenation, and also
the a-list matching), that we should let the user see the
result. This would also allow the user to modify the Fcc if
necessary.

  * Fix code to create directories as necessary

If I manually added an Fcc header before sending, (even by just
calling `notmuch-fcc-header-setup'), there is some prompting
about creating the directory. But I don't get this when I just
send a message (hoping that the Fcc stuff will kick in and do
it's job).

But even if I just point to a directory, (without cur, new, and
tmp), it complains about "not a regular file" or something. I'd
rather just have it create the directories it needs.

I found by trial-and-error that if I do create the directory,
*and* create the cur, new, and tmp sub-directories then the Fcc
actually works.

  * Fix to not depend on message-directory variable

I think a relative directory specification should be interpreted
with respect to the notmuch mail directory. It's currently a
little "tricky" for emacs code to get at that since we don't
have a command-line interface for querying configuration. [Does
emacs have a parser for this style of configuration file?]

The quick fix is probably to accept only an absolute path and
fixup the documentation. Then if someone wants to do the
additional work to support a directory relative to the notmuch
mail directory, then that could be done in the future.

With the above in place, I'd be happy to have this all enabled by
default. (But I guess we can't do that until we *do* have support for a
relative path since notmuch won't be able to construct an absolute path
without configuration.)

Then, we can remove the Bcc from the "notmuch reply" output. And we can
add an option for people who would prefer Bcc (or even Cc as keithp
wants) instead of Fcc.

That will all be later than 0.3 though.

-Carl


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

[PATCH v3 1/4] Add elisp file for FCC to maildir solution

[Carl Worth]

On Mon, 26 Apr 2010 10:23:15 +0200, Sebastian Spaeth  
wrote:
>  The patch series needed rebasing as it conflicts now with some of the
>  notmuch-hello and notmuch-mua additions. Also, I integrated Dirk's proposal
>  to use assoc-string which makes the address lookup case-insensitive.

I've merged this now and pushed it out.

I did have some problems trying to use it, which would have prevented me

[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[Jameson Rollins]

On Mon, 26 Apr 2010 10:16:42 -0700, Carl Worth  wrote:
> What do you think? This will give new users the ability to just type a
> search string as their first interaction. Users with a little more
> experience, (enough to have saved a search), will have easier access to
> those, and will not have the search bar interfering with keybindings.

What about advanced users?  I really want my notmuch front page to just
be a particular saved search.  The notmuch-hello looks neat, but I don't
really see myself ever using it, since I can access all the
functionality I need already.  All I really want from a front page is
the main search that I look at all the time ("tag:inbox and not
tag:deleted"), have it *not* close if I accidentally hit 'q', and a way
to pop back to it from wherever I am.  Could we make it configurable so
that the front page is either the hello page, or the special search page
I describe?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/576826bf/attachment-0001.pgp>

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[Sebastian Spaeth]

On 2010-04-26, David Edmondson wrote:
> M-n to move forward in the list, M-p to move backwards (including into
> any history you have accrued).

Alternatively, some of us have that weird new invention on their
keyboards called "arrow keys" ;-)

[PATCH] emacs: Fix `notmuch-search-insert-field'

[David Edmondson]

Compare the formatted version of the authors with the formatted sample
string rather than the un-formatted authors with the formatted sample
string.
---

Carl, please pull this in for 0.3. The previous fix didn't work
correctly when the authors string was one character shorter than the
length specified in the format string (presuming that the format
string is broadly unchanged from the default).

 emacs/notmuch.el |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 378c004..eecff23 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -582,11 +582,13 @@ matching will be applied."
((string-equal field "count")
 (insert (format (cdr (assoc field notmuch-search-result-format)) count)))
((string-equal field "authors")
-(insert (let ((sample (format (cdr (assoc field 
notmuch-search-result-format)) "")))
- (if (> (length authors)
-(length sample))
- (concat (substring authors 0 (- (length sample) 4)) "... ")
-   (format (cdr (assoc field notmuch-search-result-format)) 
authors)
+(insert (let* ((format-string (cdr (assoc field 
notmuch-search-result-format)))
+  (formatted-sample (format format-string ""))
+  (formatted-authors (format format-string authors)))
+ (if (> (length formatted-authors)
+(length formatted-sample))
+ (concat (substring authors 0 (- (length formatted-sample) 4)) 
"... ")
+   formatted-authors
((string-equal field "subject")
 (insert (format (cdr (assoc field notmuch-search-result-format)) subject)))
((string-equal field "tags")
-- 
1.7.0

[PATCH 2/2] Rearchitect From: header guessing code for replies

[Dirk Hohndel]

We want to be able to correctly guess the best From: header to use when
replying to emails. This is what we are looking at now:
 1 is one of the users' mail addresses in the To: or Cc: header
 2 check for an Envelope-to: header
 3 check for an X-Original-To: header
 4 check for a (for ) clause in Received: headers
 5 check for the domain part of known email addresses in the
  'by' part of Received headers
 6 fall back to the primary email address

This patch changes the algorithm for steps 2-5 of this process. Prior to
this patch we had a first attempt to implement only step 5 - but this
broke in many email setups where mail delivery to the local machine added
additional Received: lines.
Steps 2-4 are new, step 5 now analyzes the concatenated Received: header
(this was in the previous patch) to do this analysis.

Signed-off-by: Dirk Hohndel 
---
 notmuch-reply.c |  125 +-
 1 files changed, 95 insertions(+), 30 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7c43146..333e945 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -311,36 +311,100 @@ add_recipients_from_message (GMimeMessage *reply,
 static const char *
 guess_from_received_header (notmuch_config_t *config, notmuch_message_t 
*message)
 {
-const char *received,*primary;
-char **other;
-char *by,*mta,*ptr,*token;
+const char *received,*primary,*by;
+char **other,*tohdr;
+char *mta,*ptr,*token;
 char *domain=NULL;
 char *tld=NULL;
 const char *delim=". \t";
 size_t i,other_len;
 
+const char *to_headers[] = {"Envelope-to", "X-Original-To"};
+
+primary = notmuch_config_get_user_primary_email (config);
+other = notmuch_config_get_user_other_email (config, &other_len);
+
+/* sadly, there is no standard way to find out to which email
+ * address a mail was delivered - what is in the headers depends
+ * on the MTAs used along the way. So we are trying a number of
+ * heuristics which hopefully will answer this question.
+
+ * We only got here if none of the users email addresses are in
+ * the To: or Cc: header. From here we try the following in order:
+ * 1) check for an Envelope-to: header
+ * 2) check for an X-Original-To: header
+ * 3) check for a (for ) clause in Received: headers
+ * 4) check for the domain part of known email addresses in the
+ *'by' part of Received headers
+ * If none of these work, we give up and return NULL
+ */
+for (i = 0; i < sizeof(to_headers)/sizeof(*to_headers); i++) {
+   tohdr = xstrdup(notmuch_message_get_header (message, to_headers[i]));
+   if (tohdr && *tohdr) {
+   /* tohdr is potentialy a list of email addresses, so here we
+* check if one of the email addresses is a substring of tohdr
+*/
+   if (strcasestr(tohdr, primary)) {
+   free(tohdr);
+   return primary;
+   }
+   for (i = 0; i < other_len; i++)
+   if (strcasestr (tohdr, other[i])) {
+   free(tohdr);
+   return other[i];
+   }
+   free(tohdr);
+   }
+}
+
+/* We get the concatenated Received: headers and search from the
+ * front (last Received: header added) and try to extract from
+ * them indications to which email address this message was
+ * delivered.
+ * The Received: header is special in our get_header function
+ * and is always concated.
+ */
 received = notmuch_message_get_header (message, "received");
 if (received == NULL)
return NULL;
 
-by = strstr (received, " by ");
-if (by && *(by+4)) {
-   /* sadly, the format of Received: headers is a bit inconsistent,
-* depending on the MTA used. So we try to extract just the MTA
-* here by removing leading whitespace and assuming that the MTA
-* name ends at the next whitespace
-* we test for *(by+4) to be non-'\0' to make sure there's something
-* there at all - and then assume that the first whitespace delimited
-* token that follows is the last receiving server
+/* First we look for a " for " in the received
+ * header
+ */
+ptr = strstr (received, " for ");
+if (ptr) {
+   /* the text following is potentialy a list of email addresses,
+* so again we check if one of the email addresses is a
+* substring of ptr
 */
-   mta = strdup (by+4);
-   if (mta == NULL)
-   return NULL;
+   if (strcasestr(ptr, primary)) {
+   return primary;
+   }
+   for (i = 0; i < other_len; i++)
+   if (strcasestr (ptr, other[i])) {
+   return other[i];
+   }
+}
+/* Finally, we parse all the " by MTA ..." headers to guess the
+ * email address that this was originally delivered to.
+ * We extract just the MTA here by removing leading whitespace and

[PATCH 1/2] Make Received: header special in notmuch_message_file_get_header

[Dirk Hohndel]

With this patch the Received: header becomes special in the way
we treat headers - this is the only header for which we concatenate
all the instances we find (instead of just returning the first one).

This will be used in the From guessing code for replies as we need to
be able to walk ALL of the Received: headers in a message to have a
good chance to guess which mailbox this email was delivered to.

Signed-off-by: Dirk Hohndel 
---
 lib/message-file.c|   58 ++---
 lib/notmuch-private.h |3 ++
 2 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/lib/message-file.c b/lib/message-file.c
index 0c152a3..7722832 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -209,17 +209,24 @@ copy_header_unfolding (header_value_closure_t *value,
 
 /* As a special-case, a value of NULL for header_desired will force
  * the entire header to be parsed if it is not parsed already. This is
- * used by the _notmuch_message_file_get_headers_end function. */
+ * used by the _notmuch_message_file_get_headers_end function.
+ * Another special case is the Received: header. For this header we
+ * want to concatenate all instances of the header instead of just
+ * hashing the first instance as we use this when analyzing the path
+ * the mail has taken from sender to recipient.
+ */
 const char *
 notmuch_message_file_get_header (notmuch_message_file_t *message,
 const char *header_desired)
 {
 int contains;
-char *header, *decoded_value;
+char *header, *decoded_value, *header_sofar, *combined_header;
 const char *s, *colon;
-int match;
+int match, newhdr, hdrsofar, is_received;
 static int initialized = 0;
 
+is_received = (strcmp(header_desired,"received") == 0);
+
 if (! initialized) {
g_mime_init (0);
initialized = 1;
@@ -312,22 +319,39 @@ notmuch_message_file_get_header (notmuch_message_file_t 
*message,
 
NEXT_HEADER_LINE (&message->value);
 
-   if (header_desired == 0)
+   if (header_desired == NULL)
match = 0;
else
match = (strcasecmp (header, header_desired) == 0);
 
decoded_value = g_mime_utils_header_decode_text (message->value.str);
-   if (g_hash_table_lookup (message->headers, header) == NULL) {
-   /* Only insert if we don't have a value for this header, yet.
-* This way we always return the FIRST instance of any header
-* we search for
-* FIXME: we should be returning ALL instances of a header
-*or at least provide a way to iterate over them
-*/
-   g_hash_table_insert (message->headers, header, decoded_value);
+   header_sofar = (char *)g_hash_table_lookup (message->headers, header);
+   /* we treat the Received: header special - we want to concat ALL of 
+* the Received: headers we encounter.
+* for everything else we return the first instance of a header */
+   if (is_received) {
+   if (header_sofar == NULL) {
+   /* first Received: header we encountered; just add it */
+   g_hash_table_insert (message->headers, header, decoded_value);
+   } else {
+   /* we need to add the header to those we already collected */
+   newhdr = strlen(decoded_value);
+   hdrsofar = strlen(header_sofar);
+   combined_header = xmalloc(hdrsofar + newhdr + 2);
+   strncpy(combined_header,header_sofar,hdrsofar);
+   *(combined_header+hdrsofar) = ' ';
+   strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+   g_hash_table_insert (message->headers, header, combined_header);
+   }
+   } else {
+   if (header_sofar == NULL) {
+   /* Only insert if we don't have a value for this header, yet. */
+   g_hash_table_insert (message->headers, header, decoded_value);
+   }
}
-   if (match)
+   /* if we found a match we can bail - unless of course we are
+* collecting all the Received: headers */
+   if (match && !is_received)
return decoded_value;
 }
 
@@ -347,6 +371,14 @@ notmuch_message_file_get_header (notmuch_message_file_t 
*message,
message->value.len = 0;
 }
 
+/* For the Received: header we actually might end up here even
+ * though we found the header (as we force continued parsing
+ * in that case). So let's check if that's the header we were
+ * looking for and return the value that we found (if any)
+ */
+if (is_received)
+   return (char *)g_hash_table_lookup (message->headers, "received");
+
 /* We've parsed all headers and never found the one we're looking
  * for. It's probably just not there, but let's check that we
  * didn't make a mistake preventing us from seeing it. */
diff --git a/lib/notmuch-private.h b/lib/notmuch-

For 0.3 - cleaned up patches rebased on origin/master

[Dirk Hohndel]

Carl, 

based on your comment on IRC I have rebased this patch to the current
origin/master and split it in two parts, one that makes the Received: header
special when getting headers from a message file, and one that changes the
heuristic by which we guess the best From: header. This passes the tests that
have been committed last week.

I tried to get git send-email to make this a reply to the previous version of
this patch...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/2] Rearchitect From: header guessing code for replies

[Dirk Hohndel]

We want to be able to correctly guess the best From: header to use when
replying to emails. This is what we are looking at now:
 1 is one of the users' mail addresses in the To: or Cc: header
 2 check for an Envelope-to: header
 3 check for an X-Original-To: header
 4 check for a (for ) clause in Received: headers
 5 check for the domain part of known email addresses in the
  'by' part of Received headers
 6 fall back to the primary email address

This patch changes the algorithm for steps 2-5 of this process. Prior to
this patch we had a first attempt to implement only step 5 - but this
broke in many email setups where mail delivery to the local machine added
additional Received: lines.
Steps 2-4 are new, step 5 now analyzes the concatenated Received: header
(this was in the previous patch) to do this analysis.

Signed-off-by: Dirk Hohndel 
---
 notmuch-reply.c |  125 +-
 1 files changed, 95 insertions(+), 30 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7c43146..333e945 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -311,36 +311,100 @@ add_recipients_from_message (GMimeMessage *reply,
 static const char *
 guess_from_received_header (notmuch_config_t *config, notmuch_message_t 
*message)
 {
-const char *received,*primary;
-char **other;
-char *by,*mta,*ptr,*token;
+const char *received,*primary,*by;
+char **other,*tohdr;
+char *mta,*ptr,*token;
 char *domain=NULL;
 char *tld=NULL;
 const char *delim=". \t";
 size_t i,other_len;

+const char *to_headers[] = {"Envelope-to", "X-Original-To"};
+
+primary = notmuch_config_get_user_primary_email (config);
+other = notmuch_config_get_user_other_email (config, &other_len);
+
+/* sadly, there is no standard way to find out to which email
+ * address a mail was delivered - what is in the headers depends
+ * on the MTAs used along the way. So we are trying a number of
+ * heuristics which hopefully will answer this question.
+
+ * We only got here if none of the users email addresses are in
+ * the To: or Cc: header. From here we try the following in order:
+ * 1) check for an Envelope-to: header
+ * 2) check for an X-Original-To: header
+ * 3) check for a (for ) clause in Received: headers
+ * 4) check for the domain part of known email addresses in the
+ *'by' part of Received headers
+ * If none of these work, we give up and return NULL
+ */
+for (i = 0; i < sizeof(to_headers)/sizeof(*to_headers); i++) {
+   tohdr = xstrdup(notmuch_message_get_header (message, to_headers[i]));
+   if (tohdr && *tohdr) {
+   /* tohdr is potentialy a list of email addresses, so here we
+* check if one of the email addresses is a substring of tohdr
+*/
+   if (strcasestr(tohdr, primary)) {
+   free(tohdr);
+   return primary;
+   }
+   for (i = 0; i < other_len; i++)
+   if (strcasestr (tohdr, other[i])) {
+   free(tohdr);
+   return other[i];
+   }
+   free(tohdr);
+   }
+}
+
+/* We get the concatenated Received: headers and search from the
+ * front (last Received: header added) and try to extract from
+ * them indications to which email address this message was
+ * delivered.
+ * The Received: header is special in our get_header function
+ * and is always concated.
+ */
 received = notmuch_message_get_header (message, "received");
 if (received == NULL)
return NULL;

-by = strstr (received, " by ");
-if (by && *(by+4)) {
-   /* sadly, the format of Received: headers is a bit inconsistent,
-* depending on the MTA used. So we try to extract just the MTA
-* here by removing leading whitespace and assuming that the MTA
-* name ends at the next whitespace
-* we test for *(by+4) to be non-'\0' to make sure there's something
-* there at all - and then assume that the first whitespace delimited
-* token that follows is the last receiving server
+/* First we look for a " for " in the received
+ * header
+ */
+ptr = strstr (received, " for ");
+if (ptr) {
+   /* the text following is potentialy a list of email addresses,
+* so again we check if one of the email addresses is a
+* substring of ptr
 */
-   mta = strdup (by+4);
-   if (mta == NULL)
-   return NULL;
+   if (strcasestr(ptr, primary)) {
+   return primary;
+   }
+   for (i = 0; i < other_len; i++)
+   if (strcasestr (ptr, other[i])) {
+   return other[i];
+   }
+}
+/* Finally, we parse all the " by MTA ..." headers to guess the
+ * email address that this was originally delivered to.
+ * We extract just the MTA here by removing leading whitespace and
+

[PATCH 1/2] Make Received: header special in notmuch_message_file_get_header

[Dirk Hohndel]

With this patch the Received: header becomes special in the way
we treat headers - this is the only header for which we concatenate
all the instances we find (instead of just returning the first one).

This will be used in the From guessing code for replies as we need to
be able to walk ALL of the Received: headers in a message to have a
good chance to guess which mailbox this email was delivered to.

Signed-off-by: Dirk Hohndel 
---
 lib/message-file.c|   58 ++---
 lib/notmuch-private.h |3 ++
 2 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/lib/message-file.c b/lib/message-file.c
index 0c152a3..7722832 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -209,17 +209,24 @@ copy_header_unfolding (header_value_closure_t *value,

 /* As a special-case, a value of NULL for header_desired will force
  * the entire header to be parsed if it is not parsed already. This is
- * used by the _notmuch_message_file_get_headers_end function. */
+ * used by the _notmuch_message_file_get_headers_end function.
+ * Another special case is the Received: header. For this header we
+ * want to concatenate all instances of the header instead of just
+ * hashing the first instance as we use this when analyzing the path
+ * the mail has taken from sender to recipient.
+ */
 const char *
 notmuch_message_file_get_header (notmuch_message_file_t *message,
 const char *header_desired)
 {
 int contains;
-char *header, *decoded_value;
+char *header, *decoded_value, *header_sofar, *combined_header;
 const char *s, *colon;
-int match;
+int match, newhdr, hdrsofar, is_received;
 static int initialized = 0;

+is_received = (strcmp(header_desired,"received") == 0);
+
 if (! initialized) {
g_mime_init (0);
initialized = 1;
@@ -312,22 +319,39 @@ notmuch_message_file_get_header (notmuch_message_file_t 
*message,

NEXT_HEADER_LINE (&message->value);

-   if (header_desired == 0)
+   if (header_desired == NULL)
match = 0;
else
match = (strcasecmp (header, header_desired) == 0);

decoded_value = g_mime_utils_header_decode_text (message->value.str);
-   if (g_hash_table_lookup (message->headers, header) == NULL) {
-   /* Only insert if we don't have a value for this header, yet.
-* This way we always return the FIRST instance of any header
-* we search for
-* FIXME: we should be returning ALL instances of a header
-*or at least provide a way to iterate over them
-*/
-   g_hash_table_insert (message->headers, header, decoded_value);
+   header_sofar = (char *)g_hash_table_lookup (message->headers, header);
+   /* we treat the Received: header special - we want to concat ALL of 
+* the Received: headers we encounter.
+* for everything else we return the first instance of a header */
+   if (is_received) {
+   if (header_sofar == NULL) {
+   /* first Received: header we encountered; just add it */
+   g_hash_table_insert (message->headers, header, decoded_value);
+   } else {
+   /* we need to add the header to those we already collected */
+   newhdr = strlen(decoded_value);
+   hdrsofar = strlen(header_sofar);
+   combined_header = xmalloc(hdrsofar + newhdr + 2);
+   strncpy(combined_header,header_sofar,hdrsofar);
+   *(combined_header+hdrsofar) = ' ';
+   strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+   g_hash_table_insert (message->headers, header, combined_header);
+   }
+   } else {
+   if (header_sofar == NULL) {
+   /* Only insert if we don't have a value for this header, yet. */
+   g_hash_table_insert (message->headers, header, decoded_value);
+   }
}
-   if (match)
+   /* if we found a match we can bail - unless of course we are
+* collecting all the Received: headers */
+   if (match && !is_received)
return decoded_value;
 }

@@ -347,6 +371,14 @@ notmuch_message_file_get_header (notmuch_message_file_t 
*message,
message->value.len = 0;
 }

+/* For the Received: header we actually might end up here even
+ * though we found the header (as we force continued parsing
+ * in that case). So let's check if that's the header we were
+ * looking for and return the value that we found (if any)
+ */
+if (is_received)
+   return (char *)g_hash_table_lookup (message->headers, "received");
+
 /* We've parsed all headers and never found the one we're looking
  * for. It's probably just not there, but let's check that we
  * didn't make a mistake preventing us from seeing it. */
diff --git a/lib/notmuch-private.h b/lib/notmuch-private

For 0.3 - cleaned up patches rebased on origin/master

[Dirk Hohndel]

Carl, 

based on your comment on IRC I have rebased this patch to the current
origin/master and split it in two parts, one that makes the Received: header
special when getting headers from a message file, and one that changes the
heuristic by which we guess the best From: header. This passes the tests that
have been committed last week.

I tried to get git send-email to make this a reply to the previous version of
this patch...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

[PATCH] emacs: Hide the "User-Agent:" when composing messages

[David Edmondson]

Add a list of headers to those hidden by `message-mode' when
composing. By default the list includes only "User-Agent:".
---
 emacs/notmuch-mua.el |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 004b50a..bca20db 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -41,6 +41,12 @@
 notmuch-mua-user-agent-notmuch
 notmuch-mua-user-agent-emacs))

+(defcustom notmuch-mua-hidden-headers '("^User-Agent:")
+  "Headers that are added to the `message-mode' hidden headers
+list."
+  :group 'notmuch
+  :type '(repeat string))
+
 ;;

 (defun notmuch-mua-user-agent-full ()
@@ -57,6 +63,13 @@
   "Generate a `User-Agent:' string suitable for notmuch."
   (concat "Emacs/" emacs-version " (" system-configuration ")"))

+(defun notmuch-mua-add-more-hidden-headers ()
+  "Add some headers to the list that are hidden by default."
+  (mapc (lambda (header)
+ (when (not (member header 'message-hidden-headers))
+   (push header message-hidden-headers)))
+   notmuch-mua-hidden-headers))
+
 (defun notmuch-mua-reply (query-string)
   (let (headers body)
 ;; This make assumptions about the output of `notmuch reply', but
@@ -134,6 +147,10 @@ simply runs the corresponding `message-mode' hook 
functions."
   'notmuch-mua-mail 'notmuch-mua-send-and-exit
   'notmuch-mua-kill-buffer 'notmuch-mua-send-hook)

+;; Add some more headers to the list that `message-mode' hides when
+;; composing a message.
+(notmuch-mua-add-more-hidden-headers)
+
 ;;

 (provide 'notmuch-mua)
-- 
1.7.0

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[David Edmondson]

On Mon, 26 Apr 2010 13:29:42 +0200, "Sebastian Spaeth"  wrote:
> On 2010-04-26, David Edmondson wrote:
> > M-n to move forward in the list, M-p to move backwards (including into
> > any history you have accrued).
> 
> Alternatively, some of us have that weird new invention on their
> keyboards called "arrow keys" ;-)

New-fangled nonsense!

> Cc: carl at ut.hh.sledj.net

Gosh, where did that come from? Looks as though I generated it
(ut.hh.sledj.net is my desktop machine)...

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

Wrapping up the 0.3 release

[David Edmondson]

On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth  wrote:
> Meanwhile, I'm aware of two regressions I'd like to see fixed before
> 0.3:
> 
>   * Reply is now splitting the window
> 
> We're copying the original message into the new reply buffer, so
> what's the advantage of splitting here?

Patch sent.

>   * Composing a new message with 'm' brings up headers in a scrambled
> order.
> 
> A minor point, but it would be nice to fix this.

Patch sent.

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

[PATCH] emacs: Sort headers when composing

[David Edmondson]

Always sort the headers in the message composition window.
---
 emacs/notmuch-mua.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index b69e31c..004b50a 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -112,6 +112,7 @@

   (message-mail to subject other-headers continue
switch-function yank-action send-actions)
+  (message-sort-headers)
   (message-hide-headers))

 (defun notmuch-mua-send-and-exit (&optional arg)
-- 
1.7.0

Some messages show only headers.

[Jameson Rollins]

On Mon, 26 Apr 2010 09:13:20 -0700, Dirk Hohndel  
wrote:
> I think Carl already pushed the fix.

Yes, he did, and it appears to have fixed the problem.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/1e545acb/attachment.pgp>

Kudos! Also: +1 PGP!

[Jameson Rollins]

On Mon, 26 Apr 2010 17:11:33 +0100, David Edmondson  wrote:
> multipart/signed really needs the re-worked JSON output so that the UI
> can know what is going on. It might be possible to kludge something
> together with the current output, but it will be awkward.

Actually the emacs UI is current using the JSON output, since the
bremner's reworking got merged a couple weeks ago.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/4164e112/attachment.pgp>

[PATCH] emacs: Suppress window creation when replying

[David Edmondson]

The buffer used to edit a reply should overlay the original
message. Encourage this by setting `same-window-regexps' locally.
---
 emacs/notmuch-mua.el |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 305275e..b69e31c 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -73,12 +73,16 @@
  (setq headers (mail-header-extract)
   (forward-line 1)
   (setq body (buffer-substring (point) (point-max
-(notmuch-mua-mail (mail-header 'to headers)
- (mail-header 'subject headers)
- (loop for header in headers
-   if (not (or (eq 'to (car header))
-   (eq 'subject (car header
-   collect header))
+(let
+   ;; Overlay the composition window on that being used to read
+   ;; the original message.
+   ((same-window-regexps '("\\*mail .*")))
+  (notmuch-mua-mail (mail-header 'to headers)
+   (mail-header 'subject headers)
+   (loop for header in headers
+ if (not (or (eq 'to (car header))
+ (eq 'subject (car header
+ collect header)))
 (message-sort-headers)
 (message-hide-headers)
 (save-excursion
-- 
1.7.0

[PATCH] test: Comment why we need to set TZ

[Michal Sojka]

---
 test/notmuch-test |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/test/notmuch-test b/test/notmuch-test
index 7082344..dc413f7 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -1,6 +1,10 @@
 #!/bin/bash
 set -e

+# Messages contain time/date values with time zone and notmuch
+# displays them converted to the local time zone. We need to set fixed
+# timezone here so that the output of the tests is always the same
+# without regard to the time zone of where the test suite is run.
 export TZ=UTC+8

 find_notmuch_binary ()
-- 
1.7.0.4

sort order regression

[Michal Sojka]

> Want to replay all the git test-suite commits other than any from the
> person with the missing ack? That should get us pretty close to the
> current state in git, would give us code we could use, and might even
> make it possible for us to submit improvements directly to the upstream
> git repository.
> 
> Should be a pretty simple "git rebase -i" or so and edit out the lines
> From the author of interest. (Simple, assuming it doesn't fall over
> completely due to conflicts.)

I do not fully understand what you propose here. You mean to reply the
commits from git repository into notmuch repository and then put your
relicensing patch on top of it?

We do not need the contribution with missing ack in notmuch test suite
since it is git specific.

> Just an idea anyway. I also understand if you don't have motivation to
> pursue this further. And we can just do our own "modularization" as we
> want new features.

The motivation is not the problem. I will only have less time for
notmuch in the upcomming two months.

-Michal

Unhandled Xapian exception

[David Edmondson]

On Sat, 24 Apr 2010 07:38:03 -0700, Carl Worth  wrote:
> Otherwise, we might want to start supporting more clever handling of the
> exception. For example, the high-level application might want to retry
> an operation if it fails due to a DatabaseModified exception.

This is what I would like to do (and thought that I was!) in notsync.

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

[PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.

[David Edmondson]

On Sat, 24 Apr 2010 11:04:49 -0300, David Bremner  wrote:
> As I'm faced with writing docs for output selection, I'd like to revisit
> this idea. I didn't get any feedback, positive or negative about the
> idea of keeping the docs in pod.  I don't care much about the format,
> but I think it would be nice to avoid maintaining two copies of the
> documentation.
> 
> Should I rebase/rebuild this against the current docs, or not bother?

I like the idea, but I have no experience with pod.

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

[PATCH] emacs: Allow headers to be shown by default in show mode

[David Edmondson]

On Sat, 24 Apr 2010 05:42:54 -0700, Carl Worth  wrote:
> On Fri, 23 Apr 2010 21:08:48 +0100, David Edmondson  wrote:
> > I like the current behaviour, but changing the default would be fine.
> 
> Which parts of it do you like? Being able to toggle the header back and
> forth? Or just that the hidden headers take up so little vertical
> space?

Both, particularly that the headers can be hidden by default. Mostly I
care about what you have to say and who you are, not who you said it to.

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

Wrapping up the 0.3 release

[Aneesh Kumar K. V]

On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth  wrote:
> I pushed hard to get most everything we wanted for 0.3 done yesterday,
> (which was one week since 0.2). I think we're still within the tolerance
> of my published "about a week" schedule, but I would like to wrap things
> up soon.
> 
> Here are the features that I still have left in my queue at this point:
> 
>   * improve from-header guessing
> 
> Dirk is looking into fixing a segfault found by the test suite here
> 
>   * Fcc, Maildir, and Emacs message-mode -- a bit of code
> 
> This is next on my list to apply. Thanks for the extra testing!
> 
> There are a few other features that people had proposed but that didn't
> pass review yet. If people follow-up with those quickly, they can still
> go in. Otherwise, there's another new merge window coming up soon!
> 
> Meanwhile, I'm aware of two regressions I'd like to see fixed before
> 0.3:
> 
>   * Reply is now splitting the window
> 
> We're copying the original message into the new reply buffer, so
> what's the advantage of splitting here?

This actually have a disadvantage that after sending the mail i have to
explicitly kill the buffer


> 
>   * Composing a new message with 'm' brings up headers in a scrambled
> order.
> 
> A minor point, but it would be nice to fix this.
> 
> Finally, any of the tweaks I suggested to notmuch-hello mode would be
> quite welcome. I might take a whack at some of these.
> 
> Then, there's the task of writing up NEWS. Dirk started helping with
> that, which I appreciate. If anyone else wants to write up descriptions
> of their favorite features that have been merged, that would be great.

Another issue i found was


* A thread with only one message doesn't show the message body by
  default. I need to use 'h' key binding to show the message
  body. Multiple message thread seems to work fine.


-aneesh

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[David Edmondson]

On Fri, 23 Apr 2010 17:49:38 -0700, Carl Worth  wrote:
> I finally hit on doing (require 'notmuch-address) in .emacs. As noted
> previously, can we please make (require 'notmuch) pull in all notmuch
> functionality rather than having it separated like this?

Patch sent.

> Finally, though, I haven't figured out how to get more than a single
> match from this. If the first match isn't what I want, how do I see and
> choose later matches?

M-n to move forward in the list, M-p to move backwards (including into
any history you have accrued).

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

Re: new patch series for author reordering code

[Carl Worth]

On Sat, 24 Apr 2010 11:20:52 -0700, Dirk Hohndel  wrote:
> I think this could go into 0.3 as is. I've been using the mostly identical
> previous version for about a week - the changes here are mostly cleanup based
> on cworth's feedback.

Thanks, Dirk.

This made a very nice patch series, (particularly with the test case).

I've pushed this now.

-Carl

-- 
carl.d.wo...@intel.com


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

new patch series for author reordering code

[Carl Worth]

On Sat, 24 Apr 2010 11:20:52 -0700, Dirk Hohndel  
wrote:
> I think this could go into 0.3 as is. I've been using the mostly identical
> previous version for about a week - the changes here are mostly cleanup based
> on cworth's feedback.

Thanks, Dirk.

This made a very nice patch series, (particularly with the test case).

I've pushed this now.

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/c5ab21c6/attachment.pgp>

[PATCH] emacs: Automatically load "notmuch-address"

[David Edmondson]

"notmuch-address.el" tries to be careful to insinuate itself into
message mode only if it will do something useful, so it's safe to load
it all of the time.
---
 emacs/notmuch-mua.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..305275e 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -23,6 +23,7 @@
 (require 'message)

 (require 'notmuch-lib)
+(require 'notmuch-address)

 ;;

-- 
1.7.0

[PATCH] RFC: Add From guessing when forwarding email

[David Edmondson]

On Fri, 23 Apr 2010 15:52:15 -0700, Dirk Hohndel  
wrote:
> Given how little elisp I know I'm quite interested in feedback
> and better implementations

I think that:

(defun notmuch-show-forward-message ()
  "Forward the current message."
  (interactive)
  (let ((user-mail-address
 (shell-command-to-string (concat notmuch-command
  "guess-from"
  (notmuch-show-get-message-id)
(with-current-notmuch-show-message
 (notmuch-mua-forward-message

is more idiomatic.

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

Re: bug tracking

[Arvid Picciani]

On Mon, 26 Apr 2010 11:31:05 -0700, Carl Worth  wrote:

> For example, if dme commits a fix and marks "issue #217 closed" with
> that fix, then I'd like my repository of bugs to also know to close that
> issue when I later merge his fix.

bitbucket does that, and i would bet its quite a common feature on the
large git hosters too.

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

Re: [PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[Carl Worth]

carl.d.wo...@intel.com
On Mon, 26 Apr 2010 19:20:04 +0100, David Edmondson  wrote:
> On Mon, 26 Apr 2010 11:03:36 -0700, Carl Worth  wrote:
> > Thanks. I've pushed this. Bonus points to someone who fixes it to avoid
> > printing "1 matches".
> 
> It shouldn't do that:
...
> Does it?

Bah. My fault for glancing at the code (incorrectly) rather than running
it.

Move along, nothing to see here...

-Carl


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

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[Carl Worth]

carl.d.worth at intel.com
On Mon, 26 Apr 2010 19:20:04 +0100, David Edmondson  wrote:
> On Mon, 26 Apr 2010 11:03:36 -0700, Carl Worth  wrote:
> > Thanks. I've pushed this. Bonus points to someone who fixes it to avoid
> > printing "1 matches".
> 
> It shouldn't do that:
...
> Does it?

Bah. My fault for glancing at the code (incorrectly) rather than running
it.

Move along, nothing to see here...

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/eae7c717/attachment.pgp>

Re: [PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[Carl Worth]

-- 
carl.d.wo...@intel.com
On Mon, 26 Apr 2010 19:03:35 +0100, David Edmondson  wrote:
> > What about advanced users?  I really want my notmuch front page to just
> > be a particular saved search.  The notmuch-hello looks neat, but I don't
> > really see myself ever using it, since I can access all the
> > functionality I need already.  All I really want from a front page is
> > the main search that I look at all the time ("tag:inbox and not
> > tag:deleted"), have it *not* close if I accidentally hit 'q', and a way
> > to pop back to it from wherever I am.  Could we make it configurable so
> > that the front page is either the hello page, or the special search page
> > I describe?
> 
> (global-set-key "\C-ci" '(lambda () (interactive) (notmuch-search "tag:inbox 
> and not tag:deleted" notmuch-search-oldest-first)))

It's really close, I think.

It doesn't add the "not close if I hit 'q'" feature, though.

And I agree that that feature is really important for using a default
search as the "primary landing page" of notmuch. I really wanted that
feature when I was using the original `notmuch' command as my primary
landing page.

The idea is to allow the user to basically just keep hitting 'q' to
quickly pop back up to the primary search.

As far as "could we make it configurable?": Of course! This is emacs
after all. ;-)

-Carl



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

[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[Carl Worth]

-- 
carl.d.worth at intel.com
On Mon, 26 Apr 2010 19:03:35 +0100, David Edmondson  wrote:
> > What about advanced users?  I really want my notmuch front page to just
> > be a particular saved search.  The notmuch-hello looks neat, but I don't
> > really see myself ever using it, since I can access all the
> > functionality I need already.  All I really want from a front page is
> > the main search that I look at all the time ("tag:inbox and not
> > tag:deleted"), have it *not* close if I accidentally hit 'q', and a way
> > to pop back to it from wherever I am.  Could we make it configurable so
> > that the front page is either the hello page, or the special search page
> > I describe?
> 
> (global-set-key "\C-ci" '(lambda () (interactive) (notmuch-search "tag:inbox 
> and not tag:deleted" notmuch-search-oldest-first)))

It's really close, I think.

It doesn't add the "not close if I hit 'q'" feature, though.

And I agree that that feature is really important for using a default
search as the "primary landing page" of notmuch. I really wanted that
feature when I was using the original `notmuch' command as my primary
landing page.

The idea is to allow the user to basically just keep hitting 'q' to
quickly pop back up to the primary search.

As far as "could we make it configurable?": Of course! This is emacs
after all. ;-)

-Carl

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/7fb485e4/attachment.pgp>

[SCM] notmuch - thread-based email index, search and tagging. branch, master, updated. 0.2-180-gc87d17f

[Sebastian Spaeth]

On 2010-04-25, David Edmondson wrote:
> Originally this was the behaviour (jump to the search box), but I found
> that it really annoyed me. To use any of the keybindings it's necessary
> to move the cursor out of the search entry area.

Actually, a widget can have its own keymap, so it is entirely possible
to make it just to the saved searches with c-1 - c9 or whatever from
within that widget. I know that dme accepts patches for this :-)

Sebastian

Re: [PATCH] Makefile.local: Fix LDFLAGS for notmuch-shared

[Carl Worth]

On Thu, 22 Apr 2010 23:04:30 -0400, Adrien Bustany  wrote:
> This commit adds GMIME_LDFLAGS and TALLOC_LDFLAGS to the linker flags
> when linking notmuch-shared. Without these flags, linking fails because
> of undefined symbols.

Hi Adrien,

What system are you using that has this problem? For Linux, at least,
those addition flags are not needed, (nor actually wanted). For other
systems, we know that these flags are needed, so we have a configure
check that tries to set LINKER_RESOLVES_LIBRARY_DEPENDENCIES=0 for these
systems.

So perhaps the correct fix here is to fix our configure script to set
that variable for your system.

Can you test if changing that variable to 0 in Makefile.config fixes
your build?

Thanks,

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] Makefile.local: Fix LDFLAGS for notmuch-shared

[Carl Worth]

On Thu, 22 Apr 2010 23:04:30 -0400, Adrien Bustany  
wrote:
> This commit adds GMIME_LDFLAGS and TALLOC_LDFLAGS to the linker flags
> when linking notmuch-shared. Without these flags, linking fails because
> of undefined symbols.

Hi Adrien,

What system are you using that has this problem? For Linux, at least,
those addition flags are not needed, (nor actually wanted). For other
systems, we know that these flags are needed, so we have a configure
check that tries to set LINKER_RESOLVES_LIBRARY_DEPENDENCIES=0 for these
systems.

So perhaps the correct fix here is to fix our configure script to set
that variable for your system.

Can you test if changing that variable to 0 in Makefile.config fixes
your build?

Thanks,

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/589d70fb/attachment.pgp>

Re: bug tracking

[Carl Worth]

On Thu, 22 Apr 2010 14:37:26 -0300, David Bremner  wrote:
> It was thinking along these lines that got me to make the following list
> 
>  http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/

I'm not sure what it is you think of as a "git-based issue tracker". Or
rather, I'm not sure if we have the same ideas about what would make a
git-based issue tracker interesting.

> If people think the general concept of a distributed bug tracker is
> worthwhile, I'm willing to investigate a more.  Feel free to cc

For me, having an issue tracker be git-based might help with what really
matters, but wouldn't necessarily.

One realization is that since we have distributed code, we necessarily
have distributed bug state. (The bugs that exist in my repository are
distinct from the bugs that exist in your repository.) So if bug state
can follow the way code moves, then that is interesting.

For example, if dme commits a fix and marks "issue #217 closed" with
that fix, then I'd like my repository of bugs to also know to close that
issue when I later merge his fix.

To me, that's really a user-interface issue, more than a storage
issue. I don't care if the issue tracker stores its state in a git
database. But I do care that it be able to watch what we are already
doing, (creating git commits and sharing them), in order for us to
easily track state.

It seems to me that almost all issues of interest are already raised on
this mailing list, and later followed up with a message from me, (along
the lines of "thanks, this is pushed"). So I'd be happy with a system
that relied on an email interface as well.

What I don't want is something that would make me go push buttons in a
web form in addition to the "git push" and sending of email that I'm
already doing.

My primary metric for adopting a new issue tracker is "how little extra
work will I have to do to use this compared to what I'm already
doing?". That's a lot more important to me than how the system stores
its data.

-Carl


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

bug tracking

[Carl Worth]

On Thu, 22 Apr 2010 14:37:26 -0300, David Bremner  wrote:
> It was thinking along these lines that got me to make the following list
> 
>  http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/

I'm not sure what it is you think of as a "git-based issue tracker". Or
rather, I'm not sure if we have the same ideas about what would make a
git-based issue tracker interesting.

> If people think the general concept of a distributed bug tracker is
> worthwhile, I'm willing to investigate a more.  Feel free to cc

For me, having an issue tracker be git-based might help with what really
matters, but wouldn't necessarily.

One realization is that since we have distributed code, we necessarily
have distributed bug state. (The bugs that exist in my repository are
distinct from the bugs that exist in your repository.) So if bug state
can follow the way code moves, then that is interesting.

For example, if dme commits a fix and marks "issue #217 closed" with
that fix, then I'd like my repository of bugs to also know to close that
issue when I later merge his fix.

To me, that's really a user-interface issue, more than a storage
issue. I don't care if the issue tracker stores its state in a git
database. But I do care that it be able to watch what we are already
doing, (creating git commits and sharing them), in order for us to
easily track state.

It seems to me that almost all issues of interest are already raised on
this mailing list, and later followed up with a message from me, (along
the lines of "thanks, this is pushed"). So I'd be happy with a system
that relied on an email interface as well.

What I don't want is something that would make me go push buttons in a
web form in addition to the "git push" and sending of email that I'm
already doing.

My primary metric for adopting a new issue tracker is "how little extra
work will I have to do to use this compared to what I'm already
doing?". That's a lot more important to me than how the system stores
its data.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/04960729/attachment-0001.pgp>

Unhandled Xapian exception

[Sebastian Spaeth]

On 2010-04-24, Carl Worth wrote:
> On Fri, 23 Apr 2010 13:21:56 +0200, "Sebastian Spaeth"  SSpaeth.de> wrote:
> > I propose to try..catch this code block and rather than returning VOID
> > it could return NOTMUCH_STATUS_SUCCESS or NOTMUCH_XAPIAN_EXCEPTION.
> > Not sure how "notmuch_database_find_message" would notify the caller of
> > such an exception situation though. The only possible failure value is
> > NULL (which also means did not find such a message).

> And to support that, we would need a different scheme in the
> library. Basically to just document that all calls might throw an
> exception and then not catch and print anything. That would at least be
> much simpler in the library. Then the top-level "notmuch" application
> could just have a C++ wrapper for main() that would catch and print the
> exception message.

I think the python API would not be able to catch a C++ exception at the
library level. I think the proper fix would be to guard the high level
lib/* functions (our public API) and modify the API as needed to notify
us.

E.g for msg* = notmuch_database_find_message(id) (which I used to test
the existence of a message and where NULL can now also mean that someone
modified the database and which renders that test somewhat useless), I
would propose that we make it:

NOTMUCH_STATUS status = notmuch_database_find_message(id, msg*)

where *msg will be filled with the message if it exists and xapian
exceptions are notified through the status code.

Does this make sense?

Sebastian

Re: [PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[David Edmondson]

On Mon, 26 Apr 2010 11:03:36 -0700, Carl Worth  wrote:
> Thanks. I've pushed this. Bonus points to someone who fixes it to avoid
> printing "1 matches".

It shouldn't do that:

  (let* (...
 (num-options (length options))
 (chosen (if (eq num-options 1)
 (car options)
   (completing-read (format "Address (%s matches): " 
num-options)
(cdr options) nil nil (car options)
'notmuch-address-history

Does it?

More interesting is the zero matches case...

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


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

Re: Kudos! Also: +1 PGP!

[Darren McGuicken]

On Mon, 26 Apr 2010 07:16:16 -0400, Jameson Rollins 
 wrote:
> > In the meantime, I find myself using the snippet from Tassilo in:
> > id:87zl6cl595@thinkpad.tsdh.de
> 
> I'm interested in using this as a stop-gap, but unfortunately I'm not
> finding this message in my local store.  Can you point to url in an
> archive, or forward this to me or the list?

Absolutely, you can find the thread on gmane here:

 http://thread.gmane.org/gmane.mail.notmuch.general/778/focus=78

One other thing I'd recommend is downloading the complete archive from
the link on notmuchmail.org:

 http://notmuchmail.org/archives/notmuch.mbox

It's incredibly handy being able to search for notmuch information with
notmuch itself!


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

[PATCH] emacs: Correct message/header/citation/signature hiding

[David Edmondson]

Set `buffer-invisibility-spec' to `nil' (a list) if it is just `t'
before inserting any body parts, otherwise removing items from
`buffer-invisibility-spec' (which is what
`notmuch-show-headers-visible' and `notmuch-show-message-visible' do)
is a no-op and has no effect. This caused threads with only matching
messages to have those messages hidden initially because
`buffer-invisibility-spec' stayed `t'.
---

Carl, we need this fix before 0.3 is released. The bug has always
existed in the JSON based UI and is now exposed because previously
there was always a call to `add-to-invisibility-spec' (for the
headers), which transformed `buffer-invisiliblty-spec' from `t' to a
list. That doesn't always happen now (only calls to
`remove-from-invisibility-spec'), so the variable could get left as
`t'.

 emacs/notmuch-show.el |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f958a30..f9d6c93 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -382,6 +382,22 @@ current buffer, if possible."
(headers-invis-spec (notmuch-show-make-symbol "header"))
(message-invis-spec (notmuch-show-make-symbol "message")))

+;; Set `buffer-invisibility-spec' to `nil' (a list), otherwise
+;; removing items from `buffer-invisibility-spec' (which is what
+;; `notmuch-show-headers-visible' and
+;; `notmuch-show-message-visible' do) is a no-op and has no
+;; effect. This caused threads with only matching messages to have
+;; those messages hidden initially because
+;; `buffer-invisibility-spec' stayed `t'.
+;;
+;; This needs to be set here (rather than just above the call to
+;; `notmuch-show-headers-visible') because some of the part
+;; rendering or body washing functions
+;; (e.g. `notmuch-wash-text/plain-citations') manipulate
+;; `buffer-invisibility-spec').
+(when (eq buffer-invisibility-spec t)
+  (setq buffer-invisibility-spec nil))
+
 (setq message-start (point-marker))

 (notmuch-show-insert-headerline headers
-- 
1.7.0

Re: [PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[Carl Worth]

On Mon, 26 Apr 2010 17:28:47 +0100, David Edmondson  wrote:
> 
>To: David Edmondson , notmuch@notmuchmail.org, 
> d...@yoom.home.cworth.org
>Cc: c...@ut.hh.sledj.net
>Date: Mon, 26 Apr 2010 08:21:51 -0700
> 
> Something interesting is happening here :-)

Dirk wasn't involved in the original message I was replying to at all.

And I can confirm that "notmuch reply id:87k4ru5vzp@ut.hh.sledj.net"
isn't inserting "dirk" anywhere.

But this is an address-completion thread, and I did test that
functionality by typing "dirk[TAB]". I would have thought that I had
deleted the results of any expansion, (or left the expanded results).

David, you seem to be having the problem with c...@ut.hh.sledj.net more
frequently, so perhaps you can identify the trigger.

-Carl


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

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[Carl Worth]

On Mon, 26 Apr 2010 17:28:47 +0100, David Edmondson  wrote:
> 
>To: David Edmondson , notmuch at notmuchmail.org, dirk at 
> yoom.home.cworth.org
>Cc: carl at ut.hh.sledj.net
>Date: Mon, 26 Apr 2010 08:21:51 -0700
> 
> Something interesting is happening here :-)

Dirk wasn't involved in the original message I was replying to at all.

And I can confirm that "notmuch reply id:87k4ru5vzp.fsf at ut.hh.sledj.net"
isn't inserting "dirk" anywhere.

But this is an address-completion thread, and I did test that
functionality by typing "dirk[TAB]". I would have thought that I had
deleted the results of any expansion, (or left the expanded results).

David, you seem to be having the problem with carl at ut.hh.sledj.net more
frequently, so perhaps you can identify the trigger.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/e7eab9d0/attachment.pgp>

Re: [PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[Carl Worth]

On Mon, 26 Apr 2010 17:27:38 +0100, David Edmondson  wrote:
> Patch is sent for this, though given that it's not easy to change the
> prompt as you step through, it says:
> 
>   Address (7 match): Name Here 

Thanks. I've pushed this. Bonus points to someone who fixes it to avoid
printing "1 matches".

> Moving through potential completions is pretty standard Emacs UI stuff,
> so I'm not sure if it's necessary to explain? (Of course, that you had
> to ask suggests otherwise...)

It is funny that I've used emacs for all these years without learning
this.

But in general, I have been trying to keep the notmuch interface fairly
self-explanatory. I know that some people that have never used emacs at
all are giving notmuch a try, just to see what it's like. And I'd like
to help them have as positive experience as possible.

> > I don't suppose it would be feasible to make Space and DEL navigate
> > through the list as well would it?
> 
> Not with `completing-read', but I'll look at it after 0.3.

That's what I'd assumed. If we end up doing our own thing here, I'd even
have a few more things on my wishlist. I think I'd like for matching
addresses to start appearing in the minibuffer as I started typing,
(even before hitting TAB).

Of course, for that we're going to need a faster address completer,
which will mean getting the actual addresses into the database. So I'll
add that to my list of the many things I want to fix in the great
database-schema-rewrite that's coming soon.

-Carl

-- 
carl.d.wo...@intel.com


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

Re: [PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[David Edmondson]

On Mon, 26 Apr 2010 13:38:37 -0400, Jameson Rollins 
 wrote:
> What about advanced users?  I really want my notmuch front page to just
> be a particular saved search.  The notmuch-hello looks neat, but I don't
> really see myself ever using it, since I can access all the
> functionality I need already.  All I really want from a front page is
> the main search that I look at all the time ("tag:inbox and not
> tag:deleted"), have it *not* close if I accidentally hit 'q', and a way
> to pop back to it from wherever I am.  Could we make it configurable so
> that the front page is either the hello page, or the special search page
> I describe?

Isn't something like:

(global-set-key "\C-ci" '(lambda () (interactive) (notmuch-search "tag:inbox 
and not tag:deleted" notmuch-search-oldest-first)))

all you need?

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


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

[PATCH] emacs: Add notmuch-address.el for address completion using notmuch

[Carl Worth]

On Mon, 26 Apr 2010 17:27:38 +0100, David Edmondson  wrote:
> Patch is sent for this, though given that it's not easy to change the
> prompt as you step through, it says:
> 
>   Address (7 match): Name Here 

Thanks. I've pushed this. Bonus points to someone who fixes it to avoid
printing "1 matches".

> Moving through potential completions is pretty standard Emacs UI stuff,
> so I'm not sure if it's necessary to explain? (Of course, that you had
> to ask suggests otherwise...)

It is funny that I've used emacs for all these years without learning
this.

But in general, I have been trying to keep the notmuch interface fairly
self-explanatory. I know that some people that have never used emacs at
all are giving notmuch a try, just to see what it's like. And I'd like
to help them have as positive experience as possible.

> > I don't suppose it would be feasible to make Space and DEL navigate
> > through the list as well would it?
> 
> Not with `completing-read', but I'll look at it after 0.3.

That's what I'd assumed. If we end up doing our own thing here, I'd even
have a few more things on my wishlist. I think I'd like for matching
addresses to start appearing in the minibuffer as I started typing,
(even before hitting TAB).

Of course, for that we're going to need a faster address completer,
which will mean getting the actual addresses into the database. So I'll
add that to my list of the many things I want to fix in the great
database-schema-rewrite that's coming soon.

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100426/8bc5cf36/attachment.pgp>

Re: [PATCH] emacs: Remove duplicate declaration of `notmuch-folders'

[Carl Worth]

On Mon, 26 Apr 2010 16:09:43 +0100, d...@dme.org wrote:
> From: David Edmondson 
[no commit message]

Thanks, David.

Allow me the chance to try to convince you that *every* commit requires
a sentence or two of justification, (beyond the one-line summary just
stating "what" the patch does). There's *always* some utility to saying
"why".

Take this current patch which seems so simple. There were two
declarations, so one had to go. What more could there be to say?

For me, when reviewing this, I wondered "How did there come to be two
different declarations?", and "Is this patch removing the right one?".
So I had to go grep through the source to figure out what had happened.

I could have avoided that if the commit had said something like:

This variable was moved from notmuch.el to notmuch-lib.el some time
ago, but the declaration in notmuch.el was left around. Clean
that up.

[And I just pushed the patch with this added.]

Whether or not that convinces you, perhaps you can humor me and always
try to come up with something to say, even when it seems there's nothing
possible to add. If nothing else, it can be a fun challenge. If you need
more beyond that, you can try writing your commit message as a haiku.

-Carl

-- 
carl.d.wo...@intel.com


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