compile error of current git on F15

2011-06-01 Thread Dirk Hohndel
On Tue, 31 May 2011 12:29:28 -0400, Daniel Kahn Gillmor  wrote:
Non-text part: multipart/signed
> i'm CC'ing the upstream lead developer of gmime here to see if he has
> any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey!
> 
> On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote:
> > On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel  
> > wrote:
> >> CC -O2 notmuch-reply.o
> >> notmuch-reply.c: In function ?notmuch_reply_command?:
> >> notmuch-reply.c:658:3: error: unknown type name ?GMimeSession?
> >> notmuch-reply.c:659:3: warning: passing argument 1 of 
> >> ?g_mime_gpg_context_new? from incompatible pointer type [enabled by 
> >> default]
> >> /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected 
> >> ?GMimePasswordRequestFunc? but argument is of type ?int *?
> >> make: *** [notmuch-reply.o] Error 1
> >>
> >> This seems to have been introduced in Jameson's crypto patch series...
> >>
> >> ./configure shows:
> >>
> >> Checking for Xapian development files... Yes (1.2.4).
> >> Checking for GMime development files... Yes (gmime-2.6).
> >> Checking for Glib development files (>= 2.14)... Yes.
> > 
> > Hey, Dirk.  Looks like you're using gmime-2.6, which is something I've
> > never looked at, and it looks like there are API changes.  This of
> > course doesn't help you, Dirk, but this probably means we should require
> > libgmime-2.4, at least until we can figure out how to support both
> > versions, which I'm not sure how to handle.
> > 
> > Dirk, just out of curiosity, what system are you running that is
> > provides gmime 2.6?
> 
> F15 probably means Fedora 15.

Correct

> gmime 2.6 has not been released yet; gmime 2.5 is the development
> version (which itself has an unstable API); the project uses the
> even=stable/odd=unstable version numbering scheme.
> 
> As the dev version, gmime 2.5 identifies itself as 2.6.  I'm not sure i
> can justify this decision.  Jeffrey, can you explain?
> 
> If F15 does not have gmime 2.4 available in it, it's possible that it
> may not be able to build notmuch :/

That's where I am right now. But here's the odd thing: gmime-2.6 support
was explicitly added to the configure script last year:
http://notmuch.198994.n3.nabble.com/PATCH-configure-Add-support-for-GMime-2-6-td722706.html

And it's only a recent change to notmuch that broke the build on F15
(it's one of the patches for the crypto support).

So in my book this is a regression for notmuch!

> I don't think that notmuch should attempt to target a library with an
> unstable API.  But if anyone is interested in preparing for the gmime
> 2.6 release (maybe jeffrey can hint at the timeline for us) may want to
> prepare changesets that #ifdef the relevant code depending on the API
> version.
> 
> Once gmime 2.6 is released, we'll need to decide if we want to remain
> compatible with the old API as well, or just require gmime 2.6; but i
> don't think we need to cross that bridge right now.

Given what I wrote above you'll be unsurprised that I don't agree with
this interpretation of the situation.

This used to work and used to be supported and was broken in a recent
notmuch patch.

/D


Re: compile error of current git on F15

2011-06-01 Thread Dirk Hohndel
On Tue, 31 May 2011 12:29:28 -0400, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
Non-text part: multipart/signed
 i'm CC'ing the upstream lead developer of gmime here to see if he has
 any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey!
 
 On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote:
  On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel hohn...@infradead.org 
  wrote:
  CC -O2 notmuch-reply.o
  notmuch-reply.c: In function ‘notmuch_reply_command’:
  notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
  notmuch-reply.c:659:3: warning: passing argument 1 of 
  ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by 
  default]
  /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected 
  ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
  make: *** [notmuch-reply.o] Error 1
 
  This seems to have been introduced in Jameson's crypto patch series...
 
  ./configure shows:
 
  Checking for Xapian development files... Yes (1.2.4).
  Checking for GMime development files... Yes (gmime-2.6).
  Checking for Glib development files (= 2.14)... Yes.
  
  Hey, Dirk.  Looks like you're using gmime-2.6, which is something I've
  never looked at, and it looks like there are API changes.  This of
  course doesn't help you, Dirk, but this probably means we should require
  libgmime-2.4, at least until we can figure out how to support both
  versions, which I'm not sure how to handle.
  
  Dirk, just out of curiosity, what system are you running that is
  provides gmime 2.6?
 
 F15 probably means Fedora 15.

Correct
 
 gmime 2.6 has not been released yet; gmime 2.5 is the development
 version (which itself has an unstable API); the project uses the
 even=stable/odd=unstable version numbering scheme.
 
 As the dev version, gmime 2.5 identifies itself as 2.6.  I'm not sure i
 can justify this decision.  Jeffrey, can you explain?
 
 If F15 does not have gmime 2.4 available in it, it's possible that it
 may not be able to build notmuch :/

That's where I am right now. But here's the odd thing: gmime-2.6 support
was explicitly added to the configure script last year:
http://notmuch.198994.n3.nabble.com/PATCH-configure-Add-support-for-GMime-2-6-td722706.html

And it's only a recent change to notmuch that broke the build on F15
(it's one of the patches for the crypto support).

So in my book this is a regression for notmuch!
 
 I don't think that notmuch should attempt to target a library with an
 unstable API.  But if anyone is interested in preparing for the gmime
 2.6 release (maybe jeffrey can hint at the timeline for us) may want to
 prepare changesets that #ifdef the relevant code depending on the API
 version.
 
 Once gmime 2.6 is released, we'll need to decide if we want to remain
 compatible with the old API as well, or just require gmime 2.6; but i
 don't think we need to cross that bridge right now.

Given what I wrote above you'll be unsurprised that I don't agree with
this interpretation of the situation.

This used to work and used to be supported and was broken in a recent
notmuch patch.

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


compile error of current git on F15

2011-05-30 Thread Dirk Hohndel

CC -O2 notmuch-reply.o
notmuch-reply.c: In function ‘notmuch_reply_command’:
notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ 
from incompatible pointer type [enabled by default]
/usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected 
‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
make: *** [notmuch-reply.o] Error 1

This seems to have been introduced in Jameson's crypto patch series...

./configure shows:

Checking for Xapian development files... Yes (1.2.4).
Checking for GMime development files... Yes (gmime-2.6).
Checking for Glib development files (= 2.14)... Yes.

/D

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


compile error of current git on F15

2011-05-29 Thread Dirk Hohndel

CC -O2 notmuch-reply.o
notmuch-reply.c: In function ?notmuch_reply_command?:
notmuch-reply.c:658:3: error: unknown type name ?GMimeSession?
notmuch-reply.c:659:3: warning: passing argument 1 of ?g_mime_gpg_context_new? 
from incompatible pointer type [enabled by default]
/usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected 
?GMimePasswordRequestFunc? but argument is of type ?int *?
make: *** [notmuch-reply.o] Error 1

This seems to have been introduced in Jameson's crypto patch series...

./configure shows:

Checking for Xapian development files... Yes (1.2.4).
Checking for GMime development files... Yes (gmime-2.6).
Checking for Glib development files (>= 2.14)... Yes.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


problems with multipart/mixed

2011-05-24 Thread Dirk Hohndel

Pulled the latest. Fixes the reply issue - but frequently gets emacs to
dump core. Looking at the backtrace reminds me why I hate emace some
times :-) - it appears to happen in a memmove - but everything else in
the backtrave is useless

Not an improvement.

/D

On Tue, 24 May 2011 12:50:20 -0700, Carl Worth  wrote:
Non-text part: multipart/signed
> On Mon, 23 May 2011 19:46:41 -0700, Dirk Hohndel  
> wrote:
> > Hehe, as the reply below shows... there's still something screwy even
> > with the latest git version... in multipart messages things just go
> > wrong. Whether I reply (this below should have included your text/plain
> > part as quote)
> 
> You caught me again, on two points:
> 
>   1. Our multipart testing wasn't testing "notmuch reply"
> 
>   2. I wasn't actually running the latest code in my own use
> 
> I've addressed both of those problems, which made it easy to find and
> fix the segfault that was causing the missing data in the reply
> buffer. I will hopefully be in a good habit now of creating a Debian
> package and installing and using it locally as part of my testing of
> major changes.
> 
> Meanwhile, I did just push Jameson's recent new-show-part branch (along
> with some updates from me). This should complete the big upheaval of
> changes to how multipart messages are handled. From here, Jameson will
> rebase his crypto branch so we can verify signatures and decrypt
> messages within emacs.
> 
> > or whether I try to see the html part of a text/plain +
> > text/html multipart message...
> 
> This is an area where there have been some recent feature changes---and
> again, sadly, there's still some missing testing of the emacs features.
> 
> The change I am seeing is that previously whenever a message had both a
> text/plain part and a corresponding text/html part (withing
> multipart/alternative), emacs would render both of them.
> 
> Instead, I'm now seeing the text/plain part followed by:
> 
>   [ text/html (not shown) ]
> 
> As far as that goes, this hiding of the HTML by default is exactly what
> I want. (If people don't want this, there's a
> notmuch-show-all-multipart/alternative-parts variable that can be
> tweaked. Or just do "M-x customize-group notmuch" and find the setting
> there.)
> 
> Meanwhile, I can imagine that some people might actually need to view
> the HTML part that's initially not shown. I just tried hitting 'V' on
> the "(not shown)" button and I got several image-viewer windows, each
> showing one of the contained images. That's not ideal---it would be
> better to get some web browser to display the entire message formatted
> correctly.
> 
> Maybe that's just something I need to customize on my end, (though, if
> so, I think notmuch could do a better job arranging that for the user).
> 
> So contributions would be welcome in this area, (both functional
> improvements to the emacs interface as well as additional testing of
> those emacs features).
> 
> -Carl
> 
> -- 
> carl.d.worth at intel.com
Non-text part: application/pgp-signature

-- 
Dirk Hohndel
Intel Open Source Technology Center


Re: problems with multipart/mixed

2011-05-24 Thread Dirk Hohndel

Pulled the latest. Fixes the reply issue - but frequently gets emacs to
dump core. Looking at the backtrace reminds me why I hate emace some
times :-) - it appears to happen in a memmove - but everything else in
the backtrave is useless

Not an improvement.

/D

On Tue, 24 May 2011 12:50:20 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/signed
 On Mon, 23 May 2011 19:46:41 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  Hehe, as the reply below shows... there's still something screwy even
  with the latest git version... in multipart messages things just go
  wrong. Whether I reply (this below should have included your text/plain
  part as quote)
 
 You caught me again, on two points:
 
   1. Our multipart testing wasn't testing notmuch reply
 
   2. I wasn't actually running the latest code in my own use
 
 I've addressed both of those problems, which made it easy to find and
 fix the segfault that was causing the missing data in the reply
 buffer. I will hopefully be in a good habit now of creating a Debian
 package and installing and using it locally as part of my testing of
 major changes.
 
 Meanwhile, I did just push Jameson's recent new-show-part branch (along
 with some updates from me). This should complete the big upheaval of
 changes to how multipart messages are handled. From here, Jameson will
 rebase his crypto branch so we can verify signatures and decrypt
 messages within emacs.
 
  or whether I try to see the html part of a text/plain +
  text/html multipart message...
 
 This is an area where there have been some recent feature changes---and
 again, sadly, there's still some missing testing of the emacs features.
 
 The change I am seeing is that previously whenever a message had both a
 text/plain part and a corresponding text/html part (withing
 multipart/alternative), emacs would render both of them.
 
 Instead, I'm now seeing the text/plain part followed by:
 
   [ text/html (not shown) ]
 
 As far as that goes, this hiding of the HTML by default is exactly what
 I want. (If people don't want this, there's a
 notmuch-show-all-multipart/alternative-parts variable that can be
 tweaked. Or just do M-x customize-group notmuch and find the setting
 there.)
 
 Meanwhile, I can imagine that some people might actually need to view
 the HTML part that's initially not shown. I just tried hitting 'V' on
 the (not shown) button and I got several image-viewer windows, each
 showing one of the contained images. That's not ideal---it would be
 better to get some web browser to display the entire message formatted
 correctly.
 
 Maybe that's just something I need to customize on my end, (though, if
 so, I think notmuch could do a better job arranging that for the user).
 
 So contributions would be welcome in this area, (both functional
 improvements to the emacs interface as well as additional testing of
 those emacs features).
 
 -Carl
 
 -- 
 carl.d.wo...@intel.com
Non-text part: application/pgp-signature

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


problems with multipart/mixed

2011-05-23 Thread Dirk Hohndel

Hehe, as the reply below shows... there's still something screwy even
with the latest git version... in multipart messages things just go
wrong. Whether I reply (this below should have included your text/plain
part as quote), or whether I try to see the html part of a text/plain +
text/html multipart message...

/D

On Mon, 23 May 2011 14:38:05 -0700, Carl Worth  wrote:
Non-text part: multipart/signed


problems with multipart/mixed

2011-05-23 Thread Dirk Hohndel
On Sat, 21 May 2011 08:35:13 +0200, Matthias Guedemann  wrote:
> 
> Hi all,
> 
> I am using notmuch / emacs as my main mail client now for several months
> and loosely follow master.
> 
> After an update yesterday I now have problems with some multipart/mixed
> mails from mailing lists which are displayed for example as follows (I
> could also provide the raw mail if needed):
> 
> 8<--
> Subject: [Haskell-cafe] Can't access map value with key.
> To: "haskell-cafe at haskell.org"
>   
> Date: Sat, 21 May 2011 04:04:31 +0200 
>   
>   
>  
> [ multipart/mixed ]
> [ text/html ] 
>
> ___ Haskell-Cafe mailing
> list Haskell-Cafe at haskell.org http://   
> www.haskell.org/mailman/listinfo/haskell-cafe 
>
>   
>   
> [ ATT1.c: text/plain ]
>   
> [ 4-line signature. Click/Enter to toggle visibility. ]
> 8<--
> 
> i.e. the html part is not displayed. I'd like to have it displayed
> inline (using w3m), just as other html mails and just like it worked
> before (at least I think it worked). I probably just missed a simple
> configuration option.

If you did then I'm in the same boat. Notmuch/emacs used to display both
parts, text and html, and now only displays text with no way (that I
could find) to display the html part as well.

/D


Re: problems with multipart/mixed

2011-05-23 Thread Dirk Hohndel
On Sat, 21 May 2011 08:35:13 +0200, Matthias Guedemann 
matthias.guedem...@ovgu.de wrote:
 
 Hi all,
 
 I am using notmuch / emacs as my main mail client now for several months
 and loosely follow master.
 
 After an update yesterday I now have problems with some multipart/mixed
 mails from mailing lists which are displayed for example as follows (I
 could also provide the raw mail if needed):
 
 8--
 Subject: [Haskell-cafe] Can't access map value with key.
 To: haskell-c...@haskell.org haskell-c...@haskell.org 
 
 Date: Sat, 21 May 2011 04:04:31 +0200 
   
   
  
 [ multipart/mixed ]
 [ text/html ] 

 ___ Haskell-Cafe mailing
 list haskell-c...@haskell.org http://   
 www.haskell.org/mailman/listinfo/haskell-cafe 

   
   
 [ ATT1.c: text/plain ]
   
 [ 4-line signature. Click/Enter to toggle visibility. ]
 8--
 
 i.e. the html part is not displayed. I'd like to have it displayed
 inline (using w3m), just as other html mails and just like it worked
 before (at least I think it worked). I probably just missed a simple
 configuration option.

If you did then I'm in the same boat. Notmuch/emacs used to display both
parts, text and html, and now only displays text with no way (that I
could find) to display the html part as well.

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


Re: problems with multipart/mixed

2011-05-23 Thread Dirk Hohndel

Hehe, as the reply below shows... there's still something screwy even
with the latest git version... in multipart messages things just go
wrong. Whether I reply (this below should have included your text/plain
part as quote), or whether I try to see the html part of a text/plain +
text/html multipart message...

/D

On Mon, 23 May 2011 14:38:05 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/signed
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] add headers cc: bcc: and to: (as exactto:) to search index

2010-12-02 Thread Dirk Hohndel
On Wed,  1 Dec 2010 21:33:55 +0100, Joel Borggr?n-Franck  wrote:
> From: Joel Borggr?n-Franck 
> 
> Add headers cc: bcc: and to: to index. Real header to: is searched as
> "exactto:foo at bar.baz" and search term "to:" is kept as a union of cc:,
> bcc: and to: for backward compatibility. Use search term "cc:" resp.
> "bcc:" to search those headers respectively.

cworth has been talking for a while about changing notmuch to index all
of the headers - this is one of my key missing features at this point. 
Searching for Sender: or X-Mailing-List: or (PLEASE) X-Spam-Score:

/D


Re: [PATCH] add headers cc: bcc: and to: (as exactto:) to search index

2010-12-02 Thread Dirk Hohndel
On Wed,  1 Dec 2010 21:33:55 +0100, Joel Borggrén-Franck 
joel.borggren.fra...@gmail.com wrote:
 From: Joel Borggrén-Franck j...@codehouse.se
 
 Add headers cc: bcc: and to: to index. Real header to: is searched as
 exactto:f...@bar.baz and search term to: is kept as a union of cc:,
 bcc: and to: for backward compatibility. Use search term cc: resp.
 bcc: to search those headers respectively.

cworth has been talking for a while about changing notmuch to index all
of the headers - this is one of my key missing features at this point. 
Searching for Sender: or X-Mailing-List: or (PLEASE) X-Spam-Score:

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


notmuchsync: handling of the deleted tag

2010-11-12 Thread Dirk Hohndel
On Fri, 12 Nov 2010 08:30:36 +0100, Sebastian Spaeth  
wrote:
> On Thu, 11 Nov 2010 17:27:34 -0800, Carl Worth  wrote:
> > So, what we probably need here is for the user to be able to configure
> > the mapping and in a fairly sophisticated way:
> > 
> > 'R' on _any_ filename  -> "replied" tag gets added
> > 'T' on _all_ filenames -> "deleted" tag gets added
> > 'S' on _any_ filename  -> "unread" tag gets removed
> > So maybe something like that?
> 
> Maybe, but that sounds like a horribly complex configuration, in which
> the user has to really think through what he wants (and can still make
> blunders). :)
>  
> > > > If notmuch gave me at least all filenames that are associated with a
> > > > mail id, I could introduce a command line option "--prune --safe"
> > > > which would
> 
> Right, you pushed the ball in my court. The only problem is that -- with
> the arrival of maildir sync -- I lost my motivation to work on
> notmuchsync. Seriously, what does notmuchsync still provide that notmuch
> cannot do? I wonder if I shouldn't stick a "deprecated" warning on it.

Please don't! I use it all the time:

I use it to archive mail that I don't want on an imap server any more,
but in a local maildir. Can't do that with notmuch.

I use it to prune mail that has the deleted tag. Again not something
that notmuch supports.

So please don't stop supporting your very important (to me) tool!

/D


Re: notmuchsync: handling of the deleted tag

2010-11-12 Thread Dirk Hohndel
On Fri, 12 Nov 2010 08:30:36 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On Thu, 11 Nov 2010 17:27:34 -0800, Carl Worth cwo...@cworth.org wrote:
  So, what we probably need here is for the user to be able to configure
  the mapping and in a fairly sophisticated way:
  
  'R' on _any_ filename  - replied tag gets added
  'T' on _all_ filenames - deleted tag gets added
  'S' on _any_ filename  - unread tag gets removed
  So maybe something like that?
 
 Maybe, but that sounds like a horribly complex configuration, in which
 the user has to really think through what he wants (and can still make
 blunders). :)
  
If notmuch gave me at least all filenames that are associated with a
mail id, I could introduce a command line option --prune --safe
which would
 
 Right, you pushed the ball in my court. The only problem is that -- with
 the arrival of maildir sync -- I lost my motivation to work on
 notmuchsync. Seriously, what does notmuchsync still provide that notmuch
 cannot do? I wonder if I shouldn't stick a deprecated warning on it.

Please don't! I use it all the time:

I use it to archive mail that I don't want on an imap server any more,
but in a local maildir. Can't do that with notmuch.

I use it to prune mail that has the deleted tag. Again not something
that notmuch supports.

So please don't stop supporting your very important (to me) tool!

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


Maildir-flags synchronization now on master branch

2010-11-11 Thread Dirk Hohndel
On Thu, 11 Nov 2010 16:43:45 -0800, Carl Worth  wrote:
> 
> Now that all of this maildir-flag synchronization is possible, I wonder
> if we shouldn't allow the user to configure the mapping of maildir-flag
> characters to tag names. That would allow for (a limited number of) tags
> to be synchronized on multiple machines using synchronization mechanisms
> such as offlineimap without needing any notmuch-aware synchronization.
> 
> So that might be very interesting.

Oh I LOVE that idea. There are only a small number of tags that I
/really/ need and to be able to access them from multiplme machines,
kept in sync through the imap server... awesome.

/D


[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Dirk Hohndel
On Wed, 13 Oct 2010 22:34:34 +0200, Michal Sojka  wrote:
> On Wed, 13 Oct 2010, Servilio Afre Puentes wrote:
> > On 13 October 2010 08:13, Michal Sojka  wrote:
> > [...]
> > > THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
> > > unread messages doesn't work. The reason is that when you view the
> > > message its unread tag is removed which causes the file to be renamed,
> > > but Emacs still uses the original name to access the attachment. You can
> > > workaround this by closing the message and opening it again. This issue
> > > will be fixed after we (I) implement "notmuch cat" command. With this
> > > command, emacs would not access the messages by the file name, but by
> > > running notmuch cat id: which will always give the correct
> > > content.
> > 
> > Wouldn't it be more efficient to query notmuch for the filename using
> > the message ID we store in the DB? When network usage is implemented,
> > tramp can give us transparent remote file access in emacs.
> 
> Tramp would not be available in non-emacs GUIs. Also, when notmuch cat
> is implemented, emacs gui will be usable remotely by simply defining
> notmuch-command variable to contain the name of the script containing:
> 
>  ssh user at host notmuch "$@"

That to me is certainly a very elegant solution... so what's stopping us
from implementing notmuch cat? No one taken the time to do it? Or is
there a design issue left to be resolved?

/D


Re: [PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Dirk Hohndel
On Wed, 13 Oct 2010 22:34:34 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
 On Wed, 13 Oct 2010, Servilio Afre Puentes wrote:
  On 13 October 2010 08:13, Michal Sojka sojk...@fel.cvut.cz wrote:
  [...]
   THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
   unread messages doesn't work. The reason is that when you view the
   message its unread tag is removed which causes the file to be renamed,
   but Emacs still uses the original name to access the attachment. You can
   workaround this by closing the message and opening it again. This issue
   will be fixed after we (I) implement notmuch cat command. With this
   command, emacs would not access the messages by the file name, but by
   running notmuch cat id:message-id which will always give the correct
   content.
  
  Wouldn't it be more efficient to query notmuch for the filename using
  the message ID we store in the DB? When network usage is implemented,
  tramp can give us transparent remote file access in emacs.
 
 Tramp would not be available in non-emacs GUIs. Also, when notmuch cat
 is implemented, emacs gui will be usable remotely by simply defining
 notmuch-command variable to contain the name of the script containing:
 
  ssh u...@host notmuch $@

That to me is certainly a very elegant solution... so what's stopping us
from implementing notmuch cat? No one taken the time to do it? Or is
there a design issue left to be resolved?

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


notmuch synchronization

2010-10-07 Thread Dirk Hohndel
On Thu, Oct 07, 2010 at 11:51:14AM +0300, Felipe Contreras wrote:
> On Wed, Oct 6, 2010 at 10:36 AM, Sebastian Spaeth  
> wrote:
> > On 2010-10-06, Michal Sojka wrote:
> >> unfortunately, there is not much news. I only separate from these
> >> patches the part which synchronizes notmuch tags with maildir flags
> >> (unread, replied, etc.) [1]. It works pretty well and I use it to
> >> synchronize my mails with IMAP server. I think that these pathes are
> >> ready to be merged.
> >
> > +10 for merging (some of) the maildir flag/notmuch tag patches. I really 
> > wan to
> > see that functionality in notmuch. I have reverted to vanilla notmuch
> > and I'm missing that functionality.
> 
> I don't see much happening in the main repo, perhaps we should start a
> notmuch-next branch or something on gitorious?

A few people had their own patches / their own trees at some stage of
the project. Maybe having a shared notmuch-next tree somewhere that
cworth can pull from would be a good idea...

It certainly should make things easier for him as he follows his "one
day a week on notmuch" schedule.

/D


thread sorting ideas

2010-06-21 Thread Dirk Hohndel

Here is a feature that I could really use some times... 

Instead of sorting the threads based on the date of the first message in
the thread, sort them based on the newest message in the thread. So if I
take a quick look at the bottom (I am an "oldest first" kinda person) of
a search and I see all the threads that have the newest messages.

My suggestion would be to turn 'o' into a two key command:

o-o : oldest first, sort by oldest message in thread
o-O : oldest first, sort by newest message in thread
o-n : newest first, sort by oldest message in thread
o-N : newest first, sort by newest message in thread
o-s : sort by subject?
o-z : unthreaded, sort by message size?

you can come up with many more sort ideas...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


thread sorting ideas

2010-06-21 Thread Dirk Hohndel

Here is a feature that I could really use some times... 

Instead of sorting the threads based on the date of the first message in
the thread, sort them based on the newest message in the thread. So if I
take a quick look at the bottom (I am an oldest first kinda person) of
a search and I see all the threads that have the newest messages.

My suggestion would be to turn 'o' into a two key command:

o-o : oldest first, sort by oldest message in thread
o-O : oldest first, sort by newest message in thread
o-n : newest first, sort by oldest message in thread
o-N : newest first, sort by newest message in thread
o-s : sort by subject?
o-z : unthreaded, sort by message size?

you can come up with many more sort ideas...

/D

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


[PATCH 0/3] build fixes

2010-06-15 Thread Dirk Hohndel
On Mon, 14 Jun 2010 17:17:00 +0300, Felipe Contreras  wrote:
> Hi,
> 
> Is anything wrong with these patches?

cworth - our fearless leader - is extremely busy with his day job right
now. He tends to respond to all the patches on the mailing list as soon
as he finds time; sometimes within minutes, sometimes it takes weeks... 
you appear to have hit one of the slow spots.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Re: [PATCH 0/3] build fixes

2010-06-15 Thread Dirk Hohndel
On Mon, 14 Jun 2010 17:17:00 +0300, Felipe Contreras 
felipe.contre...@gmail.com wrote:
 Hi,
 
 Is anything wrong with these patches?

cworth - our fearless leader - is extremely busy with his day job right
now. He tends to respond to all the patches on the mailing list as soon
as he finds time; sometimes within minutes, sometimes it takes weeks... 
you appear to have hit one of the slow spots.

/D

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


fix problem with notmuch-hello-nice-number

2010-06-10 Thread Dirk Hohndel
On Thu, 10 Jun 2010 08:05:13 +0100, David Edmondson  wrote:
> On Wed, 09 Jun 2010 07:49:01 -0700, Dirk Hohndel  
> wrote:
> > Without this little patch notmuch fails with current git if there's a
> > saved search that has zero results
> 
> How about:
> 
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index a6e8a47..48bb6e3 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -115,6 +115,7 @@ Typically \",\" in the US and UK and \".\" in Europe."
>  (while (> n 0)
>(push (% n 1000) result)
>(setq n (/ n 1000)))
> +(setq result (or result '(0)))
>  (apply #'concat
>   (number-to-string (car result))
>   (mapcar (lambda (elem)
> 

Much better. Mine made sense when you looked at it - this one has a much
more emacs-y feel to it in that I need to stare at it for 30 seconds
before I can grasp what it does :-)

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Re: fix problem with notmuch-hello-nice-number

2010-06-10 Thread Dirk Hohndel
On Thu, 10 Jun 2010 08:05:13 +0100, David Edmondson d...@dme.org wrote:
 On Wed, 09 Jun 2010 07:49:01 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  Without this little patch notmuch fails with current git if there's a
  saved search that has zero results
 
 How about:
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index a6e8a47..48bb6e3 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -115,6 +115,7 @@ Typically \,\ in the US and UK and \.\ in Europe.
  (while ( n 0)
(push (% n 1000) result)
(setq n (/ n 1000)))
 +(setq result (or result '(0)))
  (apply #'concat
   (number-to-string (car result))
   (mapcar (lambda (elem)
 

Much better. Mine made sense when you looked at it - this one has a much
more emacs-y feel to it in that I need to stare at it for 30 seconds
before I can grasp what it does :-)

/D

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


[PATCH 0/4] Maildir synchronization

2010-06-09 Thread Dirk Hohndel
On Wed, 09 Jun 2010 19:52:42 +0100, Matt Fleming  
wrote:
> On Tue, 11 May 2010 14:14:17 +0200, Michal Sojka  
> wrote:
> > Hi,
> > 
> > these patches implement synchronization between maildir flags and
> > notmuch tags. The synchronization can be configured to not happen at
> > all (default), to set/unset tags when importing new (or new and
> > renamed) messages and to happen in both directions - set/unset tags
> > during importing and change maildir flags during tagging.
> 
> I finally got around to testing these patches and I think they're great!
> It would be fantastic if these could be merged into the main notmuch
> tree.

I've been using them for a while as well and love the feature, but I
keep running into situations where notmuch seems to get out of sync
regarding file names on disk. I haven't done a lot of searching on what
exactly causes this - but the symptom is that you'll open a message,
read it and then try to do something on it (like, save an attachment)
and suddenly are told that the message file on disk can't be found.
Or that you reply to a message and just as you are trying to send the
reply things fail for the same reason.

Next time this happens I'll take a closer look at the filenames
displayed to see what's going on.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH] remove message archiving from show-advance-and-archive

2010-06-09 Thread Dirk Hohndel
On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth  wrote:
> On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins  finestructure.net> wrote:
> > The function to advance through threads with the space bar is useful.
> > However, the current implementation also archives messages.  The idea
> > of archiving a message should not be intertwined with the processes of
> > advancing through messages to read them.  Archiving in general should
> > be a separate operation that one does explicitly.  This patch just
> > renames the advance function "notmuch-show-advance", and removes the
> > archiving of a thread when the end of the thread is reached.
> 
> The other piece of the magic space bar that people have complained about
> is that it intertwines advancing among messages within one thread with
> advancing from one thread to the next. (And only the first operation is
> reversible by backspace.)

This has always confused me - I think I've complained about it before as
well :)

> I think we'll probably want to change that at the same time.
> 
> Meanwhile, I'm currently working on support for piping a whole thread of
> messages as an mbox to a process, (mostly getting bogged down in trying
> to fix mbox support in git).
> 
> For that, I think I want the current '|' binding to pipe the current
> message and then a new binding ("M-|" ?) to pipe every (open) message in
> the thread.
> 
> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
> 
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.

I really like this. It's consistent and I'm sure I'll get used to it
quickly. The only question now is "all messages in a thread" or "all
open messages in a thread". I'd vote for all.

Oh - and I really want a way to do surgery on threads. Merge threads to
fix Blackberry users breaking threads. And split threads for
hijackers... 

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


fix problem with notmuch-hello-nice-number

2010-06-09 Thread Dirk Hohndel

Without this little patch notmuch fails with current git if there's a
saved search that has zero results

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index f5d061b..7c32f7c 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -112,6 +112,8 @@ Typically \",\" in the US and UK and \".\" in Europe."

 (defun notmuch-hello-nice-number (n)
   (let (result)
+(if (= n 0)
+   (push 0 result))
 (while (> n 0)
   (push (% n 1000) result)
   (setq n (/ n 1000)))

-- 
Dirk Hohndel
Intel Open Source Technology Center


Re: [PATCH] remove message archiving from show-advance-and-archive

2010-06-09 Thread Dirk Hohndel
On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth cwo...@cworth.org wrote:
 On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins 
 jroll...@finestructure.net wrote:
  The function to advance through threads with the space bar is useful.
  However, the current implementation also archives messages.  The idea
  of archiving a message should not be intertwined with the processes of
  advancing through messages to read them.  Archiving in general should
  be a separate operation that one does explicitly.  This patch just
  renames the advance function notmuch-show-advance, and removes the
  archiving of a thread when the end of the thread is reached.
 
 The other piece of the magic space bar that people have complained about
 is that it intertwines advancing among messages within one thread with
 advancing from one thread to the next. (And only the first operation is
 reversible by backspace.)

This has always confused me - I think I've complained about it before as
well :)
 
 I think we'll probably want to change that at the same time.
 
 Meanwhile, I'm currently working on support for piping a whole thread of
 messages as an mbox to a process, (mostly getting bogged down in trying
 to fix mbox support in git).
 
 For that, I think I want the current '|' binding to pipe the current
 message and then a new binding (M-| ?) to pipe every (open) message in
 the thread.
 
 Which makes me think that other operations should work similarly. '+'
 and '-' should change tags on the current message (as they do currently)
 and then new M-+ and M-- could change tags on all (open) messages in
 the thread.
 
 That would highlight the current 'a' as out of place since it's
 currently archiving every message in the thread. So I'd then fix it to
 be 'a' for the current message and M-a for every (open) message in the
 thread.

I really like this. It's consistent and I'm sure I'll get used to it
quickly. The only question now is all messages in a thread or all
open messages in a thread. I'd vote for all.

Oh - and I really want a way to do surgery on threads. Merge threads to
fix Blackberry users breaking threads. And split threads for
hijackers... 

/D

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


Re: [PATCH] emacs: Allow the display of absolute dates in the header line.

2010-05-20 Thread Dirk Hohndel
On Wed, 19 May 2010 07:44:18 +0100, David Edmondson d...@dme.org wrote:
 Add `notmuch-show-relative-dates' to control whether the summary line
 in `notmuch-show' mode displays relative dates (e.g. '26 mins. ago') or
 the full date string from the message. Default to `t' for
 compatibility with the previous behaviour.

Excellent - thanks for providing this (and all I did was mention it
briefly on IRC... I love this project)

/D

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


[PATCH] emacs: Allow the display of absolute dates in the header line.

2010-05-19 Thread Dirk Hohndel
On Wed, 19 May 2010 07:44:18 +0100, David Edmondson  wrote:
> Add `notmuch-show-relative-dates' to control whether the summary line
> in `notmuch-show' mode displays relative dates (e.g. '26 mins. ago') or
> the full date string from the message. Default to `t' for
> compatibility with the previous behaviour.

Excellent - thanks for providing this (and all I did was mention it
briefly on IRC... I love this project)

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


sample message that misdisplays in HTML

2010-05-16 Thread Dirk Hohndel

Apologize for the commercial message - but this one shows a weird effect
in the html display for me. This is with GNU Emacs 23.1.94.1
(x86_64-redhat-linux-gnu, GTK+ Version 2.19.7) under X running the
latest notmuch.

When displaying this as html I see 

[4]View as a Web
page|[5]Espa??olEnsure
delivery to your inbox.

(let's see how that transports... "Web page\302\240\302\249...")

/D

-- next part --
An embedded message was scrubbed...
From: "Best Buy" 
Subject: Save $500 on an HDTV and Blu-ray player bundle
Date: Sun, 16 May 2010 09:30:30 -0600
Size: 53600
URL: 



[PATCH] emacs: Display non-matching authors in italic.

2010-04-28 Thread Dirk Hohndel
On Wed, 28 Apr 2010 14:43:58 -0400, Jameson Rollins  wrote:
> On Wed, 28 Apr 2010 19:00:27 +0100, David Edmondson  wrote:
> > In search mode some messages don't match the search criteria. Show
> > their authors names in italic.
> > ---
> > 
> > Whilst enjoying knowing which authors match, I disliked the pipe
> > symbol. This is a proposed improvement.
> 
> I'm not a big fan of the | as a separator either, fwiw.  I find it a
> little distracting/confusing for some reason.

I'm not a fan of it either (and I implemented this feature). Yet it was
the only character that I could think of that somehow create the visual
separation and that is rare in Author Names and at the same time not
already used (like ';') in notmuch output

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH 2/2] Update NEWS to reflect the SEGV bugfix

2010-04-27 Thread Dirk Hohndel

Signed-off-by: Dirk Hohndel 
---
 NEWS |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index ce0ea45..035e25e 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ Notmuch 0.3.1 (2010-04-27)
 ==
 General bug fix
 ---
+Fix a potential SEGV in "notmuch search"
+
+  This bug could be triggered by an author name ending in a ','.
+  Admittedly - that's almost certainly a spam email. Still needs
+  to be handled correctly.
+
 Fix an infinite loop in "notmuch reply"

   This bug could be triggered by replying to a message where the
-- 
1.6.6.1



[PATCH 1/2] Fix SEGV in _thread_cleanup_author if author ends with ', '

2010-04-27 Thread Dirk Hohndel
Admittedly, an author name ending in ',' guarantees this is spam, and
indeed this was triggered by a spam email, but that doesn't mean we
shouldn't handle this case correctly.
We now check that there is actually a component of the name (presumably
the first name) after the comma in the author name.

Signed-off-by: Dirk Hohndel 
---
 lib/thread.cc |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index dc74ee3..13872d4 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -156,11 +156,19 @@ _thread_cleanup_author (notmuch_thread_t *thread,
 char *blank;
 int fname,lname;

+if (author == NULL)
+   return NULL;
 clean_author = talloc_strdup(thread, author);
 if (clean_author == NULL)
return NULL;
+/* check if there's a comma in the name and that there's a
+ * component of the name behind it (so the name doesn't end with
+ * the comma - in which case the string that strchr finds is just
+ * one character long ",\0").
+ * Otherwise just return the copy of the original author name that
+ * we just made*/
 comma = strchr(author,',');
-if (comma) {
+if (comma && strlen(comma) > 1) {
/* let's assemble what we think is the correct name */
lname = comma - author;
fname = strlen(author) - lname - 2;
@@ -180,7 +188,6 @@ _thread_cleanup_author (notmuch_thread_t *thread,
/* we didn't identify this as part of the email address
* so let's punt and return the original author */
strcpy (clean_author, author);
-
 }
 return clean_author;
 }
-- 
1.6.6.1



For 0.3.1: fix SEGV in notmuch search if author name ends in comma

2010-04-27 Thread Dirk Hohndel

Another incredibly stupid bug in my code.
Rather obvious fix (I hope) coming up.

/D


[PATCH] emacs: More DWIM when editing messages

2010-04-27 Thread Dirk Hohndel
On Mon, 26 Apr 2010 23:14:49 -0700, Carl Worth  wrote:
> 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.

Thanks

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

I ran out of time looking - and then forgot.

> I've pushed a fix for this.

Thanks

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


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

2010-04-27 Thread Dirk Hohndel
On Mon, 26 Apr 2010 23:14:49 -0700, Carl Worth cwo...@cworth.org wrote:
 On Tue, 27 Apr 2010 06:34:51 +0100, David Edmondson d...@dme.org wrote:
  On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel hohn...@infradead.org 
  wrote:
   +(if (re-search-backward --  nil t)
  
  Maybe `message-signature-separator' rather than the literal -- 
  here.

Thanks

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

I ran out of time looking - and then forgot.

 I've pushed a fix for this.

Thanks

/D

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


For 0.3.1: fix SEGV in notmuch search if author name ends in comma

2010-04-27 Thread Dirk Hohndel

Another incredibly stupid bug in my code.
Rather obvious fix (I hope) coming up.

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


[PATCH 1/2] Fix SEGV in _thread_cleanup_author if author ends with ', '

2010-04-27 Thread Dirk Hohndel
Admittedly, an author name ending in ',' guarantees this is spam, and
indeed this was triggered by a spam email, but that doesn't mean we
shouldn't handle this case correctly.
We now check that there is actually a component of the name (presumably
the first name) after the comma in the author name.

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 lib/thread.cc |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index dc74ee3..13872d4 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -156,11 +156,19 @@ _thread_cleanup_author (notmuch_thread_t *thread,
 char *blank;
 int fname,lname;
 
+if (author == NULL)
+   return NULL;
 clean_author = talloc_strdup(thread, author);
 if (clean_author == NULL)
return NULL;
+/* check if there's a comma in the name and that there's a
+ * component of the name behind it (so the name doesn't end with
+ * the comma - in which case the string that strchr finds is just
+ * one character long ,\0).
+ * Otherwise just return the copy of the original author name that
+ * we just made*/
 comma = strchr(author,',');
-if (comma) {
+if (comma  strlen(comma)  1) {
/* let's assemble what we think is the correct name */
lname = comma - author;
fname = strlen(author) - lname - 2;
@@ -180,7 +188,6 @@ _thread_cleanup_author (notmuch_thread_t *thread,
/* we didn't identify this as part of the email address
* so let's punt and return the original author */
strcpy (clean_author, author);
-
 }
 return clean_author;
 }
-- 
1.6.6.1

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


[PATCH 2/2] Update NEWS to reflect the SEGV bugfix

2010-04-27 Thread Dirk Hohndel

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 NEWS |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index ce0ea45..035e25e 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ Notmuch 0.3.1 (2010-04-27)
 ==
 General bug fix
 ---
+Fix a potential SEGV in notmuch search
+
+  This bug could be triggered by an author name ending in a ','.
+  Admittedly - that's almost certainly a spam email. Still needs
+  to be handled correctly.
+
 Fix an infinite loop in notmuch reply
 
   This bug could be triggered by replying to a message where the
-- 
1.6.6.1

___
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

2010-04-26 Thread 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: More DWIM when editing messages

2010-04-26 Thread 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


[PATCH] RFC: Add From guessing when forwarding email

2010-04-26 Thread 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: More DWIM when editing messages

2010-04-26 Thread 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 <hohn...@infradead.org>
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 2/2] Rearchitect From: header guessing code for replies

2010-04-26 Thread 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, _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 t

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

2010-04-26 Thread 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 (>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 -

For 0.3 - cleaned up patches rebased on origin/master

2010-04-26 Thread 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: More DWIM when editing messages

2010-04-26 Thread 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 <hohn...@infradead.org>
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


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

2010-04-26 Thread Dirk Hohndel
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

Looks like I now have an account on Carl's machine

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

Which is only fair, given that he has gotten himself an account
somewhere else as well :-)

> Something interesting is happening here :-)

Looks to me like some mail address line damage - and local domain
expansion with unqualified email addresses

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH] emacs: More DWIM when editing messages

2010-04-26 Thread Dirk Hohndel
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

/D

> ---
>  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 ( 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 ( arg)
>(interactive "P")
> -- 
> 1.7.0
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

-- 
Dirk Hohndel
Intel Open Source Technology Center


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

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 11:55:33 +0100, David Edmondson  wrote:
> 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.

I think that this is something where we really need a customization - as
my preference is the exact opposite of David's. Since I get email from
so many people it really helps me to understand the context (and who
else an email was sent to) when browsing through mail...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH] RFC: Add From guessing when forwarding email

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 11:43:45 +0100, David Edmondson  wrote:
> 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.

Thanks - I was sure that my lack of elisp foo was showing (even though I
was quite proud that I was able to get it to work at all).

I'll submit an updated patch for the 0.4 merge window.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Some messages show only headers.

2010-04-26 Thread Dirk Hohndel
On Sun, 25 Apr 2010 10:57:10 +0530, Abhishek Dasgupta  
wrote:
> 
> Hi all,
> 
> I've been using notmuch for some time, and I noticed that some mails
> show only the header when pressing [return] on notmuch-show-all. If I
> press [return] on the highlighted From: header then the entire message
> displays.

This may be the bug that David fixed this morning - under some
circumstances mails that matched the search were not displayed until you
either hid and un-hid them or hid the headers.

> Is this behaviour expected? The default behaviour in most other MUAs is
> to show the message in full.

notmuch should show all messages that match the search by default -
other messages in the thread are shown closed.

I think Carl already pushed the fix.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


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

2010-04-26 Thread Dirk Hohndel

This is lacking a committ message...

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

... just saying...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Re: Some messages show only headers.

2010-04-26 Thread Dirk Hohndel
On Sun, 25 Apr 2010 10:57:10 +0530, Abhishek Dasgupta abh...@gmail.com wrote:
 
 Hi all,
 
 I've been using notmuch for some time, and I noticed that some mails
 show only the header when pressing [return] on notmuch-show-all. If I
 press [return] on the highlighted From: header then the entire message
 displays.

This may be the bug that David fixed this morning - under some
circumstances mails that matched the search were not displayed until you
either hid and un-hid them or hid the headers.

 Is this behaviour expected? The default behaviour in most other MUAs is
 to show the message in full.

notmuch should show all messages that match the search by default -
other messages in the thread are shown closed.

I think Carl already pushed the fix.

/D

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


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

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 11:55:33 +0100, David Edmondson d...@dme.org wrote:
 On Sat, 24 Apr 2010 05:42:54 -0700, Carl Worth cwo...@cworth.org wrote:
  On Fri, 23 Apr 2010 21:08:48 +0100, David Edmondson d...@dme.org 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.

I think that this is something where we really need a customization - as
my preference is the exact opposite of David's. Since I get email from
so many people it really helps me to understand the context (and who
else an email was sent to) when browsing through mail...

/D

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

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 15:01:25 +0100, David Edmondson d...@dme.org 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

/D

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

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


For 0.3 - cleaned up patches rebased on origin/master

2010-04-26 Thread 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 1/2] Make Received: header special in notmuch_message_file_get_header

2010-04-26 Thread 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 hohn...@infradead.org
---
 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

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

2010-04-26 Thread 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 em...@add.res) 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 hohn...@infradead.org
---
 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 em...@add.res) 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 em...@add.res 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

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

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 10:28:33 -0700, Carl Worth cwo...@cworth.org wrote:
 On Mon, 26 Apr 2010 09:31:49 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  On Mon, 26 Apr 2010 15:01:25 +0100, David Edmondson d...@dme.org 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 hohn...@infradead.org
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 hohn...@infradead.org
---
 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] RFC: Add From guessing when forwarding email

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 16:27:50 -0700, Carl Worth cwo...@cworth.org wrote:
 On Fri, 23 Apr 2010 15:52:15 -0700, Dirk Hohndel hohn...@infradead.org 
 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


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

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 16:39:44 -0700, Carl Worth cwo...@cworth.org wrote:
 On Mon, 26 Apr 2010 15:28:02 -0700, Dirk Hohndel hohn...@infradead.org 
 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


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

2010-04-26 Thread Dirk Hohndel
On Mon, 26 Apr 2010 20:29:27 -0400, Jesse Rosenthal jrosent...@jhu.edu 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


RFC: Adding an attachment composition interface to notmuch

2010-04-25 Thread Dirk Hohndel
On Sun, 25 Apr 2010 21:06:01 -0400, Jesse Rosenthal  
wrote:
> On Sat, 20 Feb 2010 22:12:21 -0500, Jesse Rosenthal  
> wrote:
> > Tach is a minor mode that adds mutt-like attachment handling to
> > message mode. It's not notmuch specific, but I wrote it to use with
> > notmuch, and I thought it might be of use to some on the list.
> 
> I wanted to see if there would be any interest in adding this to notmuch
> in 0.4 or after. It makes composing messages with attachments much more
> pleasant that using raw mml-mode, and would likely be much more
> accomodating to new users. With the new notmuch-mua hooks, it would be
> easy to turn on and off as well. I've been using it for a number of
> months, and have not had any problems with it.

I have not played with the version you posted earlier - sofar I use the
attachment functionality that Emacs offers by default and I agree that
this is lacking.
>From your description I can't quite tell if tach is overkill,
though. When I just attach a file I'd like to be able to do this just
using the minibuffer to pick a file - not having to open another buffer,
press +, find the file, etc...

> One issue to note: if you start composing a message with tach-mode
> enabled, and then disable it, the attachments you added with tach won't
> get added properly (there will just be a plaintext list of them at the
> the bottom of the message after a separator). In other words, tach
> converts the attachment list on sending, just as message-mode adds
> headers, removes "text follows this line", etc. This doesn't seem like
> an issue to me (a message started by message-mode can't be sent by
> another MUA either) but I did want to bring it to people's attention.

I think that's reasonable

> If there is interest, I would take the necessary steps to integrate it
> and prepare a patch.

I'd be interested to see a notmuch integration...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Re: RFC: Adding an attachment composition interface to notmuch

2010-04-25 Thread Dirk Hohndel
On Sun, 25 Apr 2010 21:06:01 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 On Sat, 20 Feb 2010 22:12:21 -0500, Jesse Rosenthal jrosent...@jhu.edu 
 wrote:
  Tach is a minor mode that adds mutt-like attachment handling to
  message mode. It's not notmuch specific, but I wrote it to use with
  notmuch, and I thought it might be of use to some on the list.
 
 I wanted to see if there would be any interest in adding this to notmuch
 in 0.4 or after. It makes composing messages with attachments much more
 pleasant that using raw mml-mode, and would likely be much more
 accomodating to new users. With the new notmuch-mua hooks, it would be
 easy to turn on and off as well. I've been using it for a number of
 months, and have not had any problems with it.

I have not played with the version you posted earlier - sofar I use the
attachment functionality that Emacs offers by default and I agree that
this is lacking.
From your description I can't quite tell if tach is overkill,
though. When I just attach a file I'd like to be able to do this just
using the minibuffer to pick a file - not having to open another buffer,
press +, find the file, etc...
 
 One issue to note: if you start composing a message with tach-mode
 enabled, and then disable it, the attachments you added with tach won't
 get added properly (there will just be a plaintext list of them at the
 the bottom of the message after a separator). In other words, tach
 converts the attachment list on sending, just as message-mode adds
 headers, removes text follows this line, etc. This doesn't seem like
 an issue to me (a message started by message-mode can't be sent by
 another MUA either) but I did want to bring it to people's attention.

I think that's reasonable

 If there is interest, I would take the necessary steps to integrate it
 and prepare a patch.

I'd be interested to see a notmuch integration...

/D

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


Failing test cases

2010-04-24 Thread Dirk Hohndel
On Sun, 25 Apr 2010 10:17:44 +1000, Jason White  wrote:
> I just tried to build the Debian package from the latest Git master branch,
> but this could not be completed due to failures of test cases 067, 068 and
> 069.
> 
> Are others seeing this, or is it a peculiarity of my system (Debian Sid,
> x86-64)?

No, this is the expected behavior right now. Carl has the habit of
committing the tests before he commits the code that addresses the issue
/ feature that is tested for. And it turned out that there was a bug in
the original version of that code. I have submitted a fixed version but
that hasn't been pushed, yet.

0.3 with all the latest and greatest fixes and cleanups should be out,
shortly. 

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH 7/7] Integrate notmuch-fcc mechansim

2010-04-24 Thread Dirk Hohndel

On Fri, 23 Apr 2010 11:38:57 +0200, Sebastian Spaeth  
wrote:
> I have gone wild and added a defcustom "notmuch-fcc-dirs".
> Depending on the value of that variable we will not do any
> maildir fcc at all (nil, the default), or it is of the format
> (("defaultsentbox")
>  ("full name " . "Work/sentbox")
>  ("full name2 " . "Work2/sentbox"))

I love this feature (unsurprising, as I was the one who requested it
repeatedly...).

One question from the elisp noop:

> +   (let ((subdir (cdr (assoc (message-fetch-field "from") 
> notmuch-fcc-dirs

Why not make this 

(let ((subdir (cdr (assoc-string (message-fetch-field "from") 
notmuch-fcc-dirs t

and have the association be case insensitive?

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 15:05:55 -0700, Dirk Hohndel  
wrote:
> > Dirk also mentioned in IRC that there's a regression with the signature
> > being mispositioned before the quoted text with a reply buffer. Now that
> > I've added a signature, I'm noticing this as well.
> 
> Well - we don't seem to be adding the signature ourselves anymore... I
> still don't quite understand where and how we hand over to the existing
> message-mode functions - I why those decide to insert a signature at
> point.

Learning elisp every day. I think I now understand at least somewhat
what's happening there...

> Here's a trivial patch that ALSO adds a signature at the end of the
> message buffer (where it belongs). But I haven't figured out how to get
> rid of the one above the reply...
> 
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index acb7dbf..493cd0e 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -63,6 +63,7 @@
>  ;; line and then the body.
>  (with-temp-buffer
>(call-process notmuch-command nil t nil "reply" query-string)
> +  (message-insert-signature)
>(goto-char (point-min))
>(if (re-search-forward "^$" nil t)
> (save-excursion

This patch is of course completely bogus. But understanding why it was
bogus helped me come up with this patch, that hopefully makes more
sense. People who ACTUALLY understand elisp - please take a look

(I could have sworn there was a variable somewhere that gives me the
correct regex to search for a signature separator... but I can't find
it. so please replace '-- ' with that if you know)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..05c9603 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -82,7 +82,13 @@
 (message-hide-headers)
 (save-excursion
   (goto-char (point-max))
-  (insert body))
+  (if (re-search-backward "-- " nil t)
+ (progn 
+   (forward-line -1)
+   (insert body))
+   (progn
+ (goto-char (point-max))
+     (insert body
 (set-buffer-modified-p nil)))

 (defun notmuch-mua-forward-message ()


-- 
Dirk Hohndel
Intel Open Source Technology Center


Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 14:45:45 -0700, Carl Worth  wrote:
> > It doesn't for me with origin/master. Or let me double check... what do
> > you think would be the correct order (as this is a matter of taste for
> > some people)...
> 
> The order in the reply buffer is fine. But with "m" I get the User-Agent
> first which looks a bit strange.

Yep, same here.

> Dirk also mentioned in IRC that there's a regression with the signature
> being mispositioned before the quoted text with a reply buffer. Now that
> I've added a signature, I'm noticing this as well.

Well - we don't seem to be adding the signature ourselves anymore... I
still don't quite understand where and how we hand over to the existing
message-mode functions - I why those decide to insert a signature at
point.

Here's a trivial patch that ALSO adds a signature at the end of the
message buffer (where it belongs). But I haven't figured out how to get
rid of the one above the reply...

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..493cd0e 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -63,6 +63,7 @@
 ;; line and then the body.
 (with-temp-buffer
   (call-process notmuch-command nil t nil "reply" query-string)
+  (message-insert-signature)
   (goto-char (point-min))
   (if (re-search-forward "^$" nil t)
  (save-excursion

> > I think we should make this a "requirement" for patches to include a
> > little NEWS blurb and either a test case or an explanation why there
> > isn't a test case...
> 
> I've asked for these, but I haven't been pushing hard on this.

I will start playing the nagger

> Review for some of these simple things would be much appreciated from
> anybody on the list, (and would help ensure that patches are more likely
> to be ready-to-go once I get them). So let's see more of things like
> this from anyone on the list:
> 
>   Looks like a great feature---now it just needs a test case.
> 
>   I've tested this and it does just what I want. Here's a
>   follow-on patch that adds an item to the NEWS file for this.
> 
>   I can't common on the specific logic of the patch, but I did
>   notice some trailing whitespace. You'll want to clean that up
>   and resubmit so the patch won't be rejected.

I can do all of those.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


improve from-header guessing

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 11:47:04 -0700, Carl Worth  wrote:
> On Fri, 16 Apr 2010 13:51:40 -0700, Dirk Hohndel  
> wrote:
> > The following two patches should address most of the concerns raised 
> > to my previous series. 
> 
> Allow me to raise new concerns then. ;-)

Any time

> > The first patch simply adds an interface to obtain a concatenation of
> > all instances of a specific header from an email.
> 
> I was hoping to see the "special-case value of NULL" go away with this
> change.
> 
> And I like that there's a new function to get the concatenated header,
> (I would prefer an unabbreviated name of get_concatenated_header than
> get_header_concat), but I don't like seeing all the existing callers of
> get_header updated to pass an extra 0. Instead, I'd prefer to see those
> calls unchanged, and a tiny new get_header that passes the 0 and then
> make the actual implementing function be static and named something like
> notmuch_message_file_get_header_internal.

Turns out that the way I did this was broken anyway. So we can simply
forget these patches and your concerns. I'm sure you'll raise new
concerns on the new ("rearchitected") patches.

> Both patches have some trailing whitespace. I see these easily wince I
> have the following in my ~/.gitconfig:
> 
>   [core]
>   whitespace = trailing-space,space-before-tab

I know. I'm trying to be better about checking whitespace pollution
before submitting things.

> Finally, I'd like to see some tests for this feature. (But we do have
> the feature already without tests, so I won't strictly block on that).

Hu? You even commited these already. Or am I reading email out of order
again? 

/D


[PATCH 5/5] Simple attempt to display author names in a friendlier way

2010-04-24 Thread Dirk Hohndel
This patch only addresses the typical Outlook/Exchange case
where we have "Last, First"  or
"Last, First MI" .

In the future we should be more fexible as to the formats
we recognize, but for now we address this one as it is the
Exchange default setting and therefore the most common one.

Signed-off-by: Dirk Hohndel 
---
 lib/thread.cc |   51 +--
 1 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index c80bb26..b8be3e1 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -147,6 +147,51 @@ _thread_move_matched_author (notmuch_thread_t *thread,
 return;
 }

+/* clean up the uggly "Lastname, Firstname" format that some mail systems
+ * (most notably, Exchange) are creating to be "Firstname Lastname"
+ * To make sure that we don't change other potential situations where a
+ * comma is in the name, we check that we match one of these patterns
+ * "Last, First" 
+ * "Last, First MI" 
+ */
+char *
+_thread_cleanup_author (notmuch_thread_t *thread,
+   const char *author, const char *from)
+{
+char *clean_author,*test_author;
+const char *comma;
+char *blank;
+int fname,lname;
+
+clean_author = talloc_strdup(thread, author);
+if (clean_author == NULL)
+   return NULL;
+comma = strchr(author,',');
+if (comma) {
+   /* let's assemble what we think is the correct name */
+   lname = comma - author;
+   fname = strlen(author) - lname - 2;
+   strncpy(clean_author, comma + 2, fname);
+   *(clean_author+fname) = ' ';
+   strncpy(clean_author + fname + 1, author, lname);
+   *(clean_author+fname+1+lname) = '\0';
+   /* make a temporary copy and see if it matches the email */
+   test_author = talloc_strdup(thread,clean_author);
+
+   blank=strchr(test_author,' ');
+   while (blank != NULL) {
+   *blank = '.';
+   blank=strchr(test_author,' ');
+   }
+   if (strcasestr(from, test_author) == NULL)
+   /* we didn't identify this as part of the email address
+   * so let's punt and return the original author */
+   strcpy (clean_author, author);
+
+}
+return clean_author;
+}
+
 /* Add 'message' as a message that belongs to 'thread'.
  *
  * The 'thread' will talloc_steal the 'message' and hold onto a
@@ -161,6 +206,7 @@ _thread_add_message (notmuch_thread_t *thread,
 InternetAddressList *list = NULL;
 InternetAddress *address;
 const char *from, *author;
+char *clean_author;

 _notmuch_message_list_add_message (thread->message_list,
   talloc_steal (thread, message));
@@ -183,8 +229,9 @@ _thread_add_message (notmuch_thread_t *thread,
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
}
-   _thread_add_author (thread, author);
-   notmuch_message_set_author (message, author);
+   clean_author = _thread_cleanup_author (thread, author, from);
+   _thread_add_author (thread, clean_author);
+   notmuch_message_set_author (message, clean_author);
}
g_object_unref (G_OBJECT (list));
 }
-- 
1.6.6.1



[PATCH 4/5] Add tests for author name reordering in search results

2010-04-24 Thread Dirk Hohndel
This should be required for all patches :-)

Signed-off-by: Dirk Hohndel 
---
 test/notmuch-test |   28 +++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/test/notmuch-test b/test/notmuch-test
index 7082344..f455232 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -867,6 +867,33 @@ printf " Searching returns all three messages in one 
thread..."
 output=$($NOTMUCH search foo | notmuch_search_sanitize)
 pass_if_equal "$output" "thread:XXX   2000-01-01 [3/3] Notmuch Test Suite; 
brokenthreadtest (inbox unread)"

+printf "\nTesting author reordering;\n"
+printf " Adding parent message...\t\t\t"
+generate_message [body]=findme [id]=new-parent-id 
[subject]=author-reorder-threadtest '[from]="User "' 
'[date]="Sat, 01 Jan 2000 12:00:00 -"'
+output=$(NOTMUCH_NEW)
+pass_if_equal "$output" "Added 1 new message to the database."
+printf " Adding initial child message...\t\t"
+generate_message [body]=findme '[in-reply-to]=\<new-parent-id\>' 
[subject]=author-reorder-threadtest '[from]="User1 "' 
'[date]="Sat, 01 Jan 2000 12:00:00 -"'
+output=$(NOTMUCH_NEW)
+pass_if_equal "$output" "Added 1 new message to the database."
+printf " Adding second child message...\t\t\t"
+generate_message [body]=findme '[in-reply-to]=\<new-parent-id\>' 
[subject]=author-reorder-threadtest '[from]="User2 "' 
'[date]="Sat, 01 Jan 2000 12:00:00 -"'
+output=$(NOTMUCH_NEW)
+pass_if_equal "$output" "Added 1 new message to the database."
+printf " Searching when all three messages match...\t"
+output=$($NOTMUCH search findme | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [3/3] User, User1, User2; 
author-reorder-threadtest (inbox unread)"
+printf " Searching when two messages match...\t\t"
+output=$($NOTMUCH search User1 or User2 | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [2/3] User1, User2| User; 
author-reorder-threadtest (inbox unread)"
+printf " Searching when only one message matches...\t"
+output=$($NOTMUCH search User2 | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [1/3] User2| User, User1; 
author-reorder-threadtest (inbox unread)"
+printf " Searching when only first message matches...\t"
+output=$($NOTMUCH search User | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [1/3] User| User1, User2; 
author-reorder-threadtest (inbox unread)"
+
+printf "\nTesting From line heuristics;\n"
 printf " Magic from guessing (nothing to go on)...\t"
 add_message '[from]="Sender "' \
  [to]=mailinglist at notmuchmail.org \
@@ -965,7 +992,6 @@ References: <${gen_msg_id}>
 On Tue, 05 Jan 2010 15:43:56 -0800, Sender  wrote:
 > from guessing test"

-
 echo ""
 echo "Notmuch test suite complete."

-- 
1.6.6.1



[PATCH 3/5] Add NEWS section for author reordering

2010-04-24 Thread Dirk Hohndel
This should be required in all patches

Signed-off-by: Dirk Hohndel 
---
 NEWS |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index eba0fd5..c2057c2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,13 @@
+
+Visualization of author names that match a search
+
+  When notmuch displays threads as the result of a search, it now
+  lists the authors that match the search before listing the other
+  authors in the thread. It inserts a pipe '|' symbol between the last
+  matching and first non-matching author. This is especially useful in
+  a search that includes tag:unread. Now the authors of the unread
+  messages in the thread are listed first.
+
 Notmuch 0.2 (2010-04-16)
 
 This is the second release of the notmuch mail system, with actual
-- 
1.6.6.1



[PATCH 2/5] Reorder displayed names of thread authors

2010-04-24 Thread Dirk Hohndel
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from the
non-matching ones with a '|' instead of a ','

Imagine the default "+inbox" query. Those mails in the thread that
match the query are actually "new" (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread,
prior to this patch the author column in the search display will first show
"Dirk Hohndel" - I think it should first show the actual author(s) of the new
mail(s).

Signed-off-by: Dirk Hohndel 
---
 lib/thread.cc |   77 +
 1 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index e1da060..c80bb26 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
 char *subject;
 GHashTable *authors_hash;
 char *authors;
+char *nonmatched_authors;
 GHashTable *tags;

 notmuch_message_list_t *message_list;
@@ -73,6 +74,79 @@ _thread_add_author (notmuch_thread_t *thread,
thread->authors = talloc_strdup (thread, author);
 }

+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * existing order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authors_copy;
+char *current_author;
+char *last_pipe,*next_pipe;
+int idx,nm_start,author_len,authors_len;
+
+if (thread->authors == NULL || author == NULL)
+   return;
+if (thread->nonmatched_authors == NULL)
+   thread->nonmatched_authors = thread->authors;
+author_len = strlen(author);
+authors_len = strlen(thread->authors);
+if (author_len == authors_len) {
+   /* just one author */
+   thread->nonmatched_authors += author_len;
+   return;
+}
+current_author = strcasestr(thread->authors, author);
+if (current_author == NULL)
+   return;
+/* how far inside the nonmatched authors is our author? */
+idx = current_author - thread->nonmatched_authors;
+if (idx < 0) {
+   /* already among matched authors */
+   return;
+}
+/* are there any authors in the list after our author? */
+if (thread->nonmatched_authors + author_len < thread->authors + 
authors_len) {
+   /* we have to make changes, so let's get a temp copy */
+   authors_copy = talloc_strdup(thread,thread->authors);
+   /* nm_start is the offset into where the non-matched authors start */
+   nm_start = thread->nonmatched_authors - thread->authors;
+   /* copy this author and add the "| " - the if clause above tells us 
there's more */
+   strncpy(thread->nonmatched_authors,author,author_len);
+   strncpy(thread->nonmatched_authors+author_len,"| ",2);
+   thread->nonmatched_authors += author_len+2;
+   if (idx > 0) {
+ /* we are actually moving authors around, not just changing the 
separator
+  * first copy the authors that came BEFORE our author */
+ strncpy(thread->nonmatched_authors, authors_copy+nm_start, idx-2);
+ /* finally, if there are authors AFTER our author, copy those */
+ if(author_len+nm_start+idx < authors_len) {
+   strncpy(thread->nonmatched_authors + idx - 2,", ",2);
+   strncpy(thread->nonmatched_authors + idx, authors_copy+nm_start + 
idx + author_len + 2,
+   authors_len - (nm_start + idx + author_len + 2));
+ }
+   }
+   /* finally let's make sure there's just one '|' in the authors string */
+   last_pipe = strchr(thread->authors,'|');
+   while (last_pipe) {
+   next_pipe = strchr(last_pipe+1,'|');
+   if (next_pipe)
+   *last_pipe = ',';
+   last_pipe = next_pipe;
+   }
+} else {
+   thread->nonmatched_authors += author_len;
+   /* so now all authors are matched - let's remove the '|' */
+   last_pipe = strchr(thread->authors,'|');
+   if (last_pipe)
+   *last_pipe = ',';
+}
+return;
+}
+
 /* Add 'message' as a message that belongs to 'thread'.
  *
  * The 'thread' will talloc_steal the 'message' and hold onto a
@@ -110,6 +184,7 @@ _thread_add_message (notmuch_thread_t *thread,
author = internet_address_mailbox_get_addr (mailbox);
}
_thread_add_author (thread, author);
+   notmuch_message_set_author (message, author);
}
g_object_unref (G_OBJEC

[PATCH 1/5] Add authors member to message

2010-04-24 Thread Dirk Hohndel
message->authors contains the author's name (as we want to print it)
get / set methods are declared in notmuch-private.h

Signed-off-by: Dirk Hohndel 
---
 lib/message.cc|   18 ++
 lib/notmuch-private.h |   10 ++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..4b2f98f 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
 char *thread_id;
 char *in_reply_to;
 char *filename;
+char *author;
 notmuch_message_file_t *message_file;
 notmuch_message_list_t *replies;
 unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
 message->in_reply_to = NULL;
 message->filename = NULL;
 message->message_file = NULL;
+message->author = NULL;

 message->replies = _notmuch_message_list_create (message);
 if (unlikely (message->replies == NULL)) {
@@ -533,6 +535,22 @@ notmuch_message_get_tags (notmuch_message_t *message)
 return _notmuch_convert_tags(message, i, end);
 }

+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message->author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+   const char *author)
+{
+if (message->author)
+   talloc_free(message->author);
+message->author = talloc_strdup(message, author);
+return;
+}
+
 void
 _notmuch_message_set_date (notmuch_message_t *message,
   const char *date)
diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index 94cce1b..6e83cc3 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -275,6 +275,16 @@ _notmuch_message_talloc_copy_data (notmuch_message_t 
*message);
 void
 _notmuch_message_clear_data (notmuch_message_t *message);

+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message' */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
+
 /* index.cc */

 notmuch_status_t
-- 
1.6.6.1



new patch series for author reordering code

2010-04-24 Thread Dirk Hohndel

I tried to break this out into logically independent pieces - but to connect
this as a series.  
First we add the authors member and accessors to message
Second the reordering of thread authors (still the original string based
algorithm that I used before - I couldn't quite make sense of cworth's proposed
algorithm
Third a NEWS blurb
Fourth test for the new functionality
Fifth a first simple routine to make author names easier to read - this one
undoes the typical Exchange ugliness

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.

I am planning to enhance the "display author names in a friendlier way" feature
in the future, capturing more cases.

/D



[PATCH] Reordering of thread authors to list matching authors first

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:21:53 -0700, Carl Worth  wrote:
> On Wed, 21 Apr 2010 20:58:27 -0700, Dirk Hohndel  
> wrote:
> > When displaying threads as result of a search it makes sense to list those
> > authors first who match the search. The matching authors are separated from 
> > the
> > non-matching ones with a '|' instead of a ','
> 
> It seems a reasonable feature to me.

I switched back to origin/master to help get ready for 0.3 and
tremendously miss this feature :-) 

> Some notes on the patch:
> 
> > +void
> > +notmuch_message_set_author (notmuch_message_t *message,
> > +   const char *author)
> > +{
> > +message->author = talloc_strdup(message, author);
> > +return;
> > +}
> 
> This is leaking any previously set author value, (admittedly, it's only
> a "talloc leak" so it will still get cleaned up when the message is
> cleaned up, but still.

Fixed in forthcoming revision of this patch

> 
> > +/* Set the author member of 'message' - this is the representation used
> > + * when displaying the message
> > + */
> > +void
> > +notmuch_message_set_author (notmuch_message_t *message, const char 
> > *author);
> > +
> > +/* Get the author member of 'message'
> > + */
> > +const char *
> > +notmuch_message_get_author (notmuch_message_t *message);
> 
> The notmuch.h file is our publicly installed header file for the library
> interface. I don't think the feature here requires any new library
> interface. Even if it did, we wouldn't want a public function like
> set_author that could simply scramble internal state and change the
> result of future calls to get_author.

My mistake - moved them to notmuch-private.h

> > +/*
> > + * move authors of matched messages in the thread to 
> > + * the front of the authors list, but keep them in
> > + * existing order within their group
> > + */
> > +static void
> > +_thread_move_matched_author (notmuch_thread_t *thread,
> > +const char *author)
> 
> The implementation here seems a bit fiddly.
> 
> We already have two passes over the messages, (first all messages, and
> then all matched messages). And we're currently calling add_author from
> the first pass.
> 
> How about simply calling a new add_matched_author from the second pass
> which would look very much like the existing add_author. Then we could
> change add_author to accumulate authors into an array rather than a
> string. Then, finally, we would append any of these authors not already
> in the matched_authors hash tabled onto the final string.
> 
> That should be less code and easier to understand I think.
> 
> I can take a whack at that later if you don't beat me to it.

Maybe I'm misunderstanding your proposed algorithm - but it seems quite
a bit more complicated than what I'm doing today...

/D


[PATCH] emacs: Fix i-search to open up invisible citations as necessary

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 07:42:48 -0700, Carl Worth  wrote:
> On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson  wrote:
> > Add an `isearch-open-invisible' property to the overlays used to hide
> > citations and signatures, together with an appropriate function to
> > leave the invisible text visible should that be required.
> 
> This is a fantastic feature, David. Thanks! This is pushed.
> 
> I knew emacs could do this kind of thing, and I had even tried to
> implement it once, but I hadn't succeeded for some reason.
> 
> Next, I wonder if we shouldn't do something similar for the search
> view. It might be quite handy if all authors and all unique subjects for
> a thread were made available for i-search in the buffer, but hidden by
> default and expanded as needed like this. What do you think?

I would love this

/D


[PATCH] Clean up author display for some "Last, First" cases

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 08:30:22 -0700, Carl Worth  wrote:
> On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel  
> wrote:
> > +/* clean up the uggly "Lastname, Firstname" format that some mail systems
> > + * (most notably, Exchange) are creating to be "Firstname Lastname" 
> > + * To make sure that we don't change other potential situations where a 
> > + * comma is in the name, we check that we match one of these patterns
> > + * "Last, First" 
> > + * "Last, First MI" 
> 
> This is an interesting idea. We could make it a little more flexible by
> doing a regexp comparison of "first.*last" against the email address,
> (perhaps people have email addresses like carl_worth at example.com?)

I'll look into that. We actually had some discussion about this on IRC
and I was thinking of taking this feature to a new level... something
like: 
- by default we show names as they come in (least surprise)
- we offer to reverse Last, First
- we offer to shorten to FirstL
- we offer an alias map
So I could define that mail from "cworth at cworth.org" gets the author
listed as "cworth". Or as CarlW.

> > +char *cleanauthor,*testauthor;
> 
> I'd much rather see an underscore separating two words in a single
> identifier, (so clean_author, test_author).

Happy to comply to your preferences in the future

> > +   /* let's assemble what we think is the correct name */
> > +   lname = comma - author;
> > +   fname = strlen(author) - lname - 2;
> > +   strncpy(cleanauthor, comma + 2, fname);
> > +   *(cleanauthor+fname) = ' ';
> > +   strncpy(cleanauthor + fname + 1, author, lname);
> > +   *(cleanauthor+fname+1+lname) = '\0';
> 
> The comment above, ("what we think is the correct name"), didn't help me
> understand what the code is doing. And the code is hard enough to follow
> that I could really use some help. Something like:
> 
> /* Break at comma and reverse: "Last, First etc." -> "First Last etc." */

Ok, I'll try to be more explicit in documenting algorithms

> Lots of little additions here and there so plenty of chance for an
> off-by-one. Do we have a test case for this yet?

Nope. Will do.

> > +   /* make a temporary copy and see if it matches the email */
> > +   testauthor = xstrdup(cleanauthor);
> 
> It would be preferable to use talloc functions consistently. (Existing
> occurrences of xstrdup in the code base are for the sake of
> talloc-unfriendly glib data structures like GHashTable.)
> 
> As is, testauthor is leaking.

Oops.

/D


Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel

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

I sent a patch last night - but it's not realtive to the last thing that
I sent, instead relative to last night's master. Do you want me to
create another one?

Basically, the way I was trying to do concatenation of Received headers
earlier was fundamentally broken - it made assumptions about being able
to continue reading the headers even after we closed the file already.

Not so good.

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

I'll be working on notmuch for the next few hours and once my git trees
are straightened out again, I'll look into what's missing from my wish
list

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

I'll voice my "don't like" of this feature as well, I guess.

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

It doesn't for me with origin/master. Or let me double check... what do
you think would be the correct order (as this is a matter of taste for
some people)...

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

I think we should make this a "requirement" for patches to include a
little NEWS blurb and either a test case or an explanation why there
isn't a test case...

/D


[PATCH] removed unused variables

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:55:09 -0700, Carl Worth  wrote:
> On Thu, 22 Apr 2010 20:26:46 -0700, Dirk Hohndel  
> wrote:
> > 
> > trivial compiler warning fix
> 
> Thanks. I finally caught up to this.
> 
> I had seen this patch from you earlier, when I didn't have a convenient
> working-directory for just applying it---so I've been religiously
> ignoring those warnings ever since rather than just fixing them. ;-)

This is something that I got caught in last night. I have brought in
more patches from others, worked on my own patches, and suddenly I
got stuck in git-branch-hell and couldn't figure out how to move changes
from one branch to another. That's why my reply-guessing-segfault fix is
not relative to my last patch...

I'm trying to clean up my mess this morning :-)

/D


Re: [PATCH] removed unused variables

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:55:09 -0700, Carl Worth cwo...@cworth.org wrote:
 On Thu, 22 Apr 2010 20:26:46 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  
  trivial compiler warning fix
 
 Thanks. I finally caught up to this.
 
 I had seen this patch from you earlier, when I didn't have a convenient
 working-directory for just applying it---so I've been religiously
 ignoring those warnings ever since rather than just fixing them. ;-)

This is something that I got caught in last night. I have brought in
more patches from others, worked on my own patches, and suddenly I
got stuck in git-branch-hell and couldn't figure out how to move changes
from one branch to another. That's why my reply-guessing-segfault fix is
not relative to my last patch...

I'm trying to clean up my mess this morning :-)

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


Re: Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel

On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth cwo...@cworth.org 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

I sent a patch last night - but it's not realtive to the last thing that
I sent, instead relative to last night's master. Do you want me to
create another one?

Basically, the way I was trying to do concatenation of Received headers
earlier was fundamentally broken - it made assumptions about being able
to continue reading the headers even after we closed the file already.

Not so good.
 
   * 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!

I'll be working on notmuch for the next few hours and once my git trees
are straightened out again, I'll look into what's missing from my wish
list

 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?

I'll voice my don't like of this feature as well, I guess.

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

It doesn't for me with origin/master. Or let me double check... what do
you think would be the correct order (as this is a matter of taste for
some people)...

 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.

I think we should make this a requirement for patches to include a
little NEWS blurb and either a test case or an explanation why there
isn't a test case...

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


Re: [PATCH] Clean up author display for some Last, First cases

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 08:30:22 -0700, Carl Worth cwo...@cworth.org wrote:
 On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  +/* clean up the uggly Lastname, Firstname format that some mail systems
  + * (most notably, Exchange) are creating to be Firstname Lastname 
  + * To make sure that we don't change other potential situations where a 
  + * comma is in the name, we check that we match one of these patterns
  + * Last, First first.l...@company.com
  + * Last, First MI first.mi.l...@company.com
 
 This is an interesting idea. We could make it a little more flexible by
 doing a regexp comparison of first.*last against the email address,
 (perhaps people have email addresses like carl_wo...@example.com?)

I'll look into that. We actually had some discussion about this on IRC
and I was thinking of taking this feature to a new level... something
like: 
- by default we show names as they come in (least surprise)
- we offer to reverse Last, First
- we offer to shorten to FirstL
- we offer an alias map
So I could define that mail from cwo...@cworth.org gets the author
listed as cworth. Or as CarlW.

  +char *cleanauthor,*testauthor;
 
 I'd much rather see an underscore separating two words in a single
 identifier, (so clean_author, test_author).

Happy to comply to your preferences in the future

  +   /* let's assemble what we think is the correct name */
  +   lname = comma - author;
  +   fname = strlen(author) - lname - 2;
  +   strncpy(cleanauthor, comma + 2, fname);
  +   *(cleanauthor+fname) = ' ';
  +   strncpy(cleanauthor + fname + 1, author, lname);
  +   *(cleanauthor+fname+1+lname) = '\0';
 
 The comment above, (what we think is the correct name), didn't help me
 understand what the code is doing. And the code is hard enough to follow
 that I could really use some help. Something like:
 
 /* Break at comma and reverse: Last, First etc. - First Last etc. */

Ok, I'll try to be more explicit in documenting algorithms

 Lots of little additions here and there so plenty of chance for an
 off-by-one. Do we have a test case for this yet?

Nope. Will do.

  +   /* make a temporary copy and see if it matches the email */
  +   testauthor = xstrdup(cleanauthor);
 
 It would be preferable to use talloc functions consistently. (Existing
 occurrences of xstrdup in the code base are for the sake of
 talloc-unfriendly glib data structures like GHashTable.)
 
 As is, testauthor is leaking.

Oops.

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


Re: [PATCH] emacs: Fix i-search to open up invisible citations as necessary

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 07:42:48 -0700, Carl Worth cwo...@cworth.org wrote:
 On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson d...@dme.org wrote:
  Add an `isearch-open-invisible' property to the overlays used to hide
  citations and signatures, together with an appropriate function to
  leave the invisible text visible should that be required.
 
 This is a fantastic feature, David. Thanks! This is pushed.
 
 I knew emacs could do this kind of thing, and I had even tried to
 implement it once, but I hadn't succeeded for some reason.
 
 Next, I wonder if we shouldn't do something similar for the search
 view. It might be quite handy if all authors and all unique subjects for
 a thread were made available for i-search in the buffer, but hidden by
 default and expanded as needed like this. What do you think?

I would love this

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


Re: [PATCH] Reordering of thread authors to list matching authors first

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:21:53 -0700, Carl Worth cwo...@cworth.org wrote:
 On Wed, 21 Apr 2010 20:58:27 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  When displaying threads as result of a search it makes sense to list those
  authors first who match the search. The matching authors are separated from 
  the
  non-matching ones with a '|' instead of a ','
 
 It seems a reasonable feature to me.

I switched back to origin/master to help get ready for 0.3 and
tremendously miss this feature :-) 
 
 Some notes on the patch:
 
  +void
  +notmuch_message_set_author (notmuch_message_t *message,
  +   const char *author)
  +{
  +message-author = talloc_strdup(message, author);
  +return;
  +}
 
 This is leaking any previously set author value, (admittedly, it's only
 a talloc leak so it will still get cleaned up when the message is
 cleaned up, but still.

Fixed in forthcoming revision of this patch

 
  +/* Set the author member of 'message' - this is the representation used
  + * when displaying the message
  + */
  +void
  +notmuch_message_set_author (notmuch_message_t *message, const char 
  *author);
  +
  +/* Get the author member of 'message'
  + */
  +const char *
  +notmuch_message_get_author (notmuch_message_t *message);
 
 The notmuch.h file is our publicly installed header file for the library
 interface. I don't think the feature here requires any new library
 interface. Even if it did, we wouldn't want a public function like
 set_author that could simply scramble internal state and change the
 result of future calls to get_author.

My mistake - moved them to notmuch-private.h

  +/*
  + * move authors of matched messages in the thread to 
  + * the front of the authors list, but keep them in
  + * existing order within their group
  + */
  +static void
  +_thread_move_matched_author (notmuch_thread_t *thread,
  +const char *author)
 
 The implementation here seems a bit fiddly.
 
 We already have two passes over the messages, (first all messages, and
 then all matched messages). And we're currently calling add_author from
 the first pass.
 
 How about simply calling a new add_matched_author from the second pass
 which would look very much like the existing add_author. Then we could
 change add_author to accumulate authors into an array rather than a
 string. Then, finally, we would append any of these authors not already
 in the matched_authors hash tabled onto the final string.
 
 That should be less code and easier to understand I think.
 
 I can take a whack at that later if you don't beat me to it.

Maybe I'm misunderstanding your proposed algorithm - but it seems quite
a bit more complicated than what I'm doing today...

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


new patch series for author reordering code

2010-04-24 Thread Dirk Hohndel

I tried to break this out into logically independent pieces - but to connect
this as a series.  
First we add the authors member and accessors to message
Second the reordering of thread authors (still the original string based
algorithm that I used before - I couldn't quite make sense of cworth's proposed
algorithm
Third a NEWS blurb
Fourth test for the new functionality
Fifth a first simple routine to make author names easier to read - this one
undoes the typical Exchange ugliness

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.

I am planning to enhance the display author names in a friendlier way feature
in the future, capturing more cases.

/D

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


[PATCH 2/5] Reorder displayed names of thread authors

2010-04-24 Thread Dirk Hohndel
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from the
non-matching ones with a '|' instead of a ','

Imagine the default +inbox query. Those mails in the thread that
match the query are actually new (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread,
prior to this patch the author column in the search display will first show
Dirk Hohndel - I think it should first show the actual author(s) of the new
mail(s).

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 lib/thread.cc |   77 +
 1 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index e1da060..c80bb26 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
 char *subject;
 GHashTable *authors_hash;
 char *authors;
+char *nonmatched_authors;
 GHashTable *tags;
 
 notmuch_message_list_t *message_list;
@@ -73,6 +74,79 @@ _thread_add_author (notmuch_thread_t *thread,
thread-authors = talloc_strdup (thread, author);
 }
 
+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * existing order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authors_copy;
+char *current_author;
+char *last_pipe,*next_pipe;
+int idx,nm_start,author_len,authors_len;
+
+if (thread-authors == NULL || author == NULL)
+   return;
+if (thread-nonmatched_authors == NULL)
+   thread-nonmatched_authors = thread-authors;
+author_len = strlen(author);
+authors_len = strlen(thread-authors);
+if (author_len == authors_len) {
+   /* just one author */
+   thread-nonmatched_authors += author_len;
+   return;
+}
+current_author = strcasestr(thread-authors, author);
+if (current_author == NULL)
+   return;
+/* how far inside the nonmatched authors is our author? */
+idx = current_author - thread-nonmatched_authors;
+if (idx  0) {
+   /* already among matched authors */
+   return;
+}
+/* are there any authors in the list after our author? */
+if (thread-nonmatched_authors + author_len  thread-authors + 
authors_len) {
+   /* we have to make changes, so let's get a temp copy */
+   authors_copy = talloc_strdup(thread,thread-authors);
+   /* nm_start is the offset into where the non-matched authors start */
+   nm_start = thread-nonmatched_authors - thread-authors;
+   /* copy this author and add the |  - the if clause above tells us 
there's more */
+   strncpy(thread-nonmatched_authors,author,author_len);
+   strncpy(thread-nonmatched_authors+author_len,| ,2);
+   thread-nonmatched_authors += author_len+2;
+   if (idx  0) {
+ /* we are actually moving authors around, not just changing the 
separator
+  * first copy the authors that came BEFORE our author */
+ strncpy(thread-nonmatched_authors, authors_copy+nm_start, idx-2);
+ /* finally, if there are authors AFTER our author, copy those */
+ if(author_len+nm_start+idx  authors_len) {
+   strncpy(thread-nonmatched_authors + idx - 2,, ,2);
+   strncpy(thread-nonmatched_authors + idx, authors_copy+nm_start + 
idx + author_len + 2,
+   authors_len - (nm_start + idx + author_len + 2));
+ }
+   }
+   /* finally let's make sure there's just one '|' in the authors string */
+   last_pipe = strchr(thread-authors,'|');
+   while (last_pipe) {
+   next_pipe = strchr(last_pipe+1,'|');
+   if (next_pipe)
+   *last_pipe = ',';
+   last_pipe = next_pipe;
+   }
+} else {
+   thread-nonmatched_authors += author_len;
+   /* so now all authors are matched - let's remove the '|' */
+   last_pipe = strchr(thread-authors,'|');
+   if (last_pipe)
+   *last_pipe = ',';
+}
+return;
+}
+
 /* Add 'message' as a message that belongs to 'thread'.
  *
  * The 'thread' will talloc_steal the 'message' and hold onto a
@@ -110,6 +184,7 @@ _thread_add_message (notmuch_thread_t *thread,
author = internet_address_mailbox_get_addr (mailbox);
}
_thread_add_author (thread, author);
+   notmuch_message_set_author (message, author);
}
g_object_unref (G_OBJECT (list));
 }
@@ -182,6 +257,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,
notmuch_message_set_flag (hashed_message

[PATCH 1/5] Add authors member to message

2010-04-24 Thread Dirk Hohndel
message-authors contains the author's name (as we want to print it)
get / set methods are declared in notmuch-private.h

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 lib/message.cc|   18 ++
 lib/notmuch-private.h |   10 ++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..4b2f98f 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
 char *thread_id;
 char *in_reply_to;
 char *filename;
+char *author;
 notmuch_message_file_t *message_file;
 notmuch_message_list_t *replies;
 unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
 message-in_reply_to = NULL;
 message-filename = NULL;
 message-message_file = NULL;
+message-author = NULL;
 
 message-replies = _notmuch_message_list_create (message);
 if (unlikely (message-replies == NULL)) {
@@ -533,6 +535,22 @@ notmuch_message_get_tags (notmuch_message_t *message)
 return _notmuch_convert_tags(message, i, end);
 }
 
+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message-author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+   const char *author)
+{
+if (message-author)
+   talloc_free(message-author);
+message-author = talloc_strdup(message, author);
+return;
+}
+
 void
 _notmuch_message_set_date (notmuch_message_t *message,
   const char *date)
diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index 94cce1b..6e83cc3 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -275,6 +275,16 @@ _notmuch_message_talloc_copy_data (notmuch_message_t 
*message);
 void
 _notmuch_message_clear_data (notmuch_message_t *message);
 
+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message' */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
+
 /* index.cc */
 
 notmuch_status_t
-- 
1.6.6.1

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


[PATCH 3/5] Add NEWS section for author reordering

2010-04-24 Thread Dirk Hohndel
This should be required in all patches

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 NEWS |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index eba0fd5..c2057c2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,13 @@
+
+Visualization of author names that match a search
+
+  When notmuch displays threads as the result of a search, it now
+  lists the authors that match the search before listing the other
+  authors in the thread. It inserts a pipe '|' symbol between the last
+  matching and first non-matching author. This is especially useful in
+  a search that includes tag:unread. Now the authors of the unread
+  messages in the thread are listed first.
+
 Notmuch 0.2 (2010-04-16)
 
 This is the second release of the notmuch mail system, with actual
-- 
1.6.6.1

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


[PATCH 5/5] Simple attempt to display author names in a friendlier way

2010-04-24 Thread Dirk Hohndel
This patch only addresses the typical Outlook/Exchange case
where we have Last, First first.l...@company.com or
Last, First MI first.mi.l...@company.com.

In the future we should be more fexible as to the formats
we recognize, but for now we address this one as it is the
Exchange default setting and therefore the most common one.

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 lib/thread.cc |   51 +--
 1 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index c80bb26..b8be3e1 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -147,6 +147,51 @@ _thread_move_matched_author (notmuch_thread_t *thread,
 return;
 }
 
+/* clean up the uggly Lastname, Firstname format that some mail systems
+ * (most notably, Exchange) are creating to be Firstname Lastname
+ * To make sure that we don't change other potential situations where a
+ * comma is in the name, we check that we match one of these patterns
+ * Last, First first.l...@company.com
+ * Last, First MI first.mi.l...@company.com
+ */
+char *
+_thread_cleanup_author (notmuch_thread_t *thread,
+   const char *author, const char *from)
+{
+char *clean_author,*test_author;
+const char *comma;
+char *blank;
+int fname,lname;
+
+clean_author = talloc_strdup(thread, author);
+if (clean_author == NULL)
+   return NULL;
+comma = strchr(author,',');
+if (comma) {
+   /* let's assemble what we think is the correct name */
+   lname = comma - author;
+   fname = strlen(author) - lname - 2;
+   strncpy(clean_author, comma + 2, fname);
+   *(clean_author+fname) = ' ';
+   strncpy(clean_author + fname + 1, author, lname);
+   *(clean_author+fname+1+lname) = '\0';
+   /* make a temporary copy and see if it matches the email */
+   test_author = talloc_strdup(thread,clean_author);
+
+   blank=strchr(test_author,' ');
+   while (blank != NULL) {
+   *blank = '.';
+   blank=strchr(test_author,' ');
+   }
+   if (strcasestr(from, test_author) == NULL)
+   /* we didn't identify this as part of the email address
+   * so let's punt and return the original author */
+   strcpy (clean_author, author);
+
+}
+return clean_author;
+}
+
 /* Add 'message' as a message that belongs to 'thread'.
  *
  * The 'thread' will talloc_steal the 'message' and hold onto a
@@ -161,6 +206,7 @@ _thread_add_message (notmuch_thread_t *thread,
 InternetAddressList *list = NULL;
 InternetAddress *address;
 const char *from, *author;
+char *clean_author;
 
 _notmuch_message_list_add_message (thread-message_list,
   talloc_steal (thread, message));
@@ -183,8 +229,9 @@ _thread_add_message (notmuch_thread_t *thread,
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
}
-   _thread_add_author (thread, author);
-   notmuch_message_set_author (message, author);
+   clean_author = _thread_cleanup_author (thread, author, from);
+   _thread_add_author (thread, clean_author);
+   notmuch_message_set_author (message, clean_author);
}
g_object_unref (G_OBJECT (list));
 }
-- 
1.6.6.1

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


Re: improve from-header guessing

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 11:47:04 -0700, Carl Worth cwo...@cworth.org wrote:
 On Fri, 16 Apr 2010 13:51:40 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  The following two patches should address most of the concerns raised 
  to my previous series. 
 
 Allow me to raise new concerns then. ;-)

Any time
 
  The first patch simply adds an interface to obtain a concatenation of
  all instances of a specific header from an email.
 
 I was hoping to see the special-case value of NULL go away with this
 change.
 
 And I like that there's a new function to get the concatenated header,
 (I would prefer an unabbreviated name of get_concatenated_header than
 get_header_concat), but I don't like seeing all the existing callers of
 get_header updated to pass an extra 0. Instead, I'd prefer to see those
 calls unchanged, and a tiny new get_header that passes the 0 and then
 make the actual implementing function be static and named something like
 notmuch_message_file_get_header_internal.

Turns out that the way I did this was broken anyway. So we can simply
forget these patches and your concerns. I'm sure you'll raise new
concerns on the new (rearchitected) patches.

 Both patches have some trailing whitespace. I see these easily wince I
 have the following in my ~/.gitconfig:
 
   [core]
   whitespace = trailing-space,space-before-tab

I know. I'm trying to be better about checking whitespace pollution
before submitting things.

 Finally, I'd like to see some tests for this feature. (But we do have
 the feature already without tests, so I won't strictly block on that).

Hu? You even commited these already. Or am I reading email out of order
again? 

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


Re: Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 14:45:45 -0700, Carl Worth cwo...@cworth.org wrote:
  It doesn't for me with origin/master. Or let me double check... what do
  you think would be the correct order (as this is a matter of taste for
  some people)...
 
 The order in the reply buffer is fine. But with m I get the User-Agent
 first which looks a bit strange.

Yep, same here.
 
 Dirk also mentioned in IRC that there's a regression with the signature
 being mispositioned before the quoted text with a reply buffer. Now that
 I've added a signature, I'm noticing this as well.

Well - we don't seem to be adding the signature ourselves anymore... I
still don't quite understand where and how we hand over to the existing
message-mode functions - I why those decide to insert a signature at
point.

Here's a trivial patch that ALSO adds a signature at the end of the
message buffer (where it belongs). But I haven't figured out how to get
rid of the one above the reply...

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..493cd0e 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -63,6 +63,7 @@
 ;; line and then the body.
 (with-temp-buffer
   (call-process notmuch-command nil t nil reply query-string)
+  (message-insert-signature)
   (goto-char (point-min))
   (if (re-search-forward ^$ nil t)
  (save-excursion

  I think we should make this a requirement for patches to include a
  little NEWS blurb and either a test case or an explanation why there
  isn't a test case...
 
 I've asked for these, but I haven't been pushing hard on this.

I will start playing the nagger
 
 Review for some of these simple things would be much appreciated from
 anybody on the list, (and would help ensure that patches are more likely
 to be ready-to-go once I get them). So let's see more of things like
 this from anyone on the list:
 
   Looks like a great feature---now it just needs a test case.
 
   I've tested this and it does just what I want. Here's a
   follow-on patch that adds an item to the NEWS file for this.
 
   I can't common on the specific logic of the patch, but I did
   notice some trailing whitespace. You'll want to clean that up
   and resubmit so the patch won't be rejected.

I can do all of those.

/D

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


Re: Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 15:05:55 -0700, Dirk Hohndel hohn...@infradead.org wrote:
  Dirk also mentioned in IRC that there's a regression with the signature
  being mispositioned before the quoted text with a reply buffer. Now that
  I've added a signature, I'm noticing this as well.
 
 Well - we don't seem to be adding the signature ourselves anymore... I
 still don't quite understand where and how we hand over to the existing
 message-mode functions - I why those decide to insert a signature at
 point.

Learning elisp every day. I think I now understand at least somewhat
what's happening there...
 
 Here's a trivial patch that ALSO adds a signature at the end of the
 message buffer (where it belongs). But I haven't figured out how to get
 rid of the one above the reply...
 
 diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
 index acb7dbf..493cd0e 100644
 --- a/emacs/notmuch-mua.el
 +++ b/emacs/notmuch-mua.el
 @@ -63,6 +63,7 @@
  ;; line and then the body.
  (with-temp-buffer
(call-process notmuch-command nil t nil reply query-string)
 +  (message-insert-signature)
(goto-char (point-min))
(if (re-search-forward ^$ nil t)
 (save-excursion

This patch is of course completely bogus. But understanding why it was
bogus helped me come up with this patch, that hopefully makes more
sense. People who ACTUALLY understand elisp - please take a look

(I could have sworn there was a variable somewhere that gives me the
correct regex to search for a signature separator... but I can't find
it. so please replace '-- ' with that if you know)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..05c9603 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -82,7 +82,13 @@
 (message-hide-headers)
 (save-excursion
   (goto-char (point-max))
-  (insert body))
+  (if (re-search-backward --  nil t)
+ (progn 
+   (forward-line -1)
+   (insert body))
+   (progn
+ (goto-char (point-max))
+ (insert body
 (set-buffer-modified-p nil)))
 
 (defun notmuch-mua-forward-message ()


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


Re: [PATCH 7/7] Integrate notmuch-fcc mechansim

2010-04-24 Thread Dirk Hohndel

On Fri, 23 Apr 2010 11:38:57 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 I have gone wild and added a defcustom notmuch-fcc-dirs.
 Depending on the value of that variable we will not do any
 maildir fcc at all (nil, the default), or it is of the format
 ((defaultsentbox)
  (full name em...@address . Work/sentbox)
  (full name2 ema...@address2 . Work2/sentbox))

I love this feature (unsurprising, as I was the one who requested it
repeatedly...).

One question from the elisp noop:

 +   (let ((subdir (cdr (assoc (message-fetch-field from) 
 notmuch-fcc-dirs

Why not make this 

(let ((subdir (cdr (assoc-string (message-fetch-field from) 
notmuch-fcc-dirs t

and have the association be case insensitive?

/D

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


[PATCH] Rearchitect the way the Received: header is concatenated

2010-04-23 Thread Dirk Hohndel

The previous implementation misunderstood the way the message file
was handled. Under certain circumstances this could cause SEGVs as
we were trying to keep reading from the file after it was closed.

Now we treat the Received: header as special and always concatenate
it when parsing the headers.

Signed-off-by: Dirk Hohndel 
---
 lib/message-file.c|   53 -
 lib/notmuch-private.h |3 +
 lib/notmuch.h |   16 ++
 notmuch-reply.c   |  125 +
 4 files changed, 154 insertions(+), 43 deletions(-)

diff --git a/lib/message-file.c b/lib/message-file.c
index 0c152a3..75b3990 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -209,16 +209,23 @@ 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, received;
 static int initialized = 0;
+
+received = (strcmp(header_desired,"received") == 0);

 if (! initialized) {
g_mime_init (0);
@@ -312,22 +319,34 @@ notmuch_message_file_get_header (notmuch_message_file_t 
*message,

NEXT_HEADER_LINE (>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);
+   if (strcmp(header,"received") == 0) {
+   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);
+   } else {
+   /* the caller wants them all concatenated */
+   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 (match && !received)
return decoded_value;
 }

@@ -347,6 +366,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 (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.h
index 94cce1b..69298e7 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -334,6 +334,9 @@ notmuch_message_file_restrict_headersv 
(notmuch_message_file_t *message,
  *
  * The header name is case insensitive.
  *
+ * The "received" header is special - for it all received h

[PATCH] RFC: Add From guessing when forwarding email

2010-04-23 Thread Dirk Hohndel

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.

Given how little elisp I know I'm quite interested in feedback
and better implementations

Signed-off-by: Dirk Hohndel 
---
 emacs/notmuch-show.el |8 +++-
 notmuch-client.h  |3 +
 notmuch-reply.c   |  110 +
 notmuch.c |8 
 4 files changed, 127 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 53af301..8cec9e8 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -809,8 +809,12 @@ any effects from previous calls to
 (defun notmuch-show-forward-message ()
   "Forward the current message."
   (interactive)
-  (with-current-notmuch-show-message
-   (notmuch-mua-forward-message)))
+  (progn
+(let ((message-id (notmuch-show-get-message-id)))
+  (with-current-notmuch-show-message
+   (progn
+(setq user-mail-address (shell-command-to-string (concat "notmuch 
guess-from " message-id)))
+(notmuch-mua-forward-message))

 (defun notmuch-show-next-message ()
   "Show the next message."
diff --git a/notmuch-client.h b/notmuch-client.h
index 20be43b..ba5b002 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -93,6 +93,9 @@ int
 notmuch_reply_command (void *ctx, int argc, char *argv[]);

 int
+notmuch_guess_from_command (void *ctx, int argc, char *argv[]);
+
+int
 notmuch_restore_command (void *ctx, int argc, char *argv[]);

 int
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 230cacc..e9c8449 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -364,6 +364,55 @@ guess_from_received_header (notmuch_config_t *config, 
notmuch_message_t *message
 return NULL;
 }

+/*
+ * simply figure out the best from address to use without creating
+ * a reply buffer or anything else
+ */
+static const char *
+notmuch_guess_from(notmuch_config_t *config, notmuch_query_t *query)
+{
+notmuch_messages_t *messages;
+notmuch_message_t *message;
+InternetAddressList *list;
+InternetAddressMailbox *mailbox;
+InternetAddress *address;
+char *recipients;
+const char *addr;
+const char *from_addr = NULL;
+int i;
+
+for (messages = notmuch_query_search_messages (query);
+notmuch_messages_valid (messages);
+notmuch_messages_move_to_next (messages))
+{
+   message = notmuch_messages_get (messages);
+   if ((asprintf (, "%s,%s", notmuch_message_get_header 
(message, "to"),
+  notmuch_message_get_header (message, "cc")) == -1) || 
recipients == NULL) {
+   fprintf (stderr, "Out of memory\n");
+   return NULL;
+   }
+   list = internet_address_list_parse_string (recipients);
+   for (i = 0; i < internet_address_list_length (list); i++) {
+   address = internet_address_list_get_address (list, i);
+   if (! INTERNET_ADDRESS_IS_GROUP (address)) {
+   mailbox = INTERNET_ADDRESS_MAILBOX (address);
+   addr = internet_address_mailbox_get_addr (mailbox);
+   if (address_is_users (addr, config) && !from_addr) {
+   from_addr = addr;
+   break;
+   }
+   }
+   }
+   free (recipients);
+   if (from_addr == NULL)
+   from_addr = guess_from_received_header (config, message);
+
+   if (from_addr == NULL)
+   from_addr = notmuch_config_get_user_primary_email (config);
+}
+return from_addr;
+}
+
 static int
 notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
 {
@@ -567,3 +616,64 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])

 return ret;
 }
+
+int
+notmuch_guess_from_command (void *ctx, int argc, char *argv[])
+{
+notmuch_config_t *config;
+notmuch_database_t *notmuch;
+notmuch_query_t *query;
+char *query_string;
+char const *addr;
+int i, ret = 0;
+
+for (i = 0; i < argc && argv[i][0] == '-'; i++) {
+   if (strcmp (argv[i], "--") == 0) {
+   i++;
+   break;
+   }
+   fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
+   return 1;
+}
+
+argc -= i;
+argv += i;
+
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+   return 1;
+
+query_string = query_string_from_args (ctx, argc, argv);
+if (query_string == NULL) {
+   fprintf (stderr, "Out of memory\n");
+   return 1;
+}
+
+if (*query_string == '\0') {
+   fprintf (stderr, "Error: notmuch reply requires at least one search 
term.\n");
+   return 1;
+}
+
+notmuch = notmuch_database_open (notmuch_config_get_database_path (config),
+NOTMUCH_DATABASE_MO

[PATCH] Add NEWS updates for my last batch of patches

2010-04-23 Thread Dirk Hohndel

in the future I'll include those with my patches. Hope it's ok to do
this as one single patch for this series.

Signed-off-by: Dirk Hohndel 
---
 NEWS |   35 +++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index eba0fd5..5586386 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,38 @@
+
+Even Better guessing of From: header.
+
+  Notmuch now looks at a number of headers when trying to figure out
+  the best From: header to use in a reply. First it checks whether one
+  of the user's emails is in To: or Cc:, then it checks Envelope-To:
+  and X-Original-To: headers, then it analyses the Received headers
+  checking for a Received: by .. from .. for user at add.res clause. And
+  finally it matches domains in the received path.
+
+Visualization of author names that match a search
+
+  When notmuch displays threads as the result of a search, it now
+  lists the authors that match the search before listing the other
+  authors in the thread. It inserts a pipe '|' symbol between the last
+  matching and first non-matching author. This is especially useful in
+  a search that includes tag:unread. Now the authors of the unread
+  messages in the thread are listed first.
+
+Provide 'd' key binding to add the 'deleted' tag to messages and threads
+
+  The 'd' key works wherever 'a'rchive works - it performs the same
+  actions but additionally sets the deleted tag.
+
+Provide 'G' key binding to trigger mail refresh
+
+  The 'G' key works wherever '=' works. Before refreshing the screen
+  it calls an external program that can be used to poll email servers,
+  run notmuch new and setup specific tags for the new emails. The
+  script to be called can be customized with. Use the customize screen
+  to set the notmuch-poll-script variable to the program that you want
+  to execute when pressing 'G'. Note that this is synchronous - emacs
+  will wait until this program finishes.
+
+
 Notmuch 0.2 (2010-04-16)
 
 This is the second release of the notmuch mail system, with actual
-- 
1.6.6.1


-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH] Add 'G' keybinding to folder and search view that triggers external poll

2010-04-23 Thread Dirk Hohndel
On Fri, 23 Apr 2010 08:20:40 -0700, Carl Worth  wrote:
> On Fri, 23 Apr 2010 10:09:03 +0200, "Sebastian Spaeth"  SSpaeth.de> wrote:
> > Hehe. Very useful indeed. There is one more thing: Would it be possible to 
> > provide user
> > feedback while this is running (synchronously, I guess)? Like having
> > some message in the minibuffer saying "Calling all stations" and
> > "Polling finished, please move along..." ?
> 
> Anything is possible, of course. It just always seems to mean someone
> learning a bit more elisp. ;-)

I'm working on that. Check back in a few months :-)

> In the meantime, I've found it handy to put my mouse pointer over the
> emacs window when I run this command. Then I get a nice "busy" mouse
> cursor during this operation instead of the standard text-edit bar.

That's what I'm doing as well.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


  1   2   3   >