[notmuch] patch queue

2010-02-22 Thread Sebastian Spaeth
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins  wrote:
> Hey, Carl.  I've noticed that you've been applying some patches that
> were recently sent to the list, out of order from the chronological
> queue of patches that were sent to the list.  I'm a fan of the recently
> applied patches, but I'm curious about what your plans are for the older
> patches in the quene.  Are you still planning on processing them?
> Should the older patches be rebased against the current master and
> resent?

Just my snippet of info from IRC:
 bremner: OK. So my plan: 1) Commit stash stuff. 2) Make emacs 
directory. 3) Find and apply all obvious notmuch.el patches
 And bremner can help me stay focused.
 After that: 1) Modularize test suite 2) Add testing of emacs stuff
 Then: 1) Add folder: search 2) Don't index data redundantly
 And: 1) Add --format (JSON) 2) Add --output
 There. Now I've published a plan at least.
 luckily there are no public logs .

hehe, wrong ;-)

Sebastian


[notmuch] patch queue

2010-02-22 Thread Carl Worth
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins  wrote:
> Hey, Carl.  I've noticed that you've been applying some patches that
> were recently sent to the list, out of order from the chronological
> queue of patches that were sent to the list.  I'm a fan of the recently
> applied patches, but I'm curious about what your plans are for the older
> patches in the quene.  Are you still planning on processing them?
> Should the older patches be rebased against the current master and
> resent?

Thanks for asking, Jamie.

I'm still planning on processing the entire queue, (and chronologically),
but I'm definitely capable of being influenced to grab stuff from the
"future"

> I'm not at all trying to be pushy; there's just some older stuff in the
> queue that I would really like to see applied, such as folder-based
> tagging, json output, and some of the emacs UI improvements.

You're not being pushy at all. Please feel free to let me know what you
think is most important.

I totally agree on the things mentioned above as being priority. I want
folder-based tagging myself, and there are a *lot* of interesting things
that are blocking on json output. Meanwhile, shortcomings in the emacs
UI are causing me problems on a constant basis, (the latest thing
driving me crazy is the regression that refreshing search results makes
the current position in the search results get lost).

For folder-based tagging, that will cause an increment in the
database-format version, so I'd like to do a couple of other things at
the same time. One is to enable indexing of additional headers, (spam
flags, and mailing-list headers), and the other is to stop doing
redundant indexing of data under multiple prefixes[*].

For the emacs UI improvements, I do plan on making an early sweep of the
patch queue and applying them, (if only because I have some improvements
I need to make myself, and I want to avoid doing anything that's already
been done).

Thanks for your input, and please feel free to let me know your thoughts
at any time.

-Carl

[*] This idea came from an equivalent fix recently made to sup. We are
currently indexing the subject, for example, with a "subject:" prefix
and also with no prefix, (to match search terms with no prefix). The fix
is to just index it with the "subject:" prefix, but then at search time
to take any un-prefixed terms and match them against a whole list of
prefixes, (subject:, from:, to:, etc.). This should be a nice savings on
our database size with no appreciable performance cost.

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



[notmuch] patch queue

2010-02-22 Thread Michal Sojka
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins  wrote:
> I'm not at all trying to be pushy; there's just some older stuff in the
> queue that I would really like to see applied, such as folder-based
> tagging

Hi,

as for the folder-based tagging patch sent by myself, it needs some
improvement. I'm waiting for merge of testing ifrastructure in order to
write tests for the patch. The testing infrastructure is GPLv2 and we
would like to use it under GPLv3 and changing this takes some time. I
guess, Carl waits for this as well.

Michal


Re: [notmuch] patch queue

2010-02-22 Thread Michal Sojka
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 I'm not at all trying to be pushy; there's just some older stuff in the
 queue that I would really like to see applied, such as folder-based
 tagging

Hi,

as for the folder-based tagging patch sent by myself, it needs some
improvement. I'm waiting for merge of testing ifrastructure in order to
write tests for the patch. The testing infrastructure is GPLv2 and we
would like to use it under GPLv3 and changing this takes some time. I
guess, Carl waits for this as well.

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


Re: [notmuch] patch queue

2010-02-22 Thread Carl Worth
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 Hey, Carl.  I've noticed that you've been applying some patches that
 were recently sent to the list, out of order from the chronological
 queue of patches that were sent to the list.  I'm a fan of the recently
 applied patches, but I'm curious about what your plans are for the older
 patches in the quene.  Are you still planning on processing them?
 Should the older patches be rebased against the current master and
 resent?

Thanks for asking, Jamie.

I'm still planning on processing the entire queue, (and chronologically),
but I'm definitely capable of being influenced to grab stuff from the
future

 I'm not at all trying to be pushy; there's just some older stuff in the
 queue that I would really like to see applied, such as folder-based
 tagging, json output, and some of the emacs UI improvements.

You're not being pushy at all. Please feel free to let me know what you
think is most important.

I totally agree on the things mentioned above as being priority. I want
folder-based tagging myself, and there are a *lot* of interesting things
that are blocking on json output. Meanwhile, shortcomings in the emacs
UI are causing me problems on a constant basis, (the latest thing
driving me crazy is the regression that refreshing search results makes
the current position in the search results get lost).

For folder-based tagging, that will cause an increment in the
database-format version, so I'd like to do a couple of other things at
the same time. One is to enable indexing of additional headers, (spam
flags, and mailing-list headers), and the other is to stop doing
redundant indexing of data under multiple prefixes[*].

For the emacs UI improvements, I do plan on making an early sweep of the
patch queue and applying them, (if only because I have some improvements
I need to make myself, and I want to avoid doing anything that's already
been done).

Thanks for your input, and please feel free to let me know your thoughts
at any time.

-Carl

[*] This idea came from an equivalent fix recently made to sup. We are
currently indexing the subject, for example, with a subject: prefix
and also with no prefix, (to match search terms with no prefix). The fix
is to just index it with the subject: prefix, but then at search time
to take any un-prefixed terms and match them against a whole list of
prefixes, (subject:, from:, to:, etc.). This should be a nice savings on
our database size with no appreciable performance cost.



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


[notmuch] patch queue

2010-02-20 Thread Jameson Rollins
Hey, Carl.  I've noticed that you've been applying some patches that
were recently sent to the list, out of order from the chronological
queue of patches that were sent to the list.  I'm a fan of the recently
applied patches, but I'm curious about what your plans are for the older
patches in the quene.  Are you still planning on processing them?
Should the older patches be rebased against the current master and
resent?

I'm not at all trying to be pushy; there's just some older stuff in the
queue that I would really like to see applied, such as folder-based
tagging, json output, and some of the emacs UI improvements.

Thanks so much for the info.

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



[notmuch] patch queue

2010-02-20 Thread Jameson Rollins
Hey, Carl.  I've noticed that you've been applying some patches that
were recently sent to the list, out of order from the chronological
queue of patches that were sent to the list.  I'm a fan of the recently
applied patches, but I'm curious about what your plans are for the older
patches in the quene.  Are you still planning on processing them?
Should the older patches be rebased against the current master and
resent?

I'm not at all trying to be pushy; there's just some older stuff in the
queue that I would really like to see applied, such as folder-based
tagging, json output, and some of the emacs UI improvements.

Thanks so much for the info.

jamie.


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