Plans for the 0.2 release (this week)

[Carl Worth]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> For the upcoming 0.2 release, here are some things that I would like to
> have in place:
> 
>   * Any further changes from the Sebastian's repository. Sebastian, I
> worked through one list I saw recently. Do you have another list to
> propose yet?

Sebastian sent a list of these, and they are merged now.

>   * The big batch of emacs-client improvements from David E.'s
> repository. David, do you have particular things to recommend
> here?

David has no followed up with a rebase of his entire branch. It looks
*very* nice still but won't be in 0.2. I plan to land this early and
make it the focus of the 0.3 release.

>   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
> is stuff that I'll work on.

I haven't gotten to this yet. It's a big change, (in that it requires
everyone to rebuild their database). So this will need some careful
testing. And I'd like to get as many changes in at once so we won't all
have to rebuild are databases in the following release. This stuff will
be the focus of the 0.4 release.

>   * Some library additions (move_to_first for the iterators, and perhaps
> a notmuch_database_add_message_with_data which Srinivasa requested
> to support integration of notmuch into evolution). I'll work on
> these as well, (I know that there are patches for some of these on
> the list already).

I'll take a look at the existing patches for the iterators. That's still
0.2 material. The add_message_with_data feature will come later.

>   * Anything else that people want, (especially things that already
> exist and that you're already using).

Thanks for several suggestions in reply to this message. I think they
are all merged now. Let me know if I missed anything.

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

Plans for the 0.2 release (this week)

[Carl Worth]

On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins  wrote:
> I would really like to see the patch in spaetz/issue15-handle-fcc-bcc
> applied soon.  This is the lingering issue of bcc'ing the primary email
> address in notmuch replies, which I think really needs to be removed.
> 
> Let me know if there are any issues.  I'm pretty sure this will apply
> cleanly against the head without a rebase.

I'm happy to remove the Bcc thing, but only *after* we have an Fcc
approach integrated into the emacs client by default, (without users
having to configure it, download python scripts, etc.).

And yes, I know the current Bcc approach is still quite useless, because
it only triggers on replies, (and not when composing a new message from
the emacs client).

I'm looking forward to seeing this all fixed, but I haven't yet seen a
"packaged" solution.

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

Plans for the 0.2 release (this week)

[Carl Worth]

On Thu, 08 Apr 2010 09:47:00 +0200, "Sebastian Spaeth"  wrote:
> First of all, thanks for the great work Carl. I have to admit I was
> getting nervous about the backlog of patches, but your recent committing
> binge (you did say your work patterns are bursty :-)) made me very happy.

You're quite welcome. And the big backlog was making me nervous too.

I'm not sure that the backlog has gotten any smaller yet, but I'm really
happy with where things are going. I seem to have created a code hydra,
where every time I merge one patch, people get excited to and send me
three more patches.

> That having said, I am glad to meet your expectation: "I expect people
>  to remind me of their favorite features that haven't been merged..."
>  :-)

Thanks for the very useful list, Sebastian. These are all merged now,
(as mentioned in the replies I've made to the original messages with the
patches).

> >   * Some library additions (move_to_first for the iterators,
> +1!

That one I've got noted on a separate list.

> All the rest souds very good.

I really do need a thread-splitting feature in order to use notmuch as
my feature tracker. A list like the above of "6 trivial patches to
merge" is easy to handle as a single item. I can send a message like
this one saying "I'm done with this list".

But several different people did reply to my original "plans for 0.2"
call for features. So the single thread I have for this in my "notmuch
merge window" search is not doing the trick.

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

Re: Plans for the 0.2 release (this week)

[Carl Worth]

On Thu, 08 Apr 2010 09:47:00 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 First of all, thanks for the great work Carl. I have to admit I was
 getting nervous about the backlog of patches, but your recent committing
 binge (you did say your work patterns are bursty :-)) made me very happy.

You're quite welcome. And the big backlog was making me nervous too.

I'm not sure that the backlog has gotten any smaller yet, but I'm really
happy with where things are going. I seem to have created a code hydra,
where every time I merge one patch, people get excited to and send me
three more patches.

 That having said, I am glad to meet your expectation: I expect people
  to remind me of their favorite features that haven't been merged...
  :-)

Thanks for the very useful list, Sebastian. These are all merged now,
(as mentioned in the replies I've made to the original messages with the
patches).

* Some library additions (move_to_first for the iterators,
 +1!

That one I've got noted on a separate list.

 All the rest souds very good.

I really do need a thread-splitting feature in order to use notmuch as
my feature tracker. A list like the above of 6 trivial patches to
merge is easy to handle as a single item. I can send a message like
this one saying I'm done with this list.

But several different people did reply to my original plans for 0.2
call for features. So the single thread I have for this in my notmuch
merge window search is not doing the trick.

-Carl


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

Re: Plans for the 0.2 release (this week)

[Carl Worth]

On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
 I would really like to see the patch in spaetz/issue15-handle-fcc-bcc
 applied soon.  This is the lingering issue of bcc'ing the primary email
 address in notmuch replies, which I think really needs to be removed.
 
 Let me know if there are any issues.  I'm pretty sure this will apply
 cleanly against the head without a rebase.

I'm happy to remove the Bcc thing, but only *after* we have an Fcc
approach integrated into the emacs client by default, (without users
having to configure it, download python scripts, etc.).

And yes, I know the current Bcc approach is still quite useless, because
it only triggers on replies, (and not when composing a new message from
the emacs client).

I'm looking forward to seeing this all fixed, but I haven't yet seen a
packaged solution.

-Carl


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

Re: Plans for the 0.2 release (this week)

[Carl Worth]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
 For the upcoming 0.2 release, here are some things that I would like to
 have in place:
 
   * Any further changes from the Sebastian's repository. Sebastian, I
 worked through one list I saw recently. Do you have another list to
 propose yet?

Sebastian sent a list of these, and they are merged now.

   * The big batch of emacs-client improvements from David E.'s
 repository. David, do you have particular things to recommend
 here?

David has no followed up with a rebase of his entire branch. It looks
*very* nice still but won't be in 0.2. I plan to land this early and
make it the focus of the 0.3 release.

   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
 is stuff that I'll work on.

I haven't gotten to this yet. It's a big change, (in that it requires
everyone to rebuild their database). So this will need some careful
testing. And I'd like to get as many changes in at once so we won't all
have to rebuild are databases in the following release. This stuff will
be the focus of the 0.4 release.

   * Some library additions (move_to_first for the iterators, and perhaps
 a notmuch_database_add_message_with_data which Srinivasa requested
 to support integration of notmuch into evolution). I'll work on
 these as well, (I know that there are patches for some of these on
 the list already).

I'll take a look at the existing patches for the iterators. That's still
0.2 material. The add_message_with_data feature will come later.

   * Anything else that people want, (especially things that already
 exist and that you're already using).

Thanks for several suggestions in reply to this message. I think they
are all merged now. Let me know if I missed anything.

-Carl


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

Plans for the 0.2 release (this week)

[Mike Kelly]

On Thu, Apr 08, 2010 at 10:34:59AM -0400, Mike Kelly wrote:
> On Wed, Apr 07, 2010 at 11:23:14PM +0100, James Westby wrote:
> > On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> > >   * Anything else that people want, (especially things that already
> > > exist and that you're already using). Support for maildir flags on
> > > import would be great here. I'm still waiting to see a complete
> > > solution I think.
> > 
> > id:1268515677-12692-1-git-send-email-jw+debian at jameswestby.net
> 
> I haven't tested yet, but this is definitely a feature I want/need (due
> to the... unique behavior of a certain bug tracker I use at work).

I've now tested this patch, and it appears to work properly. Thanks!

-- 
Mike Kelly

Re: Plans for the 0.2 release (this week)

[Mike Kelly]

On Thu, Apr 08, 2010 at 10:34:59AM -0400, Mike Kelly wrote:
 On Wed, Apr 07, 2010 at 11:23:14PM +0100, James Westby wrote:
  On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
 * Anything else that people want, (especially things that already
   exist and that you're already using). Support for maildir flags on
   import would be great here. I'm still waiting to see a complete
   solution I think.
  
  id:1268515677-12692-1-git-send-email-jw+deb...@jameswestby.net
 
 I haven't tested yet, but this is definitely a feature I want/need (due
 to the... unique behavior of a certain bug tracker I use at work).

I've now tested this patch, and it appears to work properly. Thanks!

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

Plans for the 0.2 release (this week)

[Michal Sojka]

On Sat, 10 Apr 2010, Jameson Rollins wrote:
> On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka  
> wrote:
> > On Sat, 10 Apr 2010, Carl n?tmuch ? Worth wrote:
> > > Are you all trying to show a problem here? All of the above comes
> > > through fine. Perhaps it's only with non-ASCII in the From line being
> > > replied to? 
> > 
> > Yes and also in Subject line. You can test this with
> > id:87r5o1etjb.fsf at steelpick.localdomain.
> 
> Again, this subject line shows up fine for me in notmuch-show in emacs.
> I believe the non-ASCII characters in headers have to be escaped for
> mail handlers to properly handle them, and the reader should translate.
> I need to find a reference for this...

Yes. It is displayed correctly in notmuch-show mode, but try to reply
(press 'r') to the message and you will see. If you do not see it in
emacs, try running

  notmuch reply id:87r5o1etjb.fsf at steelpick.localdomain

and you will see the encoded headers. There is no problem with sending
such a mail. All recipients will see the headers decoded correctly. The
problem is, that I (the one who writes the reply) do not know what is
written in subject and what are the names of non-ascii named recipients.

If notmuch reply command decodes the headers, as implemented by the
patch, then Emacs (or some other part of mail sending chain?) will
encode the headers again before the message is actually sent.

-Michal

Plans for the 0.2 release (this week)

[Sebastian Spaeth]

On 2010-04-10, Carl n?tmuch ? Worth wrote:
> Are you all trying to show a problem here? All of the above comes
> through fine. Perhaps it's only with non-ASCII in the From line being
> replied to? Let's test that here...

I think there are 2 issues being discussed here. One is the encoding in
the subject line (which does not look pretty in compose mail, but seems
to be the standard). I did not refer to that.

What I referred to was the json output as the encode_as_json_string (or
however it is called), simply drops chars >127, leading to missing
letters in e.g. the author names etc. I could see that in the web
frontends that are making use of json already, and once (if?) emacs uses
the json output too, this will become an issue there too.

Certainly not urgent, but it looked quite weird in the web frontends.

Sebastian

Plans for the 0.2 release (this week)

[Michal Sojka]

On Sat, 10 Apr 2010, Carl n?tmuch ? Worth wrote:
> > On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth"  > SSpaeth.de> wrote:
> > > On 2010-04-09, Michal Sojka wrote:
> > > Perhaps Carl should get more N?rw?g?a? friends, :-).
> > 
> > Or G?rm?n or ??
> 
> Are you all trying to show a problem here? All of the above comes
> through fine. Perhaps it's only with non-ASCII in the From line being
> replied to? 

Yes and also in Subject line. You can test this with
id:87r5o1etjb.fsf at steelpick.localdomain.

Michal

Plans for the 0.2 release (this week)

[Jameson Rollins]

On Sat, 10 Apr 2010 15:52:04 +0200, "Sebastian Spaeth"  wrote:
> frontends that are making use of json already, and once (if?) emacs uses
> the json output too, this will become an issue there too.

once, not if!

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

Plans for the 0.2 release (this week)

[Jameson Rollins]

On Sat, 10 Apr 2010 09:06:54 -0400, Jameson Rollins  wrote:
> Again, this subject line shows up fine for me in notmuch-show in emacs.
> I believe the non-ASCII characters in headers have to be escaped for
> mail handlers to properly handle them, and the reader should translate.
> I need to find a reference for this...

I think this is the relevant RFC:

http://tools.ietf.org/html/rfc5335

Basically, I think that emacs is doing the right thing here.  This isn't
a notmuch issue at all.  The headers have to be encoded this way for the
MTAs.  Your reader (ie. emacs) should be doing the translation for you.

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

Plans for the 0.2 release (this week)

[Jameson Rollins]

On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka  wrote:
> On Sat, 10 Apr 2010, Carl n?tmuch ? Worth wrote:
> > Are you all trying to show a problem here? All of the above comes
> > through fine. Perhaps it's only with non-ASCII in the From line being
> > replied to? 
> 
> Yes and also in Subject line. You can test this with
> id:87r5o1etjb.fsf at steelpick.localdomain.

Again, this subject line shows up fine for me in notmuch-show in emacs.
I believe the non-ASCII characters in headers have to be escaped for
mail handlers to properly handle them, and the reader should translate.
I need to find a reference for this...

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

Plans for the 0.2 release (this week)

[Jameson Rollins]

On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel  
wrote:
> On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel  
> wrote:
> > 
> > here's what's going wrong. Look at the To: line...
> 
> Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth ,

The To: line shows up fine in notmuch-show for me (in emacs).  It only
shows up like this when editing.  I think this is actually a general
mail issue, and is not a notmuch issue.  I don't understand all the
issues, but I think non-ASCII characters in headers have to be encoded,
and that's what you're seeing.

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

Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Sat, 10 Apr 2010 15:52:04 +0200, "Sebastian Spaeth"  wrote:
> On 2010-04-10, Carl n?tmuch ? Worth wrote:
> > Are you all trying to show a problem here? All of the above comes
> > through fine. Perhaps it's only with non-ASCII in the From line being
> > replied to? Let's test that here...
> 
> I think there are 2 issues being discussed here. One is the encoding in
> the subject line (which does not look pretty in compose mail, but seems
> to be the standard). I did not refer to that.

That's the issue I refer to. Yes, it needs to be decoded for the actual
mail transport. But it should be displayed correctly not only in the
summary view but also in the message buffer when responding to an email.

> What I referred to was the json output as the encode_as_json_string (or
> however it is called), simply drops chars >127, leading to missing
> letters in e.g. the author names etc. I could see that in the web
> frontends that are making use of json already, and once (if?) emacs uses
> the json output too, this will become an issue there too.

Separate issue that almost certainly has a different cause.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Sat, 10 Apr 2010 09:05:00 -0400, Jameson Rollins  wrote:
> On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel  
> wrote:
> > On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel  
> > wrote:
> > > 
> > > here's what's going wrong. Look at the To: line...
> > 
> > Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth ,
> 
> The To: line shows up fine in notmuch-show for me (in emacs).  It only
> shows up like this when editing.  I think this is actually a general
> mail issue, and is not a notmuch issue.  I don't understand all the
> issues, but I think non-ASCII characters in headers have to be encoded,
> and that's what you're seeing.

Yes, I understand the RFCs and encoding fairly well. That wasn't my
point. The point is that for some reason we display the encoded text
shown above in the Messages Mode buffer, instead of displaying the
non-ASCII characters as we (IMHO) should.

Maybe this is an issue of different versions of Emacs behaving slightly
differently as Carl seems not to have this issue...

I'm on GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.18.6)
 of 2010-01-14 on x86-02.phx2.fedoraproject.org

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[Michael Elkins]

On Sat, Apr 10, 2010 at 09:06:54AM -0400, Jameson Rollins wrote:
> Again, this subject line shows up fine for me in notmuch-show in emacs.
> I believe the non-ASCII characters in headers have to be escaped for
> mail handlers to properly handle them, and the reader should translate.
> I need to find a reference for this...

http://tools.ietf.org/html/rfc2047

The problem is not the MTA, but the fact that the sender and recipient
may be using different character sets.  There is no way to decode it
properly unless the sender specifies the character set.

me

Re: Plans for the 0.2 release (this week)

[Michal Sojka]

On Sat, 10 Apr 2010, Carl n∅tmuch 䚳 Worth wrote:
  On Fri, 09 Apr 2010 09:35:07 +0200, Sebastian Spaeth 
  sebast...@sspaeth.de wrote:
   On 2010-04-09, Michal Sojka wrote:
   Perhaps Carl should get more Nørwég¡añ friends, :-).
  
  Or Görmän or 中文
 
 Are you all trying to show a problem here? All of the above comes
 through fine. Perhaps it's only with non-ASCII in the From line being
 replied to? 

Yes and also in Subject line. You can test this with
id:87r5o1etjb@steelpick.localdomain.

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

Re: Plans for the 0.2 release (this week)

[Jameson Rollins]

On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel hohn...@infradead.org wrote:
 On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  
  here's what's going wrong. Look at the To: line...
 
 Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth cwo...@cworth.org,

The To: line shows up fine in notmuch-show for me (in emacs).  It only
shows up like this when editing.  I think this is actually a general
mail issue, and is not a notmuch issue.  I don't understand all the
issues, but I think non-ASCII characters in headers have to be encoded,
and that's what you're seeing.

jamie.


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

Re: Plans for the 0.2 release (this week)

[Jameson Rollins]

On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
 On Sat, 10 Apr 2010, Carl n∅tmuch 䚳 Worth wrote:
  Are you all trying to show a problem here? All of the above comes
  through fine. Perhaps it's only with non-ASCII in the From line being
  replied to? 
 
 Yes and also in Subject line. You can test this with
 id:87r5o1etjb@steelpick.localdomain.

Again, this subject line shows up fine for me in notmuch-show in emacs.
I believe the non-ASCII characters in headers have to be escaped for
mail handlers to properly handle them, and the reader should translate.
I need to find a reference for this...

jamie.


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

Re: Plans for the 0.2 release (this week)

[Sebastian Spaeth]

On 2010-04-10, Carl n∅tmuch 䚳 Worth wrote:
 Are you all trying to show a problem here? All of the above comes
 through fine. Perhaps it's only with non-ASCII in the From line being
 replied to? Let's test that here...

I think there are 2 issues being discussed here. One is the encoding in
the subject line (which does not look pretty in compose mail, but seems
to be the standard). I did not refer to that.

What I referred to was the json output as the encode_as_json_string (or
however it is called), simply drops chars 127, leading to missing
letters in e.g. the author names etc. I could see that in the web
frontends that are making use of json already, and once (if?) emacs uses
the json output too, this will become an issue there too.

Certainly not urgent, but it looked quite weird in the web frontends.

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

Re: Plans for the 0.2 release (this week)

[Jameson Rollins]

On Sat, 10 Apr 2010 15:52:04 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 frontends that are making use of json already, and once (if?) emacs uses
 the json output too, this will become an issue there too.

once, not if!

jamie.


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

Re: Plans for the 0.2 release (this week)

[Michael Elkins]

On Sat, Apr 10, 2010 at 09:06:54AM -0400, Jameson Rollins wrote:
 Again, this subject line shows up fine for me in notmuch-show in emacs.
 I believe the non-ASCII characters in headers have to be escaped for
 mail handlers to properly handle them, and the reader should translate.
 I need to find a reference for this...

http://tools.ietf.org/html/rfc2047

The problem is not the MTA, but the fact that the sender and recipient
may be using different character sets.  There is no way to decode it
properly unless the sender specifies the character set.

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

Re: Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Sat, 10 Apr 2010 09:05:00 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel hohn...@infradead.org 
  wrote:
   
   here's what's going wrong. Look at the To: line...
  
  Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth cwo...@cworth.org,
 
 The To: line shows up fine in notmuch-show for me (in emacs).  It only
 shows up like this when editing.  I think this is actually a general
 mail issue, and is not a notmuch issue.  I don't understand all the
 issues, but I think non-ASCII characters in headers have to be encoded,
 and that's what you're seeing.

Yes, I understand the RFCs and encoding fairly well. That wasn't my
point. The point is that for some reason we display the encoded text
shown above in the Messages Mode buffer, instead of displaying the
non-ASCII characters as we (IMHO) should.

Maybe this is an issue of different versions of Emacs behaving slightly
differently as Carl seems not to have this issue...

I'm on GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.18.6)
 of 2010-01-14 on x86-02.phx2.fedoraproject.org

/D

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

Re: Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Sat, 10 Apr 2010 15:52:04 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On 2010-04-10, Carl n∅tmuch 䚳 Worth wrote:
  Are you all trying to show a problem here? All of the above comes
  through fine. Perhaps it's only with non-ASCII in the From line being
  replied to? Let's test that here...
 
 I think there are 2 issues being discussed here. One is the encoding in
 the subject line (which does not look pretty in compose mail, but seems
 to be the standard). I did not refer to that.

That's the issue I refer to. Yes, it needs to be decoded for the actual
mail transport. But it should be displayed correctly not only in the
summary view but also in the message buffer when responding to an email.
 
 What I referred to was the json output as the encode_as_json_string (or
 however it is called), simply drops chars 127, leading to missing
 letters in e.g. the author names etc. I could see that in the web
 frontends that are making use of json already, and once (if?) emacs uses
 the json output too, this will become an issue there too.

Separate issue that almost certainly has a different cause.

/D

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

Re: Plans for the 0.2 release (this week)

[Michal Sojka]

On Sat, 10 Apr 2010, Jameson Rollins wrote:
 On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
  On Sat, 10 Apr 2010, Carl n∅tmuch 䚳 Worth wrote:
   Are you all trying to show a problem here? All of the above comes
   through fine. Perhaps it's only with non-ASCII in the From line being
   replied to? 
  
  Yes and also in Subject line. You can test this with
  id:87r5o1etjb@steelpick.localdomain.
 
 Again, this subject line shows up fine for me in notmuch-show in emacs.
 I believe the non-ASCII characters in headers have to be escaped for
 mail handlers to properly handle them, and the reader should translate.
 I need to find a reference for this...

Yes. It is displayed correctly in notmuch-show mode, but try to reply
(press 'r') to the message and you will see. If you do not see it in
emacs, try running

  notmuch reply id:87r5o1etjb@steelpick.localdomain

and you will see the encoded headers. There is no problem with sending
such a mail. All recipients will see the headers decoded correctly. The
problem is, that I (the one who writes the reply) do not know what is
written in subject and what are the names of non-ascii named recipients.

If notmuch reply command decodes the headers, as implemented by the
patch, then Emacs (or some other part of mail sending chain?) will
encode the headers again before the message is actually sent.

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

Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel  
wrote:
> 
> here's what's going wrong. Look at the To: line...

Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth ,

that's not pretty... nor readable.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[Dirk Hohndel]

here's what's going wrong. Look at the To: line...

/D

On Fri, 09 Apr 2010 20:06:09 -0700, Carl n?tmuch ? Worth  
wrote:
> > On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth"  > SSpaeth.de> wrote:
> > > On 2010-04-09, Michal Sojka wrote:
> > > Perhaps Carl should get more N?rw?g?a? friends, :-).
> > 
> > Or G?rm?n or ??
> 
> Are you all trying to show a problem here? All of the above comes
> through fine. Perhaps it's only with non-ASCII in the From line being
> replied to? Let's test that here...
> 
> -Carl
> 
> PS. How about this for something interesting from Unicode:
> 
> ? Definition in English: do not know, to know nothing about, quickly;
> fast, sharp; keen
Non-text part: application/pgp-signature

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[Carl n∅tmuch 䚳 Worth]

> On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth"  SSpaeth.de> wrote:
> > On 2010-04-09, Michal Sojka wrote:
> > Perhaps Carl should get more N?rw?g?a? friends, :-).
> 
> Or G?rm?n or ??

Are you all trying to show a problem here? All of the above comes
through fine. Perhaps it's only with non-ASCII in the From line being
replied to? Let's test that here...

-Carl

PS. How about this for something interesting from Unicode:

? Definition in English: do not know, to know nothing about, quickly;
fast, sharp; keen
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Plans for the 0.2 release (this week)

[Anthony Towns]

On Fri, Apr 9, 2010 at 00:03, Jameson Rollins
 wrote:
> Presumably others must be annoyed about having to manually "read" and
> archive all their sent mail, unless there's some other way that people
> having been dealing with this that I'm not aware of.

I haven't switched over to notmuch properly yet, but in my initial
import of my mail I made a couple of patches to notmuch new that let
me get the tags right first. One was to make:

notmuch new --initial-tags=list,unread

set the initial tags for newly found messages to "list" and "unread"
instead of the default "inbox" and "unread".

The other was to make:

find Mail/.Saved/ -type f | notmuch new --initial-tags=archived --file-list

only process the mail files listed on stdin (via find), and give them
the explicit tags I specify. That way I could import all my existing
archived mail without it appearing in my inbox or as unread.

Unfortunately the second one ended up complicated and a bit slow (I
think because I'm doing a talloc() for every line on stdin, and
talloc_free() by context every time the base directory changes; that
sort of behaviour was necessary in order to do duplicate checking in a
sane way)

But anyway, that would let you do:

find Mail/.Drafts/ -type f | notmuch new --initial-tags=draft --file-list
notmuch new

to get drafts correctly tagged.

(I don't have the patches handy at the moment; but can certainly dig
them up if there's interest)

Cheers,
aj

-- 
Anthony Towns 

Plans for the 0.2 release (this week)

[micah anderson]

On 2010-04-08, micah anderson wrote:
> On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> > For the upcoming 0.2 release, here are some things that I would like to
> > have in place:
> > 
> >   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
> > is stuff that I'll work on.
> 
> Also, fwiw, the folder: indexing is probably the new feature that I'm
> most eagerly awaiting.  I've got all these ideas for ways to handle sent
> mail and drafts if we can get this working.

+1 on folder: capability!

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

Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth"  wrote:
> On 2010-04-09, Michal Sojka wrote:
> > "Decode headers in reply"
> > (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another
> > patch, which is quite essential to me. Am I the only one here, who needs
> > to reply to messages with non-ASCII characters?
> 
> Nope, and it looks currently very ugly. Having a good solution for that
> problem would be nice indeed.
> 
> Perhaps Carl should get more N?rw?g?a? friends, :-).

Or G?rm?n or ??

Yes, I ran into that myself as my brother's first name is J?rgen and he
complained about my emails to him suddenly being mangled...

But then, Sebastian doesn't even spell his own last name correctly :-)

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[Sebastian Spaeth]

On 2010-04-09, Michal Sojka wrote:
> "Decode headers in reply"
> (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another
> patch, which is quite essential to me. Am I the only one here, who needs
> to reply to messages with non-ASCII characters?

Nope, and it looks currently very ugly. Having a good solution for that
problem would be nice indeed.

Perhaps Carl should get more N?rw?g?a? friends, :-).

spaetz

Plans for the 0.2 release (this week)

[Michal Sojka]

On Wed, 07 Apr 2010, Carl Worth wrote:
>   * Anything else that people want, (especially things that already
> exist and that you're already using). Support for maildir flags on
> import would be great here. I'm still waiting to see a complete
> solution I think.
> 
> So keep the patches coming, and the pointers to patches that you want me
> to look at.

"Decode headers in reply"
(id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another
patch, which is quite essential to me. Am I the only one here, who needs
to reply to messages with non-ASCII characters?

-Michal

Plans for the 0.2 release (this week)

[Michal Sojka]

On Fri, 09 Apr 2010, Anthony Towns wrote:
> On Fri, Apr 9, 2010 at 00:03, Jameson Rollins
>  wrote:
> > Presumably others must be annoyed about having to manually "read" and
> > archive all their sent mail, unless there's some other way that people
> > having been dealing with this that I'm not aware of.
> 
> I haven't switched over to notmuch properly yet, but in my initial
> import of my mail I made a couple of patches to notmuch new that let
> me get the tags right first. One was to make:
> 
> notmuch new --initial-tags=list,unread
> 
> set the initial tags for newly found messages to "list" and "unread"
> instead of the default "inbox" and "unread".
> 
> The other was to make:
> 
> find Mail/.Saved/ -type f | notmuch new --initial-tags=archived 
> --file-list
> 
> only process the mail files listed on stdin (via find), and give them
> the explicit tags I specify. That way I could import all my existing
> archived mail without it appearing in my inbox or as unread.

Hmm, quite interesting feature. I think that several people asked for
this in the past. I'd be happy to see the patches.

-Michal

Re: Plans for the 0.2 release (this week)

[micah anderson]

On 2010-04-08, micah anderson wrote:
 On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
  For the upcoming 0.2 release, here are some things that I would like to
  have in place:
  
* Changes to indexing, (addition of body:, folder:, list:, etc.). This
  is stuff that I'll work on.
 
 Also, fwiw, the folder: indexing is probably the new feature that I'm
 most eagerly awaiting.  I've got all these ideas for ways to handle sent
 mail and drafts if we can get this working.

+1 on folder: capability!

micah


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

Re: Plans for the 0.2 release (this week)

[Dirk Hohndel]

here's what's going wrong. Look at the To: line...

/D

On Fri, 09 Apr 2010 20:06:09 -0700, Carl n∅tmuch 䚳 Worth cwo...@cworth.org 
wrote:
  On Fri, 09 Apr 2010 09:35:07 +0200, Sebastian Spaeth 
  sebast...@sspaeth.de wrote:
   On 2010-04-09, Michal Sojka wrote:
   Perhaps Carl should get more Nørwég¡añ friends, :-).
  
  Or Görmän or 中文
 
 Are you all trying to show a problem here? All of the above comes
 through fine. Perhaps it's only with non-ASCII in the From line being
 replied to? Let's test that here...
 
 -Carl
 
 PS. How about this for something interesting from Unicode:
 
 䚳 Definition in English: do not know, to know nothing about, quickly;
 fast, sharp; keen
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

Re: Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel hohn...@infradead.org wrote:
 
 here's what's going wrong. Look at the To: line...

Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth cwo...@cworth.org,

that's not pretty... nor readable.

/D

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

Plans for the 0.2 release (this week)

[Anthony Towns]

On Thu, Apr 8, 2010 at 17:47, Sebastian Spaeth  wrote:
> * Prevent data loss caused by SIGINT during notmuch new
> ?mail id:1269937403-8495-1-git-send-email-sojkam1 at fel.cvut.cz
> ?wentasah, commit dcb7a957027837f187f06d31fdcddb3740b2c20b
> ?(preventable data loss, has happened to him at least once)

That seems to be a different id to
http://patchwork.notmuchmail.org/patch/445/ but "me too" on that,
fwiw. (Haven't had data loss, did have confusing behaviour that I
attribute to this, and the logic for the patch seems sound to me)

Cheers,
aj

-- 
Anthony Towns 

Plans for the 0.2 release (this week)

[Mike Kelly]

On Thu, 08 Apr 2010 14:28:20 -0700
Carl Worth  wrote:

>   2. A "list:" prefix to match content from headers that identify
>  mailing list. My perception is that there are likely a handful of
>  different headers that have been used, and they should all be
>  indexed so that "list:" will search any of them.

Almost all modern mailing list software seems to use List-Id:

https://tools.ietf.org/html/rfc2919

-- 
Mike Kelly

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

Plans for the 0.2 release (this week)

[Jameson Rollins]

On Thu, 08 Apr 2010 14:28:20 -0700, Carl Worth  wrote:
> All of that sounds quite easy to do by simply saving the draft within
> the mailstore and giving it a "draft" tag.

The only way I can see to give drafts a "draft" tag is via 'folder:'
indexing.  Do you have any ideas of other ways?

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

Plans for the 0.2 release (this week)

[Michal Sojka]

On Thu, 08 Apr 2010, Dirk Hohndel wrote:
> On Thu, 08 Apr 2010 10:03:15 -0400, Jameson Rollins  finestructure.net> wrote:
> > On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> > > For the upcoming 0.2 release, here are some things that I would like to
> > > have in place:
> > > 
> > >   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
> > > is stuff that I'll work on.
> > 
> > Also, fwiw, the folder: indexing is probably the new feature that I'm
> > most eagerly awaiting.  I've got all these ideas for ways to handle sent
> > mail and drafts if we can get this working.
> 
> Maybe I am missing some context here - what exactly does 'indexing' mean
> here?

Indexing means calling notmuch new. The folder: patch, adds "folder:"
search prefix which allows searching for messages based on the folder
where the message is stored e.g. folder:sent.

-Michal

Plans for the 0.2 release (this week)

[Michal Sojka]

On Wed, 07 Apr 2010, Carl Worth wrote:
> For the upcoming 0.2 release, here are some things that I would like to
> have in place:
> 
>   * Anything else that people want, (especially things that already
> exist and that you're already using). Support for maildir flags on
> import would be great here. I'm still waiting to see a complete
> solution I think.

This would be useful: id:m1my03gsmu.fsf at watt.gilman.jhu.edu. I use it
occasionally.

-Michal

draft handling [was: Re: Plans for the 0.2 release (this week)]

[Jameson Rollins]

On Thu, 08 Apr 2010 07:58:47 -0700, Dirk Hohndel  
wrote:
> > And as for drafts, they could be easily indexed and managed by the UI if
> > the folder: search term is available.
> 
> Hmm - haven't even thought about drafts, yet. How would the UI deal with
> those? 

My idea is the following:

Currently for me drafts are stored in ~/.mail/drafts.  If we have
folder: searching, then I can starting indexing my drafts directory and
apply the following post-new filter:

notmuch tag +draft -inbox -unread -- folder:drafts

I'll then make a simple elisp "resume" function that is available for
resuming draft messages, that would be available when viewing messages

Plans for the 0.2 release (this week)

[Mike Kelly]

On Thu, Apr 08, 2010 at 10:03:15AM -0400, Jameson Rollins wrote:
> On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> > For the upcoming 0.2 release, here are some things that I would like to
> > have in place:
> > 
> >   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
> > is stuff that I'll work on.
> 
> Also, fwiw, the folder: indexing is probably the new feature that I'm
> most eagerly awaiting.  I've got all these ideas for ways to handle sent
> mail and drafts if we can get this working.

For me this, along with handling maildir flags, are pretty much my top
"must haves" before I think I would be able to begin to replace
mutt/whatever with notmuch.

-- 
Mike Kelly

Plans for the 0.2 release (this week)

[Mike Kelly]

On Wed, Apr 07, 2010 at 11:23:14PM +0100, James Westby wrote:
> On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> >   * Anything else that people want, (especially things that already
> > exist and that you're already using). Support for maildir flags on
> > import would be great here. I'm still waiting to see a complete
> > solution I think.
> 
> id:1268515677-12692-1-git-send-email-jw+debian at jameswestby.net

I haven't tested yet, but this is definitely a feature I want/need (due
to the... unique behavior of a certain bug tracker I use at work).

-- 
Mike Kelly

Plans for the 0.2 release (this week)

[Jameson Rollins]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> For the upcoming 0.2 release, here are some things that I would like to
> have in place:
> 
>   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
> is stuff that I'll work on.

Also, fwiw, the folder: indexing is probably the new feature that I'm
most eagerly awaiting.  I've got all these ideas for ways to handle sent
mail and drafts if we can get this working.

Presumably others must be annoyed about having to manually "read" and
archive all their sent mail, unless there's some other way that people
having been dealing with this that I'm not aware of.

And as for drafts, they could be easily indexed and managed by the UI if
the folder: search term is available.

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

Plans for the 0.2 release (this week)

[Jameson Rollins]

Hey, Carl.  I'm very encouraged by the recent patch-apply fest, and the
proposal for more regular releases.  I have some new improvements I'll
try to get in at some point, but in the mean time...

> So keep the patches coming, and the pointers to patches that you want me
> to look at.

I would really like to see the patch in spaetz/issue15-handle-fcc-bcc
applied soon.  This is the lingering issue of bcc'ing the primary email
address in notmuch replies, which I think really needs to be removed.

Let me know if there are any issues.  I'm pretty sure this will apply
cleanly against the head without a rebase.

jamie.

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

Plans for the 0.2 release (this week)

[Sebastian Spaeth]

First of all, thanks for the great work Carl. I have to admit I was
getting nervous about the backlog of patches, but your recent committing
binge (you did say your work patterns are bursty :-)) made me very happy.

That having said, I am glad to meet your expectation: "I expect people
 to remind me of their favorite features that haven't been merged..."
 :-)

>   * Any further changes from the Sebastian's repository. Sebastian, I
> worked through one list I saw recently. Do you have another list to
> propose yet?

One of the things I have seen no comment on yet, is the
"json_quote_str should handle non-ASCII characters" patch in 
id:1267697893-sup-4538 at sam.mediasupervision.de.

Right now, every char > 127 will simply be suppressed, this patch fixes
this for me but I cannot comment on its correctness. I rebased the patch
to current here:
http://github.com/spaetz/notmuch-all-feature/commit/3b5423fbdda5e78414e6f2e441cad5394173e155

Would that be an acceptable fix?

Also, as part of getting the useful backlog down, I propose these smallish
patches that are in my tree in the feature/misc branch (that I all grabbed from 
the mailing list):

* Add count command to manual page, Sandra Snan
  mail id:4ba29058.0f67f10a.2b59.1a73 at mx.google.com
  commit 2f5ea4c76dc9688b2520c8d64ac8617ba8a62f86
  (it was really missing)

* Fix typo in notmuch.h documentation regarding database open modes 
  mail id:1269628757-24857-1-git-send-email-michael at obberon.com
  michaelforney, comit 3262b39f58ab4865c0c0cada69955ad65fccdfd9
  (our beloved notmuch.h is WRONG!!! :-)

* Prevent data loss caused by SIGINT during notmuch new
  mail id:1269937403-8495-1-git-send-email-sojkam1 at fel.cvut.cz
  wentasah, commit dcb7a957027837f187f06d31fdcddb3740b2c20b
  (preventable data loss, has happened to him at least once)

* Do not segfault on empty mime parts, 
  mail id:1267543888-18134-1-git-send-email-madduck at madduck.net
  martin f. krafft, commit bb310c6397a94f6f59b6f93b232bedd833f96090
  (probably a bug in gmime, but we should not crash)

>   * Some library additions (move_to_first for the iterators,
+1!

All the rest souds very good.

Sebastian

Plans for the 0.2 release (this week)

[David Edmondson]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
>   * The big batch of emacs-client improvements from David E.'s
> repository. David, do you have particular things to recommend here?

It's necessary for me to merge with your latest batch of changes. That
won't happen until next week, when I can set aside a few hours. (The
merge is somewhat painful, as I have modified versions of some of the
recently applied patches in my tree.)

I worry about committing the JSON based Emacs UI and then immediately
producing a release - it would be useful to have more people test it
from git HEAD before dropping it on an unsuspecting public.

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

Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Thu, 08 Apr 2010 10:03:15 -0400, Jameson Rollins  wrote:
> On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> > For the upcoming 0.2 release, here are some things that I would like to
> > have in place:
> > 
> >   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
> > is stuff that I'll work on.
> 
> Also, fwiw, the folder: indexing is probably the new feature that I'm
> most eagerly awaiting.  I've got all these ideas for ways to handle sent
> mail and drafts if we can get this working.

Maybe I am missing some context here - what exactly does 'indexing' mean
here?

> Presumably others must be annoyed about having to manually "read" and
> archive all their sent mail, unless there's some other way that people
> having been dealing with this that I'm not aware of.

my import/tagging script deals with +sent on emails that I've sent and
removes -inbox -unread on them. The FCC logic gets them filed into a
Sent folder (right now just one - see previous comment about making this
>From address dependent)

> And as for drafts, they could be easily indexed and managed by the UI if
> the folder: search term is available.

Hmm - haven't even thought about drafts, yet. How would the UI deal with
those? 

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins  wrote:
> > So keep the patches coming, and the pointers to patches that you want me
> > to look at.
> 
> I would really like to see the patch in spaetz/issue15-handle-fcc-bcc
> applied soon.  This is the lingering issue of bcc'ing the primary email
> address in notmuch replies, which I think really needs to be removed.

+1

The FCC solution is much more sane. Especially with the From address
based path selection that I proposed (but haven't been able to implement
for lack of Lisp skills)

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Thu, 08 Apr 2010 09:13:20 +0100, David Edmondson  wrote:
> On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> >   * The big batch of emacs-client improvements from David E.'s
> > repository. David, do you have particular things to recommend here?
> 
> It's necessary for me to merge with your latest batch of changes. That
> won't happen until next week, when I can set aside a few hours. (The
> merge is somewhat painful, as I have modified versions of some of the
> recently applied patches in my tree.)

I hope that this will be a less frequent thing to happen as Carl is
quicker in picking up patches. I'm very eager to see the emacs client
improvements, though.

> I worry about committing the JSON based Emacs UI and then immediately
> producing a release - it would be useful to have more people test it
> from git HEAD before dropping it on an unsuspecting public.

Not sure how much of an "unsuspecting public" we have at this
point... but in general this is of course valid. The question is "what
are releases". Or what does it mean to "release 0.2". I don't think we
have the notion of a stable branch and a development cycle,
yet. Everything is development (correct me if I'm wrong, Carl)

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Plans for the 0.2 release (this week)

[James Westby]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
>   * Anything else that people want, (especially things that already
> exist and that you're already using). Support for maildir flags on
> import would be great here. I'm still waiting to see a complete
> solution I think.

id:1268515677-12692-1-git-send-email-jw+debian at jameswestby.net

I've been running with this locally since then with no apparent issues.

It will make anyone who suffers from this problem regularly pretty
happy, as they can return to the world of a thread-based mail client.

Thanks,

James

Re: Plans for the 0.2 release (this week)

[Sebastian Spaeth]

First of all, thanks for the great work Carl. I have to admit I was
getting nervous about the backlog of patches, but your recent committing
binge (you did say your work patterns are bursty :-)) made me very happy.

That having said, I am glad to meet your expectation: I expect people
 to remind me of their favorite features that haven't been merged...
 :-)

   * Any further changes from the Sebastian's repository. Sebastian, I
 worked through one list I saw recently. Do you have another list to
 propose yet?

One of the things I have seen no comment on yet, is the
json_quote_str should handle non-ASCII characters patch in 
id:1267697893-sup-4...@sam.mediasupervision.de.

Right now, every char  127 will simply be suppressed, this patch fixes
this for me but I cannot comment on its correctness. I rebased the patch
to current here:
http://github.com/spaetz/notmuch-all-feature/commit/3b5423fbdda5e78414e6f2e441cad5394173e155

Would that be an acceptable fix?

Also, as part of getting the useful backlog down, I propose these smallish
patches that are in my tree in the feature/misc branch (that I all grabbed from 
the mailing list):

* Add count command to manual page, Sandra Snan
  mail id:4ba29058.0f67f10a.2b59.1...@mx.google.com
  commit 2f5ea4c76dc9688b2520c8d64ac8617ba8a62f86
  (it was really missing)

* Fix typo in notmuch.h documentation regarding database open modes 
  mail id:1269628757-24857-1-git-send-email-mich...@obberon.com
  michaelforney, comit 3262b39f58ab4865c0c0cada69955ad65fccdfd9
  (our beloved notmuch.h is WRONG!!! :-)

* Prevent data loss caused by SIGINT during notmuch new
  mail id:1269937403-8495-1-git-send-email-sojk...@fel.cvut.cz
  wentasah, commit dcb7a957027837f187f06d31fdcddb3740b2c20b
  (preventable data loss, has happened to him at least once)

* Do not segfault on empty mime parts, 
  mail id:1267543888-18134-1-git-send-email-madd...@madduck.net
  martin f. krafft, commit bb310c6397a94f6f59b6f93b232bedd833f96090
  (probably a bug in gmime, but we should not crash)

   * Some library additions (move_to_first for the iterators,
+1!

All the rest souds very good.

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

Re: Plans for the 0.2 release (this week)

[David Edmondson]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
   * The big batch of emacs-client improvements from David E.'s
 repository. David, do you have particular things to recommend here?

It's necessary for me to merge with your latest batch of changes. That
won't happen until next week, when I can set aside a few hours. (The
merge is somewhat painful, as I have modified versions of some of the
recently applied patches in my tree.)

I worry about committing the JSON based Emacs UI and then immediately
producing a release - it would be useful to have more people test it
from git HEAD before dropping it on an unsuspecting public.

dme.
-- 
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Plans for the 0.2 release (this week)

[Anthony Towns]

On Thu, Apr 8, 2010 at 17:47, Sebastian Spaeth sebast...@sspaeth.de wrote:
 * Prevent data loss caused by SIGINT during notmuch new
  mail id:1269937403-8495-1-git-send-email-sojk...@fel.cvut.cz
  wentasah, commit dcb7a957027837f187f06d31fdcddb3740b2c20b
  (preventable data loss, has happened to him at least once)

That seems to be a different id to
http://patchwork.notmuchmail.org/patch/445/ but me too on that,
fwiw. (Haven't had data loss, did have confusing behaviour that I
attribute to this, and the logic for the patch seems sound to me)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Plans for the 0.2 release (this week)

[Michal Sojka]

On Wed, 07 Apr 2010, Carl Worth wrote:
 For the upcoming 0.2 release, here are some things that I would like to
 have in place:
 
   * Anything else that people want, (especially things that already
 exist and that you're already using). Support for maildir flags on
 import would be great here. I'm still waiting to see a complete
 solution I think.

This would be useful: id:m1my03gsmu@watt.gilman.jhu.edu. I use it
occasionally.

-Michal

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

Re: Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Thu, 08 Apr 2010 09:13:20 +0100, David Edmondson d...@dme.org wrote:
 On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
* The big batch of emacs-client improvements from David E.'s
  repository. David, do you have particular things to recommend here?
 
 It's necessary for me to merge with your latest batch of changes. That
 won't happen until next week, when I can set aside a few hours. (The
 merge is somewhat painful, as I have modified versions of some of the
 recently applied patches in my tree.)

I hope that this will be a less frequent thing to happen as Carl is
quicker in picking up patches. I'm very eager to see the emacs client
improvements, though.
 
 I worry about committing the JSON based Emacs UI and then immediately
 producing a release - it would be useful to have more people test it
 from git HEAD before dropping it on an unsuspecting public.

Not sure how much of an unsuspecting public we have at this
point... but in general this is of course valid. The question is what
are releases. Or what does it mean to release 0.2. I don't think we
have the notion of a stable branch and a development cycle,
yet. Everything is development (correct me if I'm wrong, Carl)

/D

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

Re: Plans for the 0.2 release (this week)

[Dirk Hohndel]

On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
  So keep the patches coming, and the pointers to patches that you want me
  to look at.
 
 I would really like to see the patch in spaetz/issue15-handle-fcc-bcc
 applied soon.  This is the lingering issue of bcc'ing the primary email
 address in notmuch replies, which I think really needs to be removed.

+1

The FCC solution is much more sane. Especially with the From address
based path selection that I proposed (but haven't been able to implement
for lack of Lisp skills)

/D

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

Re: Plans for the 0.2 release (this week)

[Carl Worth]

On Thu, 08 Apr 2010 07:58:47 -0700, Dirk Hohndel hohn...@infradead.org wrote:
 On Thu, 08 Apr 2010 10:03:15 -0400, Jameson Rollins 
 jroll...@finestructure.net wrote:
  Also, fwiw, the folder: indexing is probably the new feature that I'm
  most eagerly awaiting.  I've got all these ideas for ways to handle sent
  mail and drafts if we can get this working.
 
 Maybe I am missing some context here - what exactly does 'indexing' mean
 here?

Indexing here means shoving information into the database to make it
searchable.

I was a bit vague in my description of the features I want to enable
here. So let me start making it a bit more clear. I'd like to add
support for the following:

  1. A folder: prefix in the search syntax that will match components
 of the directory in which mail files are stored. So, if you've got
 mail filed into directories, (from using a folder-based email
 program, or from doing an imap sync from gmail that turns tags into
 directories), then you could search for things like folder:spam,
 folder:important, folder:arbitrary/subset/of/some/path, etc.

  2. A list: prefix to match content from headers that identify
 mailing list. My perception is that there are likely a handful of
 different headers that have been used, and they should all be
 indexed so that list: will search any of them.

  3. Some prefix that can be used to match typical headers added by
 spam-filtering software, (maybe this would be a general
 prefix---see below).

I think the above are probably the three I can think of that pretty much
everybody has asked for, so that should be indexed by default.

Beyond that, I'd like to be able to provide support for arbitrary
headers in the email. I had envisioned allowing the user to configure
specific headers to index. Alternately, I had imagined having a
blacklist of uninteresting headers and indexing everything
else. (Though, now Dirk is very interested in Received and its perhaps
provides the most content of any of the headers I originally thought
would be uninteresting.)

One experiment I should do is to measure how much my database would grow
if I were to index all of the header content. I don't really know what
kind of a percentage we're talking about.

Finally, we'd need a syntax for searching all of these headers. Rather
than trying to map each header name to a custom prefix, I think what
might be best would be a general thing that could look like:

header:X-Spam-Flag: YES

We don't currently have the ability to tie a search to the beginning of
a line, but it occurs to me that we could do something fancy like index
each header with a specific term to indicate line beginnings. Then, with
a custom query parser we could use the common symbol of '^' to map to
that. That would enable something like:

header:^X-Spam-Flag: YES

That's a lot of work though, (and perhaps not as important as it's
probably uncommon for a header name to appear within the value of some
other header).

 Hmm - haven't even thought about drafts, yet. How would the UI deal with
 those? 

I would imagine another folder alongside the others that would list
all drafts, and selecting any such message would bring up the message in
a mode to edit it.

Sup also displayed draft messages in their proper location in the
threads containing the message being replied to, (and highlighted such
threads in the search view).

All of that sounds quite easy to do by simply saving the draft within
the mailstore and giving it a draft tag.

Finally, many mail interfaces prompt from the compose new message
command whether an existing draft should be continued. That's useful to
help the user avoid forgetting to complete and send a draft that was
forgotten.

-Carl




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

Re: Plans for the 0.2 release (this week)

[Anthony Towns]

On Fri, Apr 9, 2010 at 00:03, Jameson Rollins
jroll...@finestructure.net wrote:
 Presumably others must be annoyed about having to manually read and
 archive all their sent mail, unless there's some other way that people
 having been dealing with this that I'm not aware of.

I haven't switched over to notmuch properly yet, but in my initial
import of my mail I made a couple of patches to notmuch new that let
me get the tags right first. One was to make:

notmuch new --initial-tags=list,unread

set the initial tags for newly found messages to list and unread
instead of the default inbox and unread.

The other was to make:

find Mail/.Saved/ -type f | notmuch new --initial-tags=archived --file-list

only process the mail files listed on stdin (via find), and give them
the explicit tags I specify. That way I could import all my existing
archived mail without it appearing in my inbox or as unread.

Unfortunately the second one ended up complicated and a bit slow (I
think because I'm doing a talloc() for every line on stdin, and
talloc_free() by context every time the base directory changes; that
sort of behaviour was necessary in order to do duplicate checking in a
sane way)

But anyway, that would let you do:

find Mail/.Drafts/ -type f | notmuch new --initial-tags=draft --file-list
notmuch new

to get drafts correctly tagged.

(I don't have the patches handy at the moment; but can certainly dig
them up if there's interest)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Plans for the 0.2 release (this week)

[Michal Sojka]

On Wed, 07 Apr 2010, Carl Worth wrote:
   * Anything else that people want, (especially things that already
 exist and that you're already using). Support for maildir flags on
 import would be great here. I'm still waiting to see a complete
 solution I think.
 
 So keep the patches coming, and the pointers to patches that you want me
 to look at.

Decode headers in reply
(id:1267602656-24940-1-git-send-email-sojk...@fel.cvut.cz) is another
patch, which is quite essential to me. Am I the only one here, who needs
to reply to messages with non-ASCII characters?

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

Plans for the 0.2 release (this week)

[Carl Worth]

We've obviously got a lot of interest in notmuch, and a huge pile of
features that need to be merged.

I think that means we're in a state where we can have extremely regular
releases, with continually improving feature sets. I'm thinking releases
once per week or so.

With each release, I expect people to remind me of their favorite
features that haven't been merged, (while I'll continue to work through
any backlog on my own).

For the upcoming 0.2 release, here are some things that I would like to
have in place:

  * Any further changes from the Sebastian's repository. Sebastian, I
worked through one list I saw recently. Do you have another list to
propose yet?

  * The big batch of emacs-client improvements from David E.'s
repository. David, do you have particular things to recommend here?

  * Changes to indexing, (addition of body:, folder:, list:, etc.). This
is stuff that I'll work on.

  * Some library additions (move_to_first for the iterators, and perhaps
a notmuch_database_add_message_with_data which Srinivasa requested
to support integration of notmuch into evolution). I'll work on
these as well, (I know that there are patches for some of these on
the list already).

  * Anything else that people want, (especially things that already
exist and that you're already using). Support for maildir flags on
import would be great here. I'm still waiting to see a complete
solution I think.

So keep the patches coming, and the pointers to patches that you want me
to look at.

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

Plans for the 0.2 release (this week)

[Carl Worth]

We've obviously got a lot of interest in notmuch, and a huge pile of
features that need to be merged.

I think that means we're in a state where we can have extremely regular
releases, with continually improving feature sets. I'm thinking releases
once per week or so.

With each release, I expect people to remind me of their favorite
features that haven't been merged, (while I'll continue to work through
any backlog on my own).

For the upcoming 0.2 release, here are some things that I would like to
have in place:

  * Any further changes from the Sebastian's repository. Sebastian, I
worked through one list I saw recently. Do you have another list to
propose yet?

  * The big batch of emacs-client improvements from David E.'s
repository. David, do you have particular things to recommend here?

  * Changes to indexing, (addition of body:, folder:, list:, etc.). This
is stuff that I'll work on.

  * Some library additions (move_to_first for the iterators, and perhaps
a notmuch_database_add_message_with_data which Srinivasa requested
to support integration of notmuch into evolution). I'll work on
these as well, (I know that there are patches for some of these on
the list already).

  * Anything else that people want, (especially things that already
exist and that you're already using). Support for maildir flags on
import would be great here. I'm still waiting to see a complete
solution I think.

So keep the patches coming, and the pointers to patches that you want me
to look at.

-Carl


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

Re: Plans for the 0.2 release (this week)

[James Westby]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
   * Anything else that people want, (especially things that already
 exist and that you're already using). Support for maildir flags on
 import would be great here. I'm still waiting to see a complete
 solution I think.

id:1268515677-12692-1-git-send-email-jw+deb...@jameswestby.net

I've been running with this locally since then with no apparent issues.

It will make anyone who suffers from this problem regularly pretty
happy, as they can return to the world of a thread-based mail client.

Thanks,

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