Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth cwo...@cworth.org wrote:

.

 
   * The magic space bar is too magic. Threads are separate conversations
 so one key for paging through the current conversation shouldn't
 also switch to the next conversation, (particularly when the
 complementary key DEL doesn't reverse this behavior of SPACE).

agreed

 
 Recommendation: Make SPACE only page the current message. Recommend
 that user use 'a' to advance to next thread, (or 'x' to exit back to
 search results).

Later you mention 'N' and 'n' to do the same task. Or are you suggesting
that 'a' would move to the next task after marking the current task read ?

 
   * The unread tag is not handled transparently enough. Both Keith and
 Eric complained of frequently being presented with messages as
 unread that they had read before. (And I don't want to ever have
 to manually think about whether to remove a thread as unread.)
 
 Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
 'x' mark remove the unread tag from all messages in the current
 thread (as well as the inbox tag as currently). Also make 'n' and
 'p' remove the unread tag as well.


ok that explains. But with Xapian ticket 250 we would definitely want
some keybinding that move to the next mail without updating tags.


 
 Followup: This frees up 'N' and 'P', so I'd like to use the for
 next message and previous message and make 'n' and 'p' do next
 open message and previous open message.
 
   * Opening up unread messages in notmuch-show mode is not
 helpful. Keith reads a lot of high-volume mailing lists by reading
 the subject lines in search mode and then doing * -inbox. He likes
 that notmuch remembers that these messages are still unread, but if
 he later searches for a single message that happens to be in a giant
 thread of unread messages, then he wants to see just than one
 message, not all of them.
 
 Recommendation: Make notmuch-show-mode open *only* messages that
 match the search---not unread messages as well. At this point the
 unread tag becomes just a hint to the user and won't be explicitly
 handled differently by the interface, (other than that various
 commands will remove the unread tag if present). The unread tag is
 still useful for when searching for something like I know I read
 this message recently.
 
 Followup: I wonder if I would miss one feature here. If I'm
 interrupted after reading part of a giant thread, currently I can
 quite and when I come back notmuch will remember right where I was
 while reading. One way to get this behavior back would be to make
 SPACE remove the inbox tag from each message its scrolled off. I'll
 have to think about that.
 
   * The current 'a' key in search-mode is unreliable. It seemed like a
 good idea to make 'a' only archive messages that match the search,
 but it's a flawed idea. Imagine the following scenario: Eric is
 reading his inbox and sees some threads related to a boring
 topic. He filters down to these with f tag:boring. He's satisfied
 with the search results, and hits 'a' on each thread and even sees
 the inbox tag disappear from the presentation. But then when he
 returns to his inbox search and refreshes, the boring threads
 re-appear and have the inbox tag again. Ugh. The presentation is
 inconsistent and things just feel unreliable and broken.
 
 And a related issue:
 
   * The '*' key in search-mode doesn't provide any feedback that it has
 actually done anything, (none of the added/removed tags are changed
 in the presentation). And hitting '=' isn't necessarily ideal since
 it can make things irretrievably disappear, ('a' is different since
 it allows the user to confirm that things are good before making
 results disappear with '='). [*]
 
 Recommendation: Revert 'a' to act on all messages in a thread---not
 only those that match the search results. Then change '*' to work by
 walking the list and explicitly calling the same action as 'a' on
 each line. This will provide the desired feedback and should be
 plenty fast.

With xapian ticket 250 doing a tag update per thread is going to be
really slow right ?


 
 Note: There are still use cases where the user might want to modify
 the tags only on messages matching the search, (think, remove from
 inbox all messages from:someone). So I'm aware that there's still a
 hole in functionality here, but I really want to fix the current
 inconsistency in the presentation. And I'm open to further
 suggestions here.
 
 Let me know if any of the above seems crazy,
 

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

Re: [notmuch] Notmuch's search view sucks

[Olly Betts]

Karl Wiberg writes:
 On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth wrote:
  And a step beyond that would support different languages for
  different emails, but that sounds like something hard to identify.
 
 But probably not as hard as identifying spam. It could probably be
 done with a simple Bayesian filter counting word frequencies---but
 it'd be much better if somebody else had already solved the problem,
 since this smells suspiciously like something that ought to be a
 separate project and put in a library ... does anyone know if such a
 project already exists?

There's TextCat:

http://www.let.rug.nl/vannoord/TextCat/

It looks at n-gram frequencies, and can guess pretty reliably from
even a fairly small amount of text.

TextCat is in Perl.  I don't know if there's a C or C++ implementation
but it isn't a huge piece of code - finding a good technique was the
clever part of it.

Cheers,
Olly

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

Re: [notmuch] Notmuch's search view sucks

[Aaron Ecay]

--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen:

[...]

 TextCat is in Perl.  I don't know if there's a C or C++ implementation but
 it isn't a huge piece of code - finding a good technique was the clever part
 of it.

The same algorithm is implemented in C here:
http://www.mnogosearch.org/guesser/

Licensed under the GPL and includes presets for ~50 languages.  A potential
drawback is that it doesn't handle raw HTML very well, according to the
documentation.

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

Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

On Fri, 04 Dec 2009 03:06:32 +0100, Marten Veldthuis mar...@veldthuis.com 
wrote:
 Not sure what happened, but:
 
 Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
 notmuch-show-view-all-mime-parts
 From: cama...@picnicpark.org
...
 now collapses into:
 
 Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
 notmuch-show-view-all-mime-parts
 From: Keith Amidon ke...@nicira.com
 
 on my system (notice the From: header).

I think that's actual text in the message, (not a header). Does that
look to you like what's happening?

And any ideas for making this kind of thing more clear? On my system,
the From: line that is in the message at least isn't colorized like
the actual headers are.

-Carl


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

[notmuch] emacs UI customization

[Jameson Graef Rollins]

Hey, Carl et. al.  The recent improvements to the notmuch emacs mode
look great.  I have a couple of suggestions/questions about the UI
that I wanted to put to the group.

Here are some things that I would really like to see:

* in thread view, show read messages as initially collapsed

* show more header info (To:, Date: (with time), etc), or add ability
  to control which headers are displayed

* add blank line between header and body

* customize coloring of fields (in headers, or collapsed
  quotes/signatures/etc)

* customize key bindings

Is it currently possible to easily customize these things (ie. without
modifying the notmuch.el)?  If so, that would be great and I would
love to learn how (my current elisp and emacs customization skills are
pretty weak).  If not, I would like to strongly petition for either
changing these things, or making it possible for users to customize
them themselves.

In general, I think it would be really good to put together some
documentation about all the ways that users can customize the notmuch
interface.  I would be willing to help with that as well.  It would
also be nice to allow for customization about of things that are
currently not that might be controversial.

Thanks so much for the help.

jamie.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 04 Dec 2009 09:55:45 -0400, da...@tethera.net wrote:
 P.S. do people want to be CC'd on this list, or not?

We don't require subscription to the list, so I recommend CC, yes.

Plus, notmuch already handles duplicate mail just fine, (in that the
user only sees one copy at least). And I tag my mail differently when
one of my addresses appears on the CC list, so I definitely prefer that
people CC me when they want to call my specific attention to a message.

-Carl



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

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 10:05:05 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and 
gimble:

 CW Plus, notmuch already handles duplicate mail just fine, (in that the
 CW user only sees one copy at least). And I tag my mail differently when
 CW one of my addresses appears on the CC list, so I definitely prefer that
 CW people CC me when they want to call my specific attention to a message.

The only problem with Cc is that Mailman suppresses duplicate messages and hence
there is no List-Id: on message.

-- 
  http://fossarchy.blogspot.com/


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

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Sat, 05 Dec 2009 00:07:36 +0600, Mikhail Gusarov dotted...@dottedmag.net 
wrote:
 The only problem with Cc is that Mailman suppresses duplicate messages and 
 hence
 there is no List-Id: on message.

Hey, well notmuch doesn't even index the List-Id: header anyway. [*] ;-)

But the above sounds like the List-Id header is unreliable enough to be
useless. Any reason not to just use something like
to:notm...@notmuchmail to match messages sent to a list like this one?

I think mailman defaults to not allowing messages with the mailing-list
address implicit (such as in a Bcc) so it seems like matching the list
recipient will be more reliable than hoping the List-Id is always there.

-Carl

[*] Our TODO list does talk about supporting a configuration parameter
for indexing additional headers of interest.


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

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

 But the above sounds like the List-Id header is unreliable enough to
 be useless.

In my current .sieve setup, I have 93 entries for mailing lists.  87
of them use list-id[1].  3 use list-post.  1 uses 'mailing-list', but
looking at it, could be switched to list-id.  2 use x-mailing-list
(blasted vger.kernel.org).

None of my email gets misfiled, so it seems pretty darn reliable to
me. :)

Now, if you have an MTA that does duplicate suppression based on
message-id, you probably won't see the copy of a message that went to
the list if you're cc:'d on it because the direct copy (sans list-id
header) is likely to arrive first.

I would argue that that's a feature not a bug---the sender, at least,
hopes you will give it closer scrutiny because you were CC:'d.  They're
trying to bring it to your attention.

Besides, in notmuch, what's the difference going to be?  It'll still be
threaded the same, etc., but you'd be able to tell that this one came
to you rather than through the list, no?

(I'm waiting for Debian packages, lazy bastard that I am, so I'm
guessing on that)

 Any reason not to just use something like
 to:notm...@notmuchmail to match messages sent to a list like this one?

On the linux-kernel list, l-k often isn't in the to: field---or does
notmuch also index the cc: as to:?  If it does, this could work; if
not, FAIL.

Mike.


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

Re: [notmuch] [PATCH] Make search filters handle disjunctive queries.

[Carl Worth]

On Wed,  2 Dec 2009 12:00:35 +0100, Jed Brown j...@59a2.org wrote:
 notmuch-search-filter now accepts an arbitrary query and will group if
 necessary so that we get
 
   tag:inbox AND (gravy OR biscuits)
 
 instead of the former
 
   tag:inbox AND gravy OR biscuits

Perfect. A nice clean patch for just the one feature. Thanks!

I've pushed this now.

-Carl


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

Re: [notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Jed Brown]

On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth cwo...@cworth.org wrote:

 But surely there's a way to implement this with dramatically less code
 duplication?

It should just be very short after this series

  id:1259450376-24523-1-git-send-email-...@59a2.org

I think --format= should not be used for this, formatting is orthogonal
to selecting recipients.

Speaking of code duplication, perhaps it is worth abstracting options
parsing (or using an existing library).

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

Re: [notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Sat, 28 Nov 2009 18:57:35 -0500, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 This also removes the Makefile.config from the repository, since it
 shouldn't be kept in the repository and should be created by the
 configure script.

Hi Jamie,

Handling --prefix will be a nice addition to our configure script. So,
thanks!

Your commit message has that flag word of also in it, and as it turns
out, the removal of Makefile.config from the repository has actually
happened already. But that was easy enough to fix.

 +# option parsing
 +for option; do
 +if [ ${option%=*} = '--prefix' ] ; then
 + PREFIX=${option#*=}
 +fi
 +done

I've gone ahead and committed that now. Then I noticed that we should
really use ${option%%=*} to support the case of an option value
containing an '=' character. So I fixed that.

Then, since I was in the area, I added support to configure for
capturing CFLAGS from the environment, I fixed this (and also make
CFLAGS=) to also influence C++ compilation (still can be separately
overridden with CXXFLAGS), and I fixed our quiet-compilation mode to
actually print the (user-specified) CFLAGS.

Finally, I documented things by adding a configure --help to document
CC, CFLAGS, and --prefix; and by making make tell the user about
./configure and ./configure --help when make runs configure
implicitly.

Our configuration system certainly isn't as full-featured yet as a
standard autoconf-based configure script, but I'm quite happy with how
clean it is for both users and developers.

-Carl


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

Re: [notmuch] [PATCH] notmuch.el: Add face support to message summary and subject lines.

[Carl Worth]

On Mon, 30 Nov 2009 22:50:39 +0800, Kan-Ru Chen ka...@kanru.info wrote:
 Remove the underline of both message summary and subject lines.
 Message summary still defaults to reverse-video, use customize to
 change it to whatever you like.

Thanks for submitting this patch. I recently fixed the ugly underlining
a separate way. Let me know if you think the current code needs any
further improvement in this area.

-Carl


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

Re: [notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:12:47PM -0800, Carl Worth wrote:
 Handling --prefix will be a nice addition to our configure script. So,
 thanks!

Yeah, it's definitely needed for the Debian packaging as well.

 Your commit message has that flag word of also in it, and as it turns
 out, the removal of Makefile.config from the repository has actually
 happened already. But that was easy enough to fix.

I was thinking that the removal of the Makefile.config from the repo
went together with the new auto-generation of that file from configure
script.  Do you think they still should have been separate patches?

  +# option parsing
  +for option; do
  +if [ ${option%=*} = '--prefix' ] ; then
  +   PREFIX=${option#*=}
  +fi
  +done
 
 I've gone ahead and committed that now. Then I noticed that we should
 really use ${option%%=*} to support the case of an option value
 containing an '=' character. So I fixed that.

Ah, good catch.  Sorry about that.  

 Our configuration system certainly isn't as full-featured yet as a
 standard autoconf-based configure script, but I'm quite happy with how
 clean it is for both users and developers.

Autoconf terrifies me, so I agree I'm quite happy with the simple
configure script we have right now.  If it gets the job done without
having to deal with autoconf then that's great in my book.

jamie.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 3/3] fix Makefile.local to install bash completion definitions as not executable

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:16:20PM -0800, Carl Worth wrote:
 On Sat, 28 Nov 2009 18:57:37 -0500, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
  -   install contrib/notmuch-completion.bash \
  +   install -m0644 contrib/notmuch-completion.bash \
  $(DESTDIR)$(bash_completion_dir)/notmuch
 
 Thanks. I pushed this.
 
 I didn't push the parent commit in the thread, (regarding zlib), since as
 mentioned in another reply this is actually a bug in the GMime
 pkg-config file.

Great.  That's fine with me (assuming that GMime actually gets fixed
upstream).

jamie.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] Fix typos in documentation strings

[Carl Worth]

On Tue, 01 Dec 2009 08:45:17 -0200, Fernando Carrijo fcarr...@yahoo.com.br 
wrote:
 One more party, one more joiner, one more patch!  :)

Welcome to the party, Fernando!

 -  Forward a the current message.
 +  Forward the current message.
..
 -  Preficate testing whether current message is unread.
 +  Predicate testing whether current message is unread.

Clearly I need to stay on top of my notmuch patch-queue better. Then I
could have just applied this patch instead of finding and fixing those
typos separately.

I'll look forward to further patches from you! (And don't worry, I'm
sure I'll keep misspelling things often...)

-Carl


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

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman 
mdor...@ironicdesign.com wrote:
 Now, if you have an MTA that does duplicate suppression based on
 message-id, you probably won't see the copy of a message that went to
 the list if you're cc:'d on it because the direct copy (sans list-id
 header) is likely to arrive first.
 
 I would argue that that's a feature not a bug---the sender, at least,
 hopes you will give it closer scrutiny because you were CC:'d.  They're
 trying to bring it to your attention.

Sure, giving it closer scrutiny is good. But if I expect a search like:

tag:lkml

to match all of my mail that came through the mailing list, but it
actually *misses* mail where the sender wanted me to give extra
scrutiny, then that's a big failure.

 Besides, in notmuch, what's the difference going to be?  It'll still be
 threaded the same, etc., but you'd be able to tell that this one came
 to you rather than through the list, no?

The difference is whether the message is found in a search, (see above).

 (I'm waiting for Debian packages, lazy bastard that I am, so I'm
 guessing on that)

Yeah, I'll get to that (real soon now, I promise.)

 On the linux-kernel list, l-k often isn't in the to: field---or does
 notmuch also index the cc: as to:?  If it does, this could work; if
 not, FAIL.

Yes. In notmuch, all recipient fields, (even Bcc: if a mail happens to
hit your mail store with that intact), all get indexed to a single to
prefix. My rationale is that when reading a message it's often very
useful to see whether I was addresses specifically or just CC'ed. But
when _searching_ for a message, it's too fragile to have to guess
whether the recipient was on the To: or CC: header (and too painful to
always type (to:m...@example.com or cc:m...@example.com).

-Carl


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

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman 
mdor...@ironicdesign.com wrote:
 Besides, in notmuch, what's the difference going to be?  It'll still be
 threaded the same, etc., but you'd be able to tell that this one came
 to you rather than through the list, no?

There's one other point I should make here while talking about duplicate
messages, (as determined by identical Message ID).

Currently notmuch just indexes the first version of any given message it
sees, and simply ignores anything else it sees in the future.

We're planning to change it to at least save each of the filenames for
messages with multiple files. That way if some duplicates are deleted,
then notmuch will still be able to find one of the others.

Also, we could make notmuch index duplicate messages and add any
additional terms found to the document for the message. Currently, that
wouldn't make a big difference since notmuch is only indexing the body
and a few specific headers, (From, Subject, To, Cc, Bcc, Messsage-ID,
In-Reply-To, References).

So any differences there should be quite minor (a [LIST] prefix in
subject? an extra footer in the boday?), under the assumption that no
mail files will ever exist with the same message ID but disparate
content.

Now, we have a TODO item to allow for indexing additional headers,
(either by default or by user configuration). Once we start doing that,
it probably will make sense to at least index the duplicates.

But when viewing an actual message, I'm still planning on having notmuch
just return an arbitrary filename from the list of filenames associated
with that message. Does anyone see any problem with that? Can you think
of a case where you'd really care about seeing one or the other of
a particular duplicated message?

-Carl


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

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 16:39:50 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and 
gimble:

 CW But when viewing an actual message, I'm still planning on having
 CW notmuch just return an arbitrary filename from the list of
 CW filenames associated with that message. Does anyone see any problem
 CW with that? Can you think of a case where you'd really care about
 CW seeing one or the other of a particular duplicated message?

There might be different Reply-To fields.

So I'd just return bigger dup, as it probably contains more information
:)

-- 
  http://fossarchy.blogspot.com/


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

Re: [notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Fri, 4 Dec 2009 19:20:50 -0500, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
  Your commit message has that flag word of also in it, and as it turns
  out, the removal of Makefile.config from the repository has actually
  happened already. But that was easy enough to fix.
 
 I was thinking that the removal of the Makefile.config from the repo
 went together with the new auto-generation of that file from configure
 script.  Do you think they still should have been separate patches?

No, it was fine. It's just funny to me how often that word also in a
commit message seems to end up being a predictor for things later, (like
this case where half of a patch is already implemented, or much worse,
how often a bisect lands on a commit that makes multiple changes).

So I was really just expressing amusement at seeing it again.

   +# option parsing
   +for option; do
   +if [ ${option%=*} = '--prefix' ] ; then
   + PREFIX=${option#*=}
   +fi
   +done
  
  I've gone ahead and committed that now. Then I noticed that we should
  really use ${option%%=*} to support the case of an option value
  containing an '=' character. So I fixed that.
 
 Ah, good catch.  Sorry about that.  

No worries. I was just impressed at the tiny amount of code needed for
the parsing here, so ended up looking closer to understand it.

 Autoconf terrifies me, so I agree I'm quite happy with the simple
 configure script we have right now.  If it gets the job done without
 having to deal with autoconf then that's great in my book.

Cool. At least not everyone thinks I'm crazy then. That's
encouraging. :-)

-Carl


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

[notmuch] [PATCH 1/2] notmuch-search-process-filter: add text properties for authors and subject to each line

[david]

From: David Bremner brem...@unb.ca

Add functions notmuch-search-find-authors and notmuch-find-subject to
match notmuch-find-thread-id.  These functions are just a wrapper
around get-text-property, but in principle that could change.
---
 notmuch.el |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index c504f46..5925907 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1133,6 +1133,14 @@ Complete list of currently available key bindings:
   Return the thread for the current thread
   (get-text-property (point) 'notmuch-search-thread-id))
 
+(defun notmuch-search-find-authors ()
+  Return the authors for the current thread
+  (get-text-property (point) 'notmuch-search-authors))
+
+(defun notmuch-search-find-subject ()
+  Return the subject for the current thread
+  (get-text-property (point) 'notmuch-search-subject))
+
 (defun notmuch-search-show-thread ()
   Display the currently selected thread.
   (interactive)
@@ -1257,7 +1265,9 @@ This function advances the next thread when finished.
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format %s %-7s %-40s %s (%s)\n date count 
authors subject tags))
-   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id))
+   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
+   (put-text-property beg (point-marker) 
'notmuch-search-authors authors)
+   (put-text-property beg (point-marker) 
'notmuch-search-subject subject))
  (set 'line (match-end 0)))
  (set 'more nil))
   (delete-process proc
-- 
1.6.5.3

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

[notmuch] [PATCH 2/2] notmuch-show: add optional argument for query context instead of using global binding notmuch-search-query-string

[david]

From: David Bremner brem...@unb.ca

Also modify the one call to notmuch-show in notmuch.el.  This makes
the call (notmuch-show thread-id) will work when there is no binding
for notmuch-search-query-string; e.g. when called from user code
outside notmuch.
---
 notmuch.el |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 5925907..f7048d5 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -949,15 +949,17 @@ All currently available key bindings:
  (lambda()
(hl-line-mode 1) ))
 
-(defun notmuch-show (thread-id optional parent-buffer)
+(defun notmuch-show (thread-id optional parent-buffer query-context)
   Run \notmuch show\ with the given thread ID and display results.
 
 The optional PARENT-BUFFER is the notmuch-search buffer from
 which this notmuch-show command was executed, (so that the next
-thread from that buffer can be show when done with this one).
+thread from that buffer can be show when done with this one).
+
+The optional QUERY-CONTEXT is a notmuch search term. Only messages from the 
thread 
+matching this search term are shown if non-nil. 
   (interactive sNotmuch show: )
-  (let ((query notmuch-search-query-string)
-   (buffer (get-buffer-create (concat *notmuch-show- thread-id *
+  (let ((buffer (get-buffer-create (concat *notmuch-show- thread-id *
 (switch-to-buffer buffer)
 (notmuch-show-mode)
 (set (make-local-variable 'notmuch-show-parent-buffer) parent-buffer)
@@ -969,7 +971,9 @@ thread from that buffer can be show when done with this 
one).
   (erase-buffer)
   (goto-char (point-min))
   (save-excursion
-   (call-process notmuch-command nil t nil show --entire-thread 
thread-id and ( query ))
+   (let* ((basic-args (list notmuch-command nil t nil show 
--entire-thread thread-id))
+   (args (if query-context (append basic-args (list and ( 
query-context ))) basic-args)))
+ (apply 'call-process args))
(notmuch-show-markup-messages)
)
   (run-hooks 'notmuch-show-hook)
@@ -1146,7 +1150,7 @@ Complete list of currently available key bindings:
   (interactive)
   (let ((thread-id (notmuch-search-find-thread-id)))
 (if ( (length thread-id) 0)
-   (notmuch-show thread-id (current-buffer))
+   (notmuch-show thread-id (current-buffer) notmuch-search-query-string)
   (error End of search results
 
 (defun notmuch-search-reply-to-thread ()
-- 
1.6.5.3

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

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Marten Veldthuis]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
>   * Much nicer looking presentation, (no more ugly reverse-video or
> underlines on the message summary line).
> 
>   * More reliable message-visibility buttons, (using RET in the first
> column of a message-summary line now works).

Not sure what happened, but:

Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
notmuch-show-view-all-mime-parts
From: camalot at picnicpark.org
To: notmuch at notmuchmail.org
Cc: Keith Amidon 
Bcc: 
Date: Fri, 27 Nov 2009 05:30:10 -0800

now collapses into:


Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
notmuch-show-view-all-mime-parts
From: Keith Amidon 

on my system (notice the From: header).

-- 
- Marten

[notmuch] [PATCH 2/9] Adjust autoload comments

[James Rowe]

  Firstly, thanks for the full explanations!

On Thu, 03 Dec 2009 17:04:52 -0800, Carl Worth  wrote:
> The notmuch-folder command is definitely a nice primary interface to
> notmuch for some people. I'm seriously considering making it the view
> that one gets with "M-x notmuch" (after the notmuch-folder view gets a
> little sprucing up).

  Coming from sup and being a gmail user "emacs -f notmuch" seems like
the natural mail interface to me. Still, even if the default view
changes I can switch to just opening a tag:inbox search.

  I've left the elisp-make-autoload-file change in our builds, which
means all the ";;;###autoload" enveloped functions are available. Nobody
seems to be upset by the change.

> As for notmuch-search, I find it very convenient to have the ability to
> do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it)
> From any random emacs buffer. If you don't live inside emacs, and just
> have a single emacs frame open for notmuch sake, maybe that's not as
> interesting.

  Carl, you've got me pegged.  I use the /other/ editor, I only
installed emacs for notmuch.

  For me, I've already managed to train myself to just fire up notmuch
and hit 's' when searching. The extra search buffer that method creates
makes no difference to my personal usage patterns.

-- 
Thanks,

James

[notmuch] Notmuch's search view sucks

[Karl Wiberg]

On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth  wrote:
> And a step beyond that would support different languages for
> different emails, but that sounds like something "hard" to identify.

But probably not as hard as identifying spam. It could probably be
done with a simple Bayesian filter counting word frequencies---but
it'd be much better if somebody else had already solved the problem,
since this smells suspiciously like something that ought to be a
separate project and put in a library ... does anyone know if such a
project already exists? I know Google can do it ...

It'd be very cool to have notmuch automatically tag messages according
to what language they're in.

-- 
Karl Wiberg, kha at treskal.com
   subrabbit.wordpress.com
   www.treskal.com/kalle

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:

.

> 
>   * The magic space bar is too magic. Threads are separate conversations
> so one key for paging through the current conversation shouldn't
> also switch to the next conversation, (particularly when the
> complementary key DEL doesn't reverse this behavior of SPACE).

agreed

> 
> Recommendation: Make SPACE only page the current message. Recommend
> that user use 'a' to advance to next thread, (or 'x' to exit back to
> search results).

Later you mention 'N' and 'n' to do the same task. Or are you suggesting
that 'a' would move to the next task after marking the current task read ?

> 
>   * The unread tag is not handled transparently enough. Both Keith and
> Eric complained of frequently being presented with messages as
> "unread" that they had read before. (And I don't want to ever have
> to manually think about whether to remove a thread as "unread".)
> 
> Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
> 'x' mark remove the "unread" tag from all messages in the current
> thread (as well as the "inbox" tag as currently). Also make 'n' and
> 'p' remove the "unread tag as well.


ok that explains. But with Xapian ticket 250 we would definitely want
some keybinding that move to the next mail without updating tags.


> 
> Followup: This frees up 'N' and 'P', so I'd like to use the for
> "next message" and "previous message" and make 'n' and 'p' do "next
> open message" and "previous open message".
> 
>   * Opening up unread messages in notmuch-show mode is not
> helpful. Keith reads a lot of high-volume mailing lists by reading
> the subject lines in search mode and then doing "* -inbox". He likes
> that notmuch remembers that these messages are still unread, but if
> he later searches for a single message that happens to be in a giant
> thread of unread messages, then he wants to see just than one
> message, not all of them.
> 
> Recommendation: Make notmuch-show-mode open *only* messages that
> match the search---not unread messages as well. At this point the
> unread tag becomes just a hint to the user and won't be explicitly
> handled differently by the interface, (other than that various
> commands will remove the unread tag if present). The unread tag is
> still useful for when searching for something like "I know I read
> this message recently".
> 
> Followup: I wonder if I would miss one feature here. If I'm
> interrupted after reading part of a giant thread, currently I can
> quite and when I come back notmuch will remember right where I was
> while reading. One way to get this behavior back would be to make
> SPACE remove the inbox tag from each message its scrolled off. I'll
> have to think about that.
> 
>   * The current 'a' key in search-mode is unreliable. It seemed like a
> good idea to make 'a' only archive messages that match the search,
> but it's a flawed idea. Imagine the following scenario: Eric is
> reading his inbox and sees some threads related to a boring
> topic. He filters down to these with "f tag:boring". He's satisfied
> with the search results, and hits 'a' on each thread and even sees
> the "inbox" tag disappear from the presentation. But then when he
> returns to his inbox search and refreshes, the boring threads
> re-appear and have the inbox tag again. Ugh. The presentation is
> inconsistent and things just feel unreliable and broken.
> 
> And a related issue:
> 
>   * The '*' key in search-mode doesn't provide any feedback that it has
> actually done anything, (none of the added/removed tags are changed
> in the presentation). And hitting '=' isn't necessarily ideal since
> it can make things irretrievably disappear, ('a' is different since
> it allows the user to confirm that things are good before making
> results disappear with '='). [*]
> 
> Recommendation: Revert 'a' to act on all messages in a thread---not
> only those that match the search results. Then change '*' to work by
> walking the list and explicitly calling the same action as 'a' on
> each line. This will provide the desired feedback and should be
> plenty fast.

With xapian ticket 250 doing a tag update per thread is going to be
really slow right ?


> 
> Note: There are still use cases where the user might want to modify
> the tags only on messages matching the search, (think, "remove from
> inbox all messages from:someone"). So I'm aware that there's still a
> hole in functionality here, but I really want to fix the current
> inconsistency in the presentation. And I'm open to further
> suggestions here.
> 
> Let me know if any of the above seems crazy,
> 

-aneesh

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
> I just pushed out a nice set of changes to the emacs interface. Here's a
> quick summary of what you can expect to get when you next update:
> 
>   * Much nicer looking presentation, (no more ugly reverse-video or
> underlines on the message summary line).
> 
>   * More reliable message-visibility buttons, (using RET in the first
> column of a message-summary line now works).
> 
>   * Space bar fixed to advance to next open message, (it was originally
> written this way, but has been broken since we changed from global
> to local toggling of hidden message parts).
> 
>   * Showing a thread where the search matches only a subset of the
> thread now opens only the matched messages (in addition to unread
> messages).
> 
> This last feature is the big one---the rest all just happened to come
> along at the same time. One thing that I often do is read some giant
> thread and then tag a single message deep in that thread for dealing
> with later. And previously, doing a search for that tag would bring back
> the entire thread. Now, it opens only the message I'm actually looking
> for. So this is a very welcome change
> 
> And thanks to Bart Trojanowski for the groundwork for this change. I
> think the vim interface has had this feature for a while, (or would have
> if I had pushed all of Bart's changes earlier).
> 
> Meanwhile, Keith and Eric gave me some helpful feedback about the
> notmuch user-interface over lunch today, and in particular about the
> handling of the "unread" tag. Here are some of the things discussed,
> along with some things I'd like to change in response.
> 
> I'm open to suggestions on all of these, and most importantly, wanted to
> let people know about some upcoming user-interface changes before they
> were in place and potentially surprising.
> 
>   * The magic space bar is too magic. Threads are separate conversations
> so one key for paging through the current conversation shouldn't
> also switch to the next conversation, (particularly when the
> complementary key DEL doesn't reverse this behavior of SPACE).
> 
> Recommendation: Make SPACE only page the current message. Recommend
> that user use 'a' to advance to next thread, (or 'x' to exit back to
> search results).
> 
>   * The unread tag is not handled transparently enough. Both Keith and
> Eric complained of frequently being presented with messages as
> "unread" that they had read before. (And I don't want to ever have
> to manually think about whether to remove a thread as "unread".)
> 
> Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
> 'x' mark remove the "unread" tag from all messages in the current
> thread (as well as the "inbox" tag as currently). Also make 'n' and
> 'p' remove the "unread tag as well.
> 
> Followup: This frees up 'N' and 'P', so I'd like to use the for
> "next message" and "previous message" and make 'n' and 'p' do "next
> open message" and "previous open message".
> 
>   * Opening up unread messages in notmuch-show mode is not
> helpful. Keith reads a lot of high-volume mailing lists by reading
> the subject lines in search mode and then doing "* -inbox". He likes
> that notmuch remembers that these messages are still unread, but if
> he later searches for a single message that happens to be in a giant
> thread of unread messages, then he wants to see just than one
> message, not all of them.
> 
> Recommendation: Make notmuch-show-mode open *only* messages that
> match the search---not unread messages as well. At this point the
> unread tag becomes just a hint to the user and won't be explicitly
> handled differently by the interface, (other than that various
> commands will remove the unread tag if present). The unread tag is
> still useful for when searching for something like "I know I read
> this message recently".
> 
> Followup: I wonder if I would miss one feature here. If I'm
> interrupted after reading part of a giant thread, currently I can
> quite and when I come back notmuch will remember right where I was
> while reading. One way to get this behavior back would be to make
> SPACE remove the inbox tag from each message its scrolled off. I'll
> have to think about that.
> 
>   * The current 'a' key in search-mode is unreliable. It seemed like a
> good idea to make 'a' only archive messages that match the search,
> but it's a flawed idea. Imagine the following scenario: Eric is
> reading his inbox and sees some threads related to a boring
> topic. He filters down to these with "f tag:boring". He's satisfied
> with the search results, and hits 'a' on each thread and even sees
> the "inbox" tag disappear from the presentation. But then when he
> returns to his inbox search and refreshes, the boring threads
> re-appear and have the 

[notmuch] Notmuch's search view sucks

[Olly Betts]

Karl Wiberg writes:
> On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth wrote:
> > And a step beyond that would support different languages for
> > different emails, but that sounds like something "hard" to identify.
> 
> But probably not as hard as identifying spam. It could probably be
> done with a simple Bayesian filter counting word frequencies---but
> it'd be much better if somebody else had already solved the problem,
> since this smells suspiciously like something that ought to be a
> separate project and put in a library ... does anyone know if such a
> project already exists?

There's TextCat:

http://www.let.rug.nl/vannoord/TextCat/

It looks at n-gram frequencies, and can guess pretty reliably from
even a fairly small amount of text.

TextCat is in Perl.  I don't know if there's a C or C++ implementation
but it isn't a huge piece of code - finding a good technique was the
clever part of it.

Cheers,
Olly

[notmuch] Notmuch's search view sucks

[Aaron Ecay]

--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen:

[...]

> TextCat is in Perl.  I don't know if there's a C or C++ implementation but
> it isn't a huge piece of code - finding a good technique was the clever part
> of it.

The same algorithm is implemented in C here:
http://www.mnogosearch.org/guesser/

Licensed under the GPL and includes presets for ~50 languages.  A potential
drawback is that it doesn't handle raw HTML very well, according to the
documentation.

Aaron

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[da...@tethera.net]

At Thu, 03 Dec 2009 16:45:22 -0800,

> Anyway, I think we'll see code for that soon, so I'm not planning to
> commit the offered patch. But people really needing renames might want
> to use it for now, (and live with any performance implications it
> causes).

I could live with the performance issues, but it seems that it re-tags
every "Processed" file (renamed or not) as inbox.  This brings about
20k messages back into my inbox, which is a bit unusable.  The problem
seems to be that notmuch_database_add_message returns
NOTMUCH_STATUS_SUCCESS whether or not a new message was really added.
I don't know if there is an easy fix for this, or if it is worth
pursuing, given that the patch won't be committed.

d

P.S. do people want to be CC'd on this list, or not?

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

Hi Aneesh,

Thanks for the followup.

On Fri, 04 Dec 2009 14:08:52 +0530, "Aneesh Kumar K. V"  wrote:
> > Recommendation: Make SPACE only page the current message. Recommend
> > that user use 'a' to advance to next thread, (or 'x' to exit back to
> > search results).
> 
> Later you mention 'N' and 'n' to do the same task. Or are you suggesting
> that 'a' would move to the next task after marking the current task
> read ?

Sorry, I meant for 'N' and 'P' to move between messages in a thread.

But it would make sense to also have commands to navigate to the next
and previous threads. So many actions and so few keys... :-}

> ok that explains. But with Xapian ticket 250 we would definitely want
> some keybinding that move to the next mail without updating tags.

I don't want to let a current bug shape the interface we want. But, yes,
that's a current reality.

> > Recommendation: Revert 'a' to act on all messages in a thread---not
> > only those that match the search results. Then change '*' to work by
> > walking the list and explicitly calling the same action as 'a' on
> > each line. This will provide the desired feedback and should be
> > plenty fast.
> 
> With xapian ticket 250 doing a tag update per thread is going to be
> really slow right ?

Yes, but that's already the case with '*'. The Xapian work involved
should be the same whether calling "notmuch tag" once with the whole
search string, or several times, (once for each thread).

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

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

On Fri, 04 Dec 2009 14:28:22 +0530, "Aneesh Kumar K. V"  wrote:
> Can we also get a facility to temporarily mark a message and apply tags
> on all marked message. In mutt terminology it is called 'tag'.

Would be nice, yes. Another thing we probably want is a way to modify
the tags on all threads within the current emacs region.

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

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

On Fri, 04 Dec 2009 03:06:32 +0100, Marten Veldthuis  
wrote:
> Not sure what happened, but:
> 
> Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
> notmuch-show-view-all-mime-parts
> From: camalot at picnicpark.org
...
> now collapses into:
> 
> Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
> notmuch-show-view-all-mime-parts
> From: Keith Amidon 
> 
> on my system (notice the From: header).

I think that's actual text in the message, (not a header). Does that
look to you like what's happening?

And any ideas for making this kind of thing more clear? On my system,
the "From:" line that is in the message at least isn't colorized like
the actual headers are.

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

[notmuch] [PATCH 2/9] Adjust autoload comments

[Carl Worth]

On Thu, 3 Dec 2009 20:24:59 -0500, Jameson Graef Rollins  wrote:
> I actually really like having notmuch open right into my "inbox".

Well, at least that option won't ever go away. :-)

> I thought part of the point of notmuch was to get rid of the whole dump
> idea of folders!

There's certainly lots of brain-damage in "folder-based" email
programs. And obviously, we don't want to encourage that. I think one of
the biggest things that notmuch provides to avoid the brain damage is
global search.

So what I'm imagining for the default notmuch view is something like
this:

Welcome to notmuch.

Notmuch search: _

Saved searches:

55,342  All messages
22  Inbox

Recent searches:

 1  from:"someone special" and tag:unread
34  tag:notmuch and tag:todo

Click (or press Enter) on any search to see the results.
Right-click (or press Space) on any recent search to save it.

So the "saved searches" portion of the view is basically just what
notmuch-folder displays now. Above that there's an obvious place to
start a new search, (in a slightly more "web-browser-like" way than the
typical mini-buffer approach).

All recent searches appear in the list at the bottom automatically, and
there's the documented mechanism for saving a search, (giving it a name
and having it appear above).

I think the above should do a good job of emphasizing what notmuch is,
and how a search-based email program is fundamentally different than a
folder-based approach.

Feedback?

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

[notmuch] Notmuch's search view sucks

[Baruch Even]

Karl Wiberg wrote:
> On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth  wrote:
>> And a step beyond that would support different languages for
>> different emails, but that sounds like something "hard" to identify.
> 
> But probably not as hard as identifying spam. It could probably be
> done with a simple Bayesian filter counting word frequencies---but
> it'd be much better if somebody else had already solved the problem,
> since this smells suspiciously like something that ought to be a
> separate project and put in a library ... does anyone know if such a
> project already exists? I know Google can do it ...
> 
> It'd be very cool to have notmuch automatically tag messages according
> to what language they're in.

What we should have is an interface to run an external program to 
classify a message when it's newly introduced and another that runs when 
tags are changed so that machine learning can be made to work when the 
user changes tags.

Baruch

[notmuch] emacs UI customization

[Jameson Graef Rollins]

Hey, Carl et. al.  The recent improvements to the notmuch emacs mode
look great.  I have a couple of suggestions/questions about the UI
that I wanted to put to the group.

Here are some things that I would really like to see:

* in thread view, show read messages as initially collapsed

* show more header info (To:, Date: (with time), etc), or add ability
  to control which headers are displayed

* add blank line between header and body

* customize coloring of fields (in headers, or collapsed
  quotes/signatures/etc)

* customize key bindings

Is it currently possible to easily customize these things (ie. without
modifying the notmuch.el)?  If so, that would be great and I would
love to learn how (my current elisp and emacs customization skills are
pretty weak).  If not, I would like to strongly petition for either
changing these things, or making it possible for users to customize
them themselves.

In general, I think it would be really good to put together some
documentation about all the ways that users can customize the notmuch
interface.  I would be willing to help with that as well.  It would
also be nice to allow for customization about of things that are
currently not that might be controversial.

Thanks so much for the help.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/34d88203/attachment.pgp>

[notmuch] Notmuch's search view sucks

[Carl Worth]

On Fri, 04 Dec 2009 06:52:38 -0500, Aaron Ecay  wrote:
> The same algorithm is implemented in C here:
> http://www.mnogosearch.org/guesser/
> 
> Licensed under the GPL and includes presets for ~50 languages.

That indeed does look very interesting, (at least what I can get from
google's cache of the website, as the server seems to be down just
now). Oh, but I can just "apt-get source mnogosearch" and find
src/mguesser.c and src/guesser.c at least.

> A potential drawback is that it doesn't handle raw HTML very well,
> according to the documentation.

Shouldn't really be an issue. Notmuch will already want to de-tagify
HTML before indexing anyway.

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

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 04 Dec 2009 09:55:45 -0400, david at tethera.net wrote:
> P.S. do people want to be CC'd on this list, or not?

We don't require subscription to the list, so I recommend CC, yes.

Plus, notmuch already handles duplicate mail just fine, (in that the
user only sees one copy at least). And I tag my mail differently when
one of my addresses appears on the CC list, so I definitely prefer that
people CC me when they want to call my specific attention to a message.

-Carl

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

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Sat, 05 Dec 2009 00:07:36 +0600, Mikhail Gusarov  wrote:
> The only problem with Cc is that Mailman suppresses duplicate messages and 
> hence
> there is no List-Id: on message.

Hey, well notmuch doesn't even index the List-Id: header anyway. [*] ;-)

But the above sounds like the List-Id header is unreliable enough to be
useless. Any reason not to just use something like
to:notmuch at notmuchmail to match messages sent to a list like this one?

I think mailman defaults to not allowing messages with the mailing-list
address implicit (such as in a Bcc) so it seems like matching the list
recipient will be more reliable than hoping the List-Id is always there.

-Carl

[*] Our TODO list does talk about supporting a configuration parameter
for indexing additional headers of interest.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/d72d0cf7/attachment.pgp>

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

On Sat, 05 Dec 2009 00:07:36 +0600
Mikhail Gusarov  wrote:

> The only problem with Cc is that Mailman suppresses duplicate
> messages and hence there is no List-Id: on message.

Err, this makes no sense.  How can Mailman have any knowledge of, and
therefore "do anything" to any message that came by way of a CC?

Now, your mail transfer agent might do duplicate suppression, and if
the direct email reaches you before the one that went through the
mailing list, you won't have a copy that includes the list-id header,
but that's an issue on your end, not with the mailing list software.

Mike.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/1a80237f/attachment.pgp>

[notmuch] Emacs: Problem viewing a thread after reading it once interface

[Carl Worth]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
>   * Showing a thread where the search matches only a subset of the
> thread now opens only the matched messages (in addition to unread
> messages).
> 
> This last feature is the big one---the rest all just happened to come
> along at the same time. One thing that I often do is read some giant
> thread and then tag a single message deep in that thread for dealing
> with later. And previously, doing a search for that tag would bring back
> the entire thread. Now, it opens only the message I'm actually looking
> for. So this is a very welcome change

Unfortunately, this change also introduces a major bug.

After I do a search such as tag:inbox and then view a resulting thread,
(and read it and archive it), then my search results still show that
thread result until I manually update the search view.

But, if I actually try to view that thread again from the search view,
it doesn't work. It previously worked since it would call "notmuch show"
with a query string of "thread:foo" but now calls it with "thread:foo
and tag:inbox" which now matches no messages.

The additional search term wasn't intended to change the returned
messages, (since we're passing the --entire-thread option to see all the
messages in the thread). It was only intended to restrict which messages
get the "match:1" marker added to them.

So maybe we need "notmuch show" to accept a second query string
to do something like:

notmuch show tag:foo --matching tag:inbox

which will display all threads with messages matching "tag:foo" but then
mark only the messages matching "tag:inbox" with the "match:1" marker
for the UI to use.

What do you think, Bart? Did you run into a similar issue with the vim
interface?

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

[notmuch] Trouble with notmuch-show

[Carl Worth]

On Thu, 03 Dec 2009 23:08:31 +0100, Jed Brown  wrote:
> I know html support is still poor, but the following seems worse than
> not showing anything.  When I visit this message, I get prompted to save
> the MIME part and the following is displayed (including all the hidden
> stuff).  Original message is attached.

I ran into this recently as well.

When the HTML formatting works, it's quite impressive. But when it
decides it needs to save some attachment, then notmuch gets tripped up
and ends up displaying a very raw message.

Improvements would be most welcome, from anyone, of course.

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

[notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Carl Worth]

On Thu,  3 Dec 2009 14:16:44 +0530, "Aneesh Kumar K.V"  wrote:
> From: Aneesh Kumar K.V 
> 
> This patch add --format=sender-only option.

I like the idea here, (and agree that an 'R' keybinding would be great).

But surely there's a way to implement this with dramatically less code
duplication?

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

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

> But the above sounds like the List-Id header is unreliable enough to
> be useless.

In my current .sieve setup, I have 93 entries for mailing lists.  87
of them use list-id[1].  3 use list-post.  1 uses 'mailing-list', but
looking at it, could be switched to list-id.  2 use x-mailing-list
(blasted vger.kernel.org).

None of my email gets misfiled, so it seems pretty darn reliable to
me. :)

Now, if you have an MTA that does duplicate suppression based on
message-id, you probably won't see the copy of a message that went to
the list if you're cc:'d on it because the direct copy (sans list-id
header) is likely to arrive first.

I would argue that that's a feature not a bug---the sender, at least,
hopes you will give it closer scrutiny because you were CC:'d.  They're
trying to bring it to your attention.

Besides, in notmuch, what's the difference going to be?  It'll still be
threaded the same, etc., but you'd be able to tell that this one came
to you rather than through the list, no?

(I'm waiting for Debian packages, lazy bastard that I am, so I'm
guessing on that)

> Any reason not to just use something like
> to:notmuch at notmuchmail to match messages sent to a list like this one?

On the linux-kernel list, l-k often isn't in the to: field---or does
notmuch also index the cc: as to:?  If it does, this could work; if
not, FAIL.

Mike.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/8770d8fc/attachment.pgp>

[notmuch] [PATCH] Make search filters handle disjunctive queries.

[Carl Worth]

On Wed,  2 Dec 2009 12:00:35 +0100, Jed Brown  wrote:
> notmuch-search-filter now accepts an arbitrary query and will group if
> necessary so that we get
> 
>   tag:inbox AND (gravy OR biscuits)
> 
> instead of the former
> 
>   tag:inbox AND gravy OR biscuits

Perfect. A nice clean patch for just the one feature. Thanks!

I've pushed this now.

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

[notmuch] Trouble with notmuch-show

[Alexander Botero-Lowry]

On Fri, 04 Dec 2009 11:06:15 -0800, Carl Worth  wrote:
> On Thu, 03 Dec 2009 23:08:31 +0100, Jed Brown  wrote:
> > I know html support is still poor, but the following seems worse than
> > not showing anything.  When I visit this message, I get prompted to save
> > the MIME part and the following is displayed (including all the hidden
> > stuff).  Original message is attached.
> 
> I ran into this recently as well.
> 
> When the HTML formatting works, it's quite impressive. But when it
> decides it needs to save some attachment, then notmuch gets tripped up
> and ends up displaying a very raw message.
> 
Yes. I've notied this but only with spam. I've been not bothered to look
into it because of that, but it's starting to break my spacebar flow, so
I'll try and figure out what's going on.

alex

[notmuch] [PATCH 2/2] * free the response data from 'prompt'

[Carl Worth]

On Wed,  2 Dec 2009 09:11:25 +0200, "Dirk-Jan C. Binnema"  wrote:
> Free the results of the prompt; this patch does the minimal job for that.
> It may be nice to refactor the function a bit. 
> 
> Signed-off-by: Dirk-Jan C. Binnema 

Hi there,

I pushed the first leak fix from this series, but the below is doing a
little more work than necessary.

The getline function is happy to accept a malloc'ed pointer and return
it again if it's large enough, (or otherwise realloc it and return the
result).

So we don't need to free response between each call to prompt, but just
after the last one.

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

[notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Jed Brown]

On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth  wrote:

> But surely there's a way to implement this with dramatically less code
> duplication?

It should just be very short after this series

  id:1259450376-24523-1-git-send-email-jed at 59A2.org

I think --format= should not be used for this, formatting is orthogonal
to selecting recipients.

Speaking of code duplication, perhaps it is worth abstracting options
parsing (or using an existing library).

Jed

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

On Sat, 05 Dec 2009 00:55:20 +0600
Mikhail Gusarov  wrote:

> 
> Twas brillig at 13:52:20 04.12.2009 UTC-05 when
> mdorman at ironicdesign.com did gyre and gimble:
> 
>  MAD> Err, this makes no sense.  How can Mailman have any knowledge
>  MAD> of, and therefore "do anything" to any message that came by way
>  MAD> of a CC?
> 
> for each subscriber:
>   if subscriber.email in message.cc:
>  continue
>   ...
>   # delivery

I stand corrected---it seems like a gigantic misfeature to me, so
much so that I checked and apparently that is exactly how Mailman
works in its default configuration.

My apologies for suggesting you didn't know what you were talking
about.  I made the mistake of assuming sane software.

Mike.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/37421252/attachment-0001.pgp>

[notmuch] Emacs: Problem viewing a thread after reading it once interface

[Bart Trojanowski]

* Carl Worth  [091204 13:55]:
> So maybe we need "notmuch show" to accept a second query string
> to do something like:
> 
>   notmuch show tag:foo --matching tag:inbox
> 
> which will display all threads with messages matching "tag:foo" but then
> mark only the messages matching "tag:inbox" with the "match:1" marker
> for the UI to use.

Right.  That would make sense.
thread ID, like say:

> What do you think, Bart? Did you run into a similar issue with the vim
> interface?

While I have not noticed before, yes... it's there.

-Bart



-- 
WebSig: http://www.jukie.net/~bart/sig/

[notmuch] emacs UI customization

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 01:01:17PM -0500, Jameson Graef Rollins wrote:
> In general, I think it would be really good to put together some
> documentation about all the ways that users can customize the notmuch
> interface.  I would be willing to help with that as well.  It would
> also be nice to allow for customization about of things that are
> currently not that might be controversial.

So I was thinking about this a bit, and it occured to me that a great
thing to do would be to include with notmuch an example emacs
configuration file that includes examples of all (or many) of the ways
one could customize emacs for notmuch, maybe also including ways one
might want to customize the 'message' or 'MML' modes as well.  I, and
I'm sure others, would find it a very useful reference.  I'll start
putting something like this together and forward what I have to the
list.  If others are interested in doing the same, I would be thrilled
to compile what we come up with.

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

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Sat, 28 Nov 2009 18:57:35 -0500, Jameson Graef Rollins  wrote:
> This also removes the Makefile.config from the repository, since it
> shouldn't be kept in the repository and should be created by the
> configure script.

Hi Jamie,

Handling --prefix will be a nice addition to our configure script. So,
thanks!

Your commit message has that flag word of "also" in it, and as it turns
out, the removal of Makefile.config from the repository has actually
happened already. But that was easy enough to fix.

> +# option parsing
> +for option; do
> +if [ "${option%=*}" = '--prefix' ] ; then
> + PREFIX="${option#*=}"
> +fi
> +done

I've gone ahead and committed that now. Then I noticed that we should
really use ${option%%=*} to support the case of an option value
containing an '=' character. So I fixed that.

Then, since I was in the area, I added support to configure for
capturing CFLAGS from the environment, I fixed this (and also "make
CFLAGS=") to also influence C++ compilation (still can be separately
overridden with CXXFLAGS), and I fixed our quiet-compilation mode to
actually print the (user-specified) CFLAGS.

Finally, I documented things by adding a "configure --help" to document
CC, CFLAGS, and --prefix; and by making "make" tell the user about
"./configure" and "./configure --help" when make runs configure
implicitly.

Our configuration system certainly isn't as full-featured yet as a
standard autoconf-based configure script, but I'm quite happy with how
clean it is for both users and developers.

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

[notmuch] [PATCH 3/3] fix Makefile.local to install bash completion definitions as not executable

[Carl Worth]

On Sat, 28 Nov 2009 18:57:37 -0500, Jameson Graef Rollins  wrote:
> - install contrib/notmuch-completion.bash \
> + install -m0644 contrib/notmuch-completion.bash \
>   $(DESTDIR)$(bash_completion_dir)/notmuch

Thanks. I pushed this.

I didn't push the parent commit in the thread, (regarding zlib), since as
mentioned in another reply this is actually a bug in the GMime
pkg-config file.

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

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:12:47PM -0800, Carl Worth wrote:
> Handling --prefix will be a nice addition to our configure script. So,
> thanks!

Yeah, it's definitely needed for the Debian packaging as well.

> Your commit message has that flag word of "also" in it, and as it turns
> out, the removal of Makefile.config from the repository has actually
> happened already. But that was easy enough to fix.

I was thinking that the removal of the Makefile.config from the repo
went together with the new auto-generation of that file from configure
script.  Do you think they still should have been separate patches?

> > +# option parsing
> > +for option; do
> > +if [ "${option%=*}" = '--prefix' ] ; then
> > +   PREFIX="${option#*=}"
> > +fi
> > +done
> 
> I've gone ahead and committed that now. Then I noticed that we should
> really use ${option%%=*} to support the case of an option value
> containing an '=' character. So I fixed that.

Ah, good catch.  Sorry about that.  

> Our configuration system certainly isn't as full-featured yet as a
> standard autoconf-based configure script, but I'm quite happy with how
> clean it is for both users and developers.

Autoconf terrifies me, so I agree I'm quite happy with the simple
configure script we have right now.  If it gets the job done without
having to deal with autoconf then that's great in my book.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/3bd13606/attachment.pgp>

[notmuch] [PATCH 3/3] fix Makefile.local to install bash completion definitions as not executable

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:16:20PM -0800, Carl Worth wrote:
> On Sat, 28 Nov 2009 18:57:37 -0500, Jameson Graef Rollins  finestructure.net> wrote:
> > -   install contrib/notmuch-completion.bash \
> > +   install -m0644 contrib/notmuch-completion.bash \
> > $(DESTDIR)$(bash_completion_dir)/notmuch
> 
> Thanks. I pushed this.
> 
> I didn't push the parent commit in the thread, (regarding zlib), since as
> mentioned in another reply this is actually a bug in the GMime
> pkg-config file.

Great.  That's fine with me (assuming that GMime actually gets fixed
upstream).

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/2ee667b4/attachment.pgp>

[notmuch] [PATCH] Fix typos in documentation strings

[Carl Worth]

On Tue, 01 Dec 2009 08:45:17 -0200, Fernando Carrijo  
wrote:
> One more party, one more joiner, one more patch!  :)

Welcome to the party, Fernando!

> -  "Forward a the current message."
> +  "Forward the current message."
..
> -  "Preficate testing whether current message is unread."
> +  "Predicate testing whether current message is unread."

Clearly I need to stay on top of my notmuch patch-queue better. Then I
could have just applied this patch instead of finding and fixing those
typos separately.

I'll look forward to further patches from you! (And don't worry, I'm
sure I'll keep misspelling things often...)

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

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman  wrote:
> Now, if you have an MTA that does duplicate suppression based on
> message-id, you probably won't see the copy of a message that went to
> the list if you're cc:'d on it because the direct copy (sans list-id
> header) is likely to arrive first.
> 
> I would argue that that's a feature not a bug---the sender, at least,
> hopes you will give it closer scrutiny because you were CC:'d.  They're
> trying to bring it to your attention.

Sure, giving it closer scrutiny is good. But if I expect a search like:

tag:lkml

to match all of my mail that came through the mailing list, but it
actually *misses* mail where the sender wanted me to give extra
scrutiny, then that's a big failure.

> Besides, in notmuch, what's the difference going to be?  It'll still be
> threaded the same, etc., but you'd be able to tell that this one came
> to you rather than through the list, no?

The difference is whether the message is found in a search, (see above).

> (I'm waiting for Debian packages, lazy bastard that I am, so I'm
> guessing on that)

Yeah, I'll get to that (real soon now, I promise.)

> On the linux-kernel list, l-k often isn't in the to: field---or does
> notmuch also index the cc: as to:?  If it does, this could work; if
> not, FAIL.

Yes. In notmuch, all recipient fields, (even Bcc: if a mail happens to
hit your mail store with that intact), all get indexed to a single "to"
prefix. My rationale is that when reading a message it's often very
useful to see whether I was addresses specifically or just CC'ed. But
when _searching_ for a message, it's too fragile to have to guess
whether the recipient was on the To: or CC: header (and too painful to
always type (to:me at example.com or cc:me at example.com).

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

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman  wrote:
> Besides, in notmuch, what's the difference going to be?  It'll still be
> threaded the same, etc., but you'd be able to tell that this one came
> to you rather than through the list, no?

There's one other point I should make here while talking about duplicate
messages, (as determined by identical Message ID).

Currently notmuch just indexes the first version of any given message it
sees, and simply ignores anything else it sees in the future.

We're planning to change it to at least save each of the filenames for
messages with multiple files. That way if some duplicates are deleted,
then notmuch will still be able to find one of the others.

Also, we could make notmuch index duplicate messages and add any
additional terms found to the document for the message. Currently, that
wouldn't make a big difference since notmuch is only indexing the body
and a few specific headers, (From, Subject, To, Cc, Bcc, Messsage-ID,
In-Reply-To, References).

So any differences there should be quite minor (a "[LIST]" prefix in
subject? an extra footer in the boday?), under the assumption that no
mail files will ever exist with the same message ID but disparate
content.

Now, we have a TODO item to allow for indexing additional headers,
(either by default or by user configuration). Once we start doing that,
it probably will make sense to at least index the duplicates.

But when viewing an actual message, I'm still planning on having notmuch
just return an arbitrary filename from the list of filenames associated
with that message. Does anyone see any problem with that? Can you think
of a case where you'd really care about seeing one or the other of
a particular duplicated message?

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

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Fri, 4 Dec 2009 19:20:50 -0500, Jameson Graef Rollins  wrote:
> > Your commit message has that flag word of "also" in it, and as it turns
> > out, the removal of Makefile.config from the repository has actually
> > happened already. But that was easy enough to fix.
> 
> I was thinking that the removal of the Makefile.config from the repo
> went together with the new auto-generation of that file from configure
> script.  Do you think they still should have been separate patches?

No, it was fine. It's just funny to me how often that word "also" in a
commit message seems to end up being a predictor for things later, (like
this case where half of a patch is already implemented, or much worse,
how often a bisect lands on a commit that makes multiple changes).

So I was really just expressing amusement at seeing it again.

> > > +# option parsing
> > > +for option; do
> > > +if [ "${option%=*}" = '--prefix' ] ; then
> > > + PREFIX="${option#*=}"
> > > +fi
> > > +done
> > 
> > I've gone ahead and committed that now. Then I noticed that we should
> > really use ${option%%=*} to support the case of an option value
> > containing an '=' character. So I fixed that.
> 
> Ah, good catch.  Sorry about that.  

No worries. I was just impressed at the tiny amount of code needed for
the parsing here, so ended up looking closer to understand it.

> Autoconf terrifies me, so I agree I'm quite happy with the simple
> configure script we have right now.  If it gets the job done without
> having to deal with autoconf then that's great in my book.

Cool. At least not everyone thinks I'm crazy then. That's
encouraging. :-)

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

[notmuch] Patches in support of linking from org-mode

[da...@tethera.net]

These two patches are pretty much independent. The first is needed by my 
work in progress patch for org-mode to provide links into notmuch 
(http://pivot.cs.unb.ca/git/?p=org-mode.git;a=shortlog;h=refs/heads/notmuch-link).

The second changes the interface of git-show to take the query-string
recently added explicitly as a parameter. This is more an aesthetic
thing, but it means that I don't have to call notmuch-show like
(let notmuch-query-search-string thread-id
 (notmuch-show thread-id))

Hope you like em. I also hope this whole git-send-email thing works out.

David

[notmuch] [PATCH 1/2] notmuch-search-process-filter: add text properties for authors and subject to each line

[da...@tethera.net]

From: David Bremner 

Add functions notmuch-search-find-authors and notmuch-find-subject to
match notmuch-find-thread-id.  These functions are just a wrapper
around get-text-property, but in principle that could change.
---
 notmuch.el |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index c504f46..5925907 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1133,6 +1133,14 @@ Complete list of currently available key bindings:
   "Return the thread for the current thread"
   (get-text-property (point) 'notmuch-search-thread-id))

+(defun notmuch-search-find-authors ()
+  "Return the authors for the current thread"
+  (get-text-property (point) 'notmuch-search-authors))
+
+(defun notmuch-search-find-subject ()
+  "Return the subject for the current thread"
+  (get-text-property (point) 'notmuch-search-subject))
+
 (defun notmuch-search-show-thread ()
   "Display the currently selected thread."
   (interactive)
@@ -1257,7 +1265,9 @@ This function advances the next thread when finished."
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format "%s %-7s %-40s %s (%s)\n" date count 
authors subject tags))
-   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id))
+   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
+   (put-text-property beg (point-marker) 
'notmuch-search-authors authors)
+   (put-text-property beg (point-marker) 
'notmuch-search-subject subject))
  (set 'line (match-end 0)))
  (set 'more nil))
   (delete-process proc
-- 
1.6.5.3

[notmuch] [PATCH 2/2] notmuch-show: add optional argument for query context instead of using global binding notmuch-search-query-string

[da...@tethera.net]

From: David Bremner 

Also modify the one call to notmuch-show in notmuch.el.  This makes
the call (notmuch-show thread-id) will work when there is no binding
for notmuch-search-query-string; e.g. when called from user code
outside notmuch.
---
 notmuch.el |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 5925907..f7048d5 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -949,15 +949,17 @@ All currently available key bindings:
  (lambda()
(hl-line-mode 1) ))

-(defun notmuch-show (thread-id  parent-buffer)
+(defun notmuch-show (thread-id  parent-buffer query-context)
   "Run \"notmuch show\" with the given thread ID and display results.

 The optional PARENT-BUFFER is the notmuch-search buffer from
 which this notmuch-show command was executed, (so that the next
-thread from that buffer can be show when done with this one)."
+thread from that buffer can be show when done with this one).
+
+The optional QUERY-CONTEXT is a notmuch search term. Only messages from the 
thread 
+matching this search term are shown if non-nil. "
   (interactive "sNotmuch show: ")
-  (let ((query notmuch-search-query-string)
-   (buffer (get-buffer-create (concat "*notmuch-show-" thread-id "*"
+  (let ((buffer (get-buffer-create (concat "*notmuch-show-" thread-id "*"
 (switch-to-buffer buffer)
 (notmuch-show-mode)
 (set (make-local-variable 'notmuch-show-parent-buffer) parent-buffer)
@@ -969,7 +971,9 @@ thread from that buffer can be show when done with this 
one)."
   (erase-buffer)
   (goto-char (point-min))
   (save-excursion
-   (call-process notmuch-command nil t nil "show" "--entire-thread" 
thread-id "and (" query ")")
+   (let* ((basic-args (list notmuch-command nil t nil "show" 
"--entire-thread" thread-id))
+   (args (if query-context (append basic-args (list "and (" 
query-context ")")) basic-args)))
+ (apply 'call-process args))
(notmuch-show-markup-messages)
)
   (run-hooks 'notmuch-show-hook)
@@ -1146,7 +1150,7 @@ Complete list of currently available key bindings:
   (interactive)
   (let ((thread-id (notmuch-search-find-thread-id)))
 (if (> (length thread-id) 0)
-   (notmuch-show thread-id (current-buffer))
+   (notmuch-show thread-id (current-buffer) notmuch-search-query-string)
   (error "End of search results"

 (defun notmuch-search-reply-to-thread ()
-- 
1.6.5.3