a proposed change to JSON output to report verification of PGP/MIME signatures.

[Daniel Kahn Gillmor]

hi notmuch folks--

i've been trying to wrap my head around how to get notmuch to support
verifying cryptographically-signed mail.  i'm afraid my current
understanding of the problem space is that it is neither pretty nor
clean.  Sorry for the length of this message.

Scope:
--

I'm focusing initially here only on verifying PGP/MIME cleartext
signatures.  I'm proposing to do the verification in the backend, and to
report on the validity of the signatures to the frontend through
"notmuch show --format=json" (ignoring the other output formats for now).

This mail is only trying to explain how the JSON format might
communicate this information from the backend to the frontend.
(implementation will happen depending on the followup discussion, but i
don't mean for implementation questions to derail this first)


Proposal:
-

No attempt to actually validate the signatures will be made unless the
new --verify flag is passed to "notmuch show".

A signed MIME part will contain a new element "signedby", which is a
list of part numbers identifying signatures that cover this part.

Signature parts (Content-Type: application/pgp-signature) will contain a
new element "signs", which points back to the list of parts this
signature covers.  It will also contain a "sigstatus" member, which is a
list of objects, each of which contain at least the following element:
 * "verified" -- one of the following values:
 "success" (the sig has been tested and is cryptographically valid)
 "failure" (the sig has been tested and does not match)
 "nokey"   (the sig could not be tested because pubkey is missing)
 "error"   (testing the sig failed for some other reason)
 "unknown" (testing was not tried)
 If "verified" is "success" in a "sigstatus" object, then the following
fields might also be present:
 * "signingkey" -- hexadecimal representation of 160-bit fingerprint of
   the signing key
 * "digest" -- the hash over which the sig was made (e.g. "SHA1")
 * "timestamp" -- the time the signature claims to have been made
  (let me know what format i should represent this in)
 * "pubkeyalgo" -- the signing key's asymmetric algorithm (e.g. "RSA")
 * "expires" -- if the signature has an expiration date, it goes here


Example:


currently, the "body" element of a PGP/MIME signed message looks like
this with --format=json:

---
 "body": [
 {
 "content": "here is a test message i signed on 2010-11-11.\n\n
 --dkg\n\n",
 "content-type": "text/plain",
 "id": 1
 },
 {
 "content-type": "application/pgp-signature",
 "filename": "signature.asc",
 "id": 2
 }
 ],
---

It would end up like this (without the --verify flag):

---
 "body": [
 {
 "content": "here is a test message i signed on 2010-11-11.\n\n
 --dkg\n\n",
 "content-type": "text/plain",
 "id": 1,
 "signedby": [ 2 ]
 },
 {
 "content-type": "application/pgp-signature",
 "filename": "signature.asc",
 "id": 2,
 "signs": [ 1 ],
 "sigstatus": [ {
 "verified": "unknown"
 } ]
 }
 ],
---

and here it is with the --verify flag:

---
 "body": [
 {
 "content": "here is a test message i signed on 2010-11-11.\n\n
 --dkg\n\n",
 "content-type": "text/plain",
 "id": 1,
 "signedby": [ 2 ]
 },
 {
 "content-type": "application/pgp-signature",
 "filename": "signature.asc",
 "id": 2,
 "signs": [ 1 ],
 "sigstatus": [ {
 "verified": "success",
 "signingkey": "0EE5BE979282D80B9F7540F1CCD2ED94D21739E9",
 "digest": "SHA512",
 "timestamp": "2010-11-11 22:32:45 -0400",
 "pubkeyalgo": "RSA"
 } ]
 }
 ],
---


Observations:
-

i'm not covering key->userid bindings in this first pass -- it's already
complicated enough to say "the following key did actually sign this
message part".  I'm still not sure whether the front-end or the backend
should be responsible for resolution of key->userid bindings, but i'm OK
punting on that question for the moment.

Multipart messages can have some parts signed and other parts not
signed: think of mailing lists which tack on a footer to each relayed
mail; the footer isn't signed, though the rest of the message is.

One MIME signature can cover more than one MIME part: Think of a signed
e-mail with an attachment. In this case, the signature is actually over
the aggregate, not the individual parts.  For example, a signed two-part
message that says:
 [ (A) "this is the budget for 2011", and (B) an attached spreadsheet ]
is *not* the same as either (A) or (B) signed independently.

A multipart MIME message can contain more than one distinct signature

Re: [PATCH] How to improve the mail handling workflow?

[Michal Sojka]

On Fri, 12 Nov 2010, Darren McGuicken wrote:
> On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> > Here is first a patch that copes with this last point. Whenever you
> > want to archive a thread, it finds whether you forgot to add a custom
> > "user" tag to a message, and if so asks you for a tag to add before
> > archiving. That way, I no longer have messages without any tags.
> 
> Hmm, this would be very irritating in my own workflow in which I really
> only use a small number of tags on a fraction of my total mail archive
> to differentiate mail type or content which can't otherwise be
> determined from the indexed plain text of the message (I don't like to
> add a 'notmuch' tag to mail from the list for instance since a saved
> search for mail sent to the list address does exactly the same thing).

I agree with you in that in many cases tags can be replaced by saved
searches. Last time I did it, i.e. used saved searches to distinguish
messages from different mailing lists, the result was that it took very
long time (something like 5 seconds) to show notmuch-hello screen. There
is a bug in notmuch hello, as I described in
id:"87wrtz3pw2@steelpick.2x.cz".

Additionally, I compared the speed of command line searches for tags and
for the whole email addresses and even without the bug mentioned above,
the search for to: is usually slower than the search for tag:.

And finally, there are some mailing lists, which changed their address
in the past or have multiple aliases and in this case you always has to
use a more complex search to match all messages to that mailing list and
these searches are even more slow than tag searches.

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

Re: Second draft of logging patches

[Michal Sojka]

On Wed, 10 Nov 2010, David Bremner wrote:
> On Sun, 24 Oct 2010 18:01:02 -0300, da...@tethera.net wrote:
> > Here is my second try at logging, taking into account the feedback I
> > got from Rob and Michal.  There is definitely some tidying to do; in
> > particular I know the protoypes in public headers need
> > documentation. Also, I should add a configuration option to
> > enable configuration by command or something like that.
> 
> I had a thought of a possibly interesting application of the (yet to be
> written) log playback code. It could be use to implement a simple
> queuing system where commands are only logged but not actually run on
> the database. I'm not sure about the performance implications, but it
> could be interesting because it eliminates the need to have a server
> running in order to eliminate write contention for the tag database.
> The "queue runner" could be as simple as a cron job, or it could be
> something spawned by one of the queue operations; the point would be
> that queueing could continue while the snapshot of the queue was run.

Hi, I think this could be very interesting and that it could make the
tagging operation asynchronous and thus faster as was suggested by
Sebastian in id:"87k4l5whwe@sspaeth.de".

In this case, however, the queuing should happen in the client, not in
the library.

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

splittng threads [was: Re: Combining threads]

[Daniel Kahn Gillmor]

(hi list -- i'm new here; don't be afraid to explain things to me that
seem obvious to you, or correct my vocabulary if i'm using it wrong)

On 11/12/2010 08:11 PM, Carl Worth wrote:
> But I suppose it's as simple a matter of creating a new "top-level
> message" term in the database. The split operation would set this
> term. The explicit join operation would clear it, and the implicit join
> operation would have to be made to respect it by avoiding merging any
> top-level messages as a child of some other message. I haven't thought
> through exactly how that would work in the implementation, but hopefully
> it wouldn't be too hard.

my current understanding is that a not-uncommon use case is to have two
separate notmuch instances, synchronized by syncing maildirs and
tagsets.  Would such a thread-split be syncable between two notmuch
instances?

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101112/512b0e75/attachment-0001.pgp>

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

On Fri, 12 Nov 2010 17:05:23 +, David Edmondson  wrote:
> On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> >  - Processing mails which do not have any automatically added tag is
> >boring, because I need to press several keys to archive them: "+" to
> >add a tag, and then "a". If I forget about +, then my mail is
> >impossible to find.
> 
> I don't understand this at all. You can find messages by searching for
> anything about them (sender, subject, body). In what way is it
> 'impossible'?

Impossible was a bit strong. But if for instance I hit space in a
inboxed mail in a thread with one mail, without taking too much time to
study it, then I will know that I forgot to process one mail without
knowing which one it is. I used to find such mails by searching for
mails without any tags, but this was cumbersome. My present patch is a
better attempt to fix this.

> Using tags to group things is great, I agree, but coercing me into
> adding tags that I don't really need seems strange.

It is just a way to ensure that all your mails are properly filed, and
file them quickly.

Matthieu

splittng threads [was: Re: Combining threads]

[Daniel Kahn Gillmor]

(hi list -- i'm new here; don't be afraid to explain things to me that
seem obvious to you, or correct my vocabulary if i'm using it wrong)

On 11/12/2010 08:11 PM, Carl Worth wrote:
> But I suppose it's as simple a matter of creating a new "top-level
> message" term in the database. The split operation would set this
> term. The explicit join operation would clear it, and the implicit join
> operation would have to be made to respect it by avoiding merging any
> top-level messages as a child of some other message. I haven't thought
> through exactly how that would work in the implementation, but hopefully
> it wouldn't be too hard.

my current understanding is that a not-uncommon use case is to have two
separate notmuch instances, synchronized by syncing maildirs and
tagsets.  Would such a thread-split be syncable between two notmuch
instances?

--dkg



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

[PATCH] How to improve the mail handling workflow?

[David Edmondson]

On Fri, 12 Nov 2010 18:48:12 +0100, Matthieu Lemerre  wrote:
> It is just a way to ensure that all your mails are properly filed, and
> file them quickly.

We should just add a hook that you can use, then.

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

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

Hi, Jamie.

> 
> >  - I often find myself hitting the spacebar too much, which ends up with
> >some of my new messages being removed from all of their tags, which
> >make them very difficult to find. I don't think the spacebar should
> >remove the inbox tag at all. It should only change the unread tag.
> 
> I agree that the function currently bound to space bar is annoying.  I
> am actually in the middle of preparing a patch to fix this.  I think
> that space should just scroll through the open messages.  I don't want
> it to archive anything, or pop out of the currently viewed thread.  I
> think this function is too aggressive as is.

Great! Then I'll be waiting for your patch.

> >  - It does not provide a command for deleting mails. We were several
> >people who provided patches to add a 'd' keybinding to support
> >deletion. I provided a complex patch for that (that added "and not
> >tag:deleted" to all requests", but I now think that just adding a
> >"deleted" tag and removing the "inbox" tag would be sufficient).
> 

[...]


> I do *not* think that adding the "deleted" tag should remove the inbox
> tag.  If you want to view your inbox without seeing the deleted
> messages, then just use the search "tag:inbox and not tag:deleted".

Good idea, yes.

> 
> >  - Processing mails which do not have any automatically added tag is
> >boring, because I need to press several keys to archive them: "+" to
> >add a tag, and then "a". If I forget about +, then my mail is
> >impossible to find.
> 
> Again, I achieve archiving with some simple custom functions:
> 

[...]

OK, but this does not solve the problem of forgetting to put a tag when
archiving a thread. Also my patch allows to put a tag without having to
press "+" (so you don't have to think about adding tags when you archive
your mail, you only have to press "a" and be reminded about it).

Matthieu

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

On Fri, 12 Nov 2010 15:39:37 +, Darren McGuicken  wrote:
> On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> > Here is first a patch that copes with this last point. Whenever you
> > want to archive a thread, it finds whether you forgot to add a custom
> > "user" tag to a message, and if so asks you for a tag to add before
> > archiving. That way, I no longer have messages without any tags.
> 
> Hmm, this would be very irritating in my own workflow in which I really
> only use a small number of tags on a fraction of my total mail archive
> to differentiate mail type or content which can't otherwise be
> determined from the indexed plain text of the message (I don't like to
> add a 'notmuch' tag to mail from the list for instance since a saved
> search for mail sent to the list address does exactly the same thing).

I prefer to add tags, for the following reasons:

 - If I want to search through a mailing list, I don't have to remember
   its address. Saved searchs solve the problem only partly, because I
   am not able to make complex queries involving several saved
   searches. This could be solved only by making notmuch aware of saved
   searches.

 - I have some collection of emails that belong to a topic, even if the
   topic does not appear in it. For instance, if I receive mails about a
   project "foo", it can happen that foo is not mentionned in it.

 - I think that adding more informations to mail help find it, even if
   it fills my screen with tag names. Basically, I use tags for several
   different things:
 - to label information 
 - to indicate actions that have to be done (like todo, waiting, done, etc)
 - the other are mail-related tags (inbox, attachment, replied etc).

> I agree that the spacebar does too much if you're just using a search on
> the inbox tag and want something to stay visible even when you've
> quickly spacebar'd through a thread and archived it, but in my case that
> was easily solved by creating a new default saved search called 'todo'
> which collects unread, manually tagged 'todo' and mail matching a number
> of other criteria into one place.  When something has been followed-up
> on, I remove the tag.

But the space bar removes the unread tag, so I do not see how it
helps... By default, hitting the space bar throughout a thread would
remove every tag from the thread, so you keep asking "where was the mail
in my inbox that I have read and I can't find anymore?"
> 
> Colouring threads using notmuch-search-line-faces is also very useful in
> that one-stop 'todo' view.
> 
> Would any of that work for you?  Why are plain text or header searches
> not able to find the mail you're looking for?

Of course, I can change my patch so that its behaviour can be customized
using a variable.

Thanks,
Matthieu

[PATCH] emacs: remove thread archiving from show-advance function

[David Edmondson]

On Fri, 12 Nov 2010 10:57:53 -0500, Jameson Rollins  wrote:
> I believe it's important to have a function to scroll through open
> messages in the currently viewed thread, and ' ' is the most logical
> keybinding for that.  However, the current function is far too
> agressive in automatically archiving the thread and moving to the next
> thread when getting to the end of the current thread.  This patch
> changes this function to just stop when it gets to the end of the
> thread, thereby giving the user a chance to act on the thread how they
> wish.

Whether space moves to the next thread should be configurable, I
think. Similarly whether or not it archives the thread. I'm not worried
about which is the default behaviour.

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

Re: Combining threads

[Carl Worth]

On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson  wrote:
> Sometimes I get email from people with broken email clients that seem to
> break threading.  I remember that sup had a method of combining two threads
> into one.  Does notmuch have a similar feature?  Is it even possible to
> force it to glue two threads together and treat them as one?

There's no support for this in the command-line interface, nor even the
library interface. But internally in the implementation there is a
function that joins two threads together. It looks like this:

static notmuch_status_t
_merge_threads (notmuch_database_t *notmuch,
const char *winner_thread_id,
const char *loser_thread_id);

This function is used regularly---for example, when two child messages
arrive separately and each get their own thread[*], then later the parent
arrives. At that point the two threads are merged with the above
function.

Now, if we did have good support for thread joining I could join your
request with the reply I gave the last time the question came up. ;-)

That was in this email:

id:87vd4k6956@yoom.home.cworth.org

And since we don't yet have a good web-based archive that lets you just
plug in message IDs, I'll quote my reply here:

> On Sat, 08 May 2010 14:36:26 +0200, Arvid Picciani  wrote:
> > Most of my mail comes from the 50MLs i'm subscribed to. Unfortunately
> > some MUAs suck that much, they don't even respond in threads.
> > My idea how to fix them would be:
>
> People have previously asked for a feature to combine messages into the
> same thread.
>
> And it would actually be a fairly simple operation. Perhaps it could be
> something like:
>
> notmuch set-thread $(notmuch search --threads ) 
>
> The bigger problem is that as soon as we have an operation to join
> threads, people are going to need an operation to split threads. (And
> some people want this already for cases where people reply when they
> should have composed a new message.)
>
> The split case is harder in that it will require some extra stashing of
> information about the intent of the split, (otherwise, the current logic
> will recombine things when a future message arrives that References:
> messages from two split threads).
>
> So I think we'd need a proposal to handle that before we could do
> splitting. The proposal I'm looking for here would be at the database
> level, not the command-line level.
>
> -Carl

Here are some new thoughts on this today:

The join case is easy. Simply expose the function above and then add a
command like:

notmuch join id: id:

As I mentioned above, adding this command would almost force the
addition of a "notmuch split" command as well, (even if only to undo an
accidental join). We could easily implement a "notmuch split" that would
function perfectly for undo:

notmuch split id:
# Split  from its parent thread, making it a
# top-level message in a new thread (with all of its existing
# children)

Without any additional "stashing of intent" this would work for the
"undo of a join" operation, since those messages are inherently
separate, (they don't have any common references). It wouldn't work well
for splitting an originally intact thread since, (as I mentioned above),
future messages could undo the split by triggering a _merge_threads
call.

But I suppose it's as simple a matter of creating a new "top-level
message" term in the database. The split operation would set this
term. The explicit join operation would clear it, and the implicit join
operation would have to be made to respect it by avoiding merging any
top-level messages as a child of some other message. I haven't thought
through exactly how that would work in the implementation, but hopefully
it wouldn't be too hard.

Anyone interested in tackling this task? It might be interesting. :-)

-Carl

[*] To be strict here: In the common case, both children will reference
a common message-ID and notmuch is clever enough to notice this and
merge the children even before the parent arrives. But it's still
possible to construct mails that start out in separate threads and later
get merged when a common parent arrives.


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

Combining threads

[Carl Worth]

On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson  
wrote:
> Sometimes I get email from people with broken email clients that seem to
> break threading.  I remember that sup had a method of combining two threads
> into one.  Does notmuch have a similar feature?  Is it even possible to
> force it to glue two threads together and treat them as one?

There's no support for this in the command-line interface, nor even the
library interface. But internally in the implementation there is a
function that joins two threads together. It looks like this:

static notmuch_status_t
_merge_threads (notmuch_database_t *notmuch,
const char *winner_thread_id,
const char *loser_thread_id);

This function is used regularly---for example, when two child messages
arrive separately and each get their own thread[*], then later the parent
arrives. At that point the two threads are merged with the above
function.

Now, if we did have good support for thread joining I could join your
request with the reply I gave the last time the question came up. ;-)

That was in this email:

id:87vd4k6956.fsf at yoom.home.cworth.org

And since we don't yet have a good web-based archive that lets you just
plug in message IDs, I'll quote my reply here:

> On Sat, 08 May 2010 14:36:26 +0200, Arvid Picciani  wrote:
> > Most of my mail comes from the 50MLs i'm subscribed to. Unfortunately
> > some MUAs suck that much, they don't even respond in threads.
> > My idea how to fix them would be:
>
> People have previously asked for a feature to combine messages into the
> same thread.
>
> And it would actually be a fairly simple operation. Perhaps it could be
> something like:
>
> notmuch set-thread $(notmuch search --threads ) 
>
> The bigger problem is that as soon as we have an operation to join
> threads, people are going to need an operation to split threads. (And
> some people want this already for cases where people reply when they
> should have composed a new message.)
>
> The split case is harder in that it will require some extra stashing of
> information about the intent of the split, (otherwise, the current logic
> will recombine things when a future message arrives that References:
> messages from two split threads).
>
> So I think we'd need a proposal to handle that before we could do
> splitting. The proposal I'm looking for here would be at the database
> level, not the command-line level.
>
> -Carl

Here are some new thoughts on this today:

The join case is easy. Simply expose the function above and then add a
command like:

notmuch join id: id:

As I mentioned above, adding this command would almost force the
addition of a "notmuch split" command as well, (even if only to undo an
accidental join). We could easily implement a "notmuch split" that would
function perfectly for undo:

notmuch split id:
# Split  from its parent thread, making it a
# top-level message in a new thread (with all of its existing
# children)

Without any additional "stashing of intent" this would work for the
"undo of a join" operation, since those messages are inherently
separate, (they don't have any common references). It wouldn't work well
for splitting an originally intact thread since, (as I mentioned above),
future messages could undo the split by triggering a _merge_threads
call.

But I suppose it's as simple a matter of creating a new "top-level
message" term in the database. The split operation would set this
term. The explicit join operation would clear it, and the implicit join
operation would have to be made to respect it by avoiding merging any
top-level messages as a child of some other message. I haven't thought
through exactly how that would work in the implementation, but hopefully
it wouldn't be too hard.

Anyone interested in tackling this task? It might be interesting. :-)

-Carl

[*] To be strict here: In the common case, both children will reference
a common message-ID and notmuch is clever enough to notice this and
merge the children even before the parent arrives. But it's still
possible to construct mails that start out in separate threads and later
get merged when a common parent arrives.
-- 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/20101112/11f267d1/attachment.pgp>

[PATCH] How to improve the mail handling workflow?

[David Edmondson]

On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
>  - Processing mails which do not have any automatically added tag is
>boring, because I need to press several keys to archive them: "+" to
>add a tag, and then "a". If I forget about +, then my mail is
>impossible to find.

I don't understand this at all. You can find messages by searching for
anything about them (sender, subject, body). In what way is it
'impossible'?

Using tags to group things is great, I agree, but coercing me into
adding tags that I don't really need seems strange.

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

[PATCH] How to improve the mail handling workflow?

[Darren McGuicken]

On Fri, 12 Nov 2010 17:35:22 +0100, Matthieu Lemerre  wrote:
> I prefer to add tags, for the following reasons:

It sounds like we do much the same things with our mail except that your
approach is quite disciplined and mine quite lazy :-)

>  - If I want to search through a mailing list, I don't have to
>  remember its address. Saved searchs solve the problem only partly,
>  because I am not able to make complex queries involving several saved
>  searches. This could be solved only by making notmuch aware of saved
>  searches.

[...]

> By default, hitting the space bar throughout a thread would remove
> every tag from the thread, so you keep asking "where was the mail in
> my inbox that I have read and I can't find anymore?"

As it's so quick, I tend to search my entire archive, even for new
messages, through progressive stages of filtering (which is really all
that a saved search is) starting off knowing only vaguely what it is
that I'm looking for.

For instance 'there was something on the notmuch list about printing
format issues recently' would be 's to:notmuch' 'f print' 'f format' etc
until I see what I'm looking for (or something similar) in the results.
That particular set of steps gives me a buffer with 24 threads in it,
the second of which is what I was looking for.  I tend not to even
bother with subject header based searches unless I know for sure that
what I'm looking for had an unusual subject.

It sounds like a lot of work when I write it out long-form, but it's
incredibly intuitive and so far always gets me what I need.

I can see your approach has its own merits though.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101112/51ae10e5/attachment.pgp>

Re: notmuchsync: handling of the deleted tag

[Carl Worth]

On Fri, 12 Nov 2010 13:04:16 -0800, Dirk Hohndel  wrote:
> > notmuchsync. Seriously, what does notmuchsync still provide that notmuch
> > cannot do? I wonder if I shouldn't stick a "deprecated" warning on it.
> 
> Please don't! I use it all the time:

Excellent. I love getting more feedback from users so that we can
understand things better.

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

Can you describe this use case in a bit more detail? I'd like to
understand what needs to be done to support this.

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

This one is a simple one-liner as of notmuch 0.4:

notmuch search --output=files tag:deleted -print0 | xargs -0 rm

And that's something we could even add to a keybinding in the emacs
interface[*].

Meanwhile, I know people have asked for keybindings to even just add the
"deleted" tag before. What I still want for that is good support for
being able to configure tags that cause mails to be automatically
omitted from search results---unless the user is explicitly searching
for mails with that tag. So for example, I would add "deleted" and
"spam" to such a list and never see mails with that tag unless I go
looking for a mis-tagged email with a search like "from:someone and
tag:spam".

I think the above should be fairly easy. One way to do it is to just
implicitly add "and not (tag:deleted or tag:spam)" to all searches. And
then simply omit the relevant portion of this if the original search
terms happen to mention tag:deleted or tag:spam. This is what sup does,
for example.

-Carl

[*] Personally, I don't want a keybinding for actual deletion of mail
files. As long as nothing appears in searches, then I'd prefer the
tagged messages not be deleted right away. Instead, I'd like a cron job
to delete appropriately tagged messages after some safety interval (a
month, say). For that, I'd like better support for specifying message
dates of course, (that's been on my todo list for some time). But
really, I care about the date of the tag, not the date of the
message. We don't save information like that, but the cron script could
do something cheesy like implement counters in tags:

  # XXX: Entirely untested!

  # Days after a mail is tag:deleted when the mail will be deleted
  EXPIRATION=30
  for days in $(seq 0 $((EXPIRATION - 1))); do
notmuch tag +expire-$((days)) -expire-$((days + 1)) tag:expire-$(days + 1))
  done

  notmuch search --output=files tag:expire-0 and tag:deleted -print0 | xargs -0 
rm
  notmuch tag -expire-0 tag:expire-0

  notmuch tag +expire-$EXPIRATION +expiring tag:deleted and not tag:expiring
  notmuch tag -expiring not tag:deleted

OK. Looking at that---that's *really* cheesy. Perhaps we should come up
with a sane way to do this. Hooks on the addition or deletion of the
"deleted" tag that set/cleared a date value in the message document in
the database might be much cleaner.

But the above might actually work for now. Anyone brave enough to test
it?

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


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

notmuchsync: handling of the deleted tag

[Carl Worth]

On Fri, 12 Nov 2010 13:04:16 -0800, Dirk Hohndel  
wrote:
> > notmuchsync. Seriously, what does notmuchsync still provide that notmuch
> > cannot do? I wonder if I shouldn't stick a "deprecated" warning on it.
> 
> Please don't! I use it all the time:

Excellent. I love getting more feedback from users so that we can
understand things better.

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

Can you describe this use case in a bit more detail? I'd like to
understand what needs to be done to support this.

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

This one is a simple one-liner as of notmuch 0.4:

notmuch search --output=files tag:deleted -print0 | xargs -0 rm

And that's something we could even add to a keybinding in the emacs
interface[*].

Meanwhile, I know people have asked for keybindings to even just add the
"deleted" tag before. What I still want for that is good support for
being able to configure tags that cause mails to be automatically
omitted from search results---unless the user is explicitly searching
for mails with that tag. So for example, I would add "deleted" and
"spam" to such a list and never see mails with that tag unless I go
looking for a mis-tagged email with a search like "from:someone and
tag:spam".

I think the above should be fairly easy. One way to do it is to just
implicitly add "and not (tag:deleted or tag:spam)" to all searches. And
then simply omit the relevant portion of this if the original search
terms happen to mention tag:deleted or tag:spam. This is what sup does,
for example.

-Carl

[*] Personally, I don't want a keybinding for actual deletion of mail
files. As long as nothing appears in searches, then I'd prefer the
tagged messages not be deleted right away. Instead, I'd like a cron job
to delete appropriately tagged messages after some safety interval (a
month, say). For that, I'd like better support for specifying message
dates of course, (that's been on my todo list for some time). But
really, I care about the date of the tag, not the date of the
message. We don't save information like that, but the cron script could
do something cheesy like implement counters in tags:

  # XXX: Entirely untested!

  # Days after a mail is tag:deleted when the mail will be deleted
  EXPIRATION=30
  for days in $(seq 0 $((EXPIRATION - 1))); do
notmuch tag +expire-$((days)) -expire-$((days + 1)) tag:expire-$(days + 1))
  done

  notmuch search --output=files tag:expire-0 and tag:deleted -print0 | xargs -0 
rm
  notmuch tag -expire-0 tag:expire-0

  notmuch tag +expire-$EXPIRATION +expiring tag:deleted and not tag:expiring
  notmuch tag -expiring not tag:deleted

OK. Looking at that---that's *really* cheesy. Perhaps we should come up
with a sane way to do this. Hooks on the addition or deletion of the
"deleted" tag that set/cleared a date value in the message document in
the database might be much cleaner.

But the above might actually work for now. Anyone brave enough to test
it?

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

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

Hi,

I think that there are several irritating nitpicks when using notmuch in
a typical mail workflow.

I don't know how other people process their email. I for myself use the
following method:

1. The script I use to fetch new mails tries to add tags if it can. For
   instance, all new mails from the notmuch mailing lists appears with
   tags "(inbox,unread,notmuch)".

2. When processing mails, I manually add some tag to the mails for which
   no tags were added automatically. Then I archive the mail (remove its
   inbox tag).

3. Sometimes I keep mails in my inbox, for instance if I am expecting a
   specific mail and do not want to take the time to process the others.

The emacs interface to notmuch gets in my way in at least several
manners:

 - I often find myself hitting the spacebar too much, which ends up with
   some of my new messages being removed from all of their tags, which
   make them very difficult to find. I don't think the spacebar should
   remove the inbox tag at all. It should only change the unread tag.

 - It does not provide a command for deleting mails. We were several
   people who provided patches to add a 'd' keybinding to support
   deletion. I provided a complex patch for that (that added "and not
   tag:deleted" to all requests", but I now think that just adding a
   "deleted" tag and removing the "inbox" tag would be sufficient).

 - Processing mails which do not have any automatically added tag is
   boring, because I need to press several keys to archive them: "+" to
   add a tag, and then "a". If I forget about +, then my mail is
   impossible to find.

Here is first a patch that copes with this last point. Whenever you want
to archive a thread, it finds whether you forgot to add a custom "user"
tag to a message, and if so asks you for a tag to add before
archiving. That way, I no longer have messages without any tags.

I probably will send patches to handle the other bullet points to, but
first I would be happy to hear your comments about this, or learn about
how you process your mail using the current interface.

Thanks,
Matthieu Lemerre

-- next part --
A non-text attachment was scrubbed...
Name: out.patch
Type: text/x-diff
Size: 2244 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101112/2b3f0836/attachment.patch>

[PATCH] How to improve the mail handling workflow?

[Darren McGuicken]

On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> Here is first a patch that copes with this last point. Whenever you
> want to archive a thread, it finds whether you forgot to add a custom
> "user" tag to a message, and if so asks you for a tag to add before
> archiving. That way, I no longer have messages without any tags.

Hmm, this would be very irritating in my own workflow in which I really
only use a small number of tags on a fraction of my total mail archive
to differentiate mail type or content which can't otherwise be
determined from the indexed plain text of the message (I don't like to
add a 'notmuch' tag to mail from the list for instance since a saved
search for mail sent to the list address does exactly the same thing).

I agree that the spacebar does too much if you're just using a search on
the inbox tag and want something to stay visible even when you've
quickly spacebar'd through a thread and archived it, but in my case that
was easily solved by creating a new default saved search called 'todo'
which collects unread, manually tagged 'todo' and mail matching a number
of other criteria into one place.  When something has been followed-up
on, I remove the tag.

Colouring threads using notmuch-search-line-faces is also very useful in
that one-stop 'todo' view.

Would any of that work for you?  Why are plain text or header searches
not able to find the mail you're looking for?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101112/b5ae9691/attachment.pgp>

Support for multiple filenames (in notmuch library)

[Jameson Rollins]

On Thu, 11 Nov 2010 05:11:09 -0800, Carl Worth  wrote:
> As part of my recent work to fix up the maildir-flags synchronization
> patches, I found myself needing to access the complete list of filenames
> for a given message. So I added the following, new public function to
> libnotmuch:
> 
>   notmuch_filenames_t *
>   notmuch_message_get_filenames (notmuch_message_t *message);

Hey, Carl.  This is really great.  Thanks so much for getting this
working.

> Others want similar support in the command-line tools, (to show
> duplicate files rather than suppressing them). This would be fairly easy
> to add now. Does anyone have recommendations for suitable command-line
> arguments?
> 
>   notmuch search --with-duplicates
> 
> Or something else??

I think this is definitely the way to go.  It at least makes sense from
my perspective, and then we could add a switch to the emacs ui to return
those messages so that those of us who wanted to could see them in our
search results.

Thanks again for all the great work.

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

[PATCH] emacs: remove thread archiving from show-advance function

[Jameson Rollins]

On Fri, 12 Nov 2010 17:12:18 +, David Edmondson  wrote:
> Whether space moves to the next thread should be configurable, I
> think. Similarly whether or not it archives the thread. I'm not worried
> about which is the default behaviour.

Hey, David.  I thought about that, but decided I'd go ahead and submit
this patch to see what kind of reaction it got.  I'm a little surprised
that anyone would actually like the current behavior, but to each their
own!  I'll look into making it a config option when I get the chance.

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

Re: notmuchsync: handling of the deleted tag

[Carl Worth]

On Fri, 12 Nov 2010 08:30:36 +0100, Sebastian Spaeth  
wrote:
> On Thu, 11 Nov 2010 17:27:34 -0800, Carl Worth  wrote:
> > 'R' on _any_ filename  -> "replied" tag gets added
> > 'T' on _all_ filenames -> "deleted" tag gets added
> > 'S' on _any_ filename  -> "unread" tag gets removed
> > So maybe something like that?
> 
> Maybe, but that sounds like a horribly complex configuration, in which
> the user has to really think through what he wants (and can still make
> blunders). :)

Yes. But a common user configurations could be as simple as:

R:replied; t:todo; d:done;

or so. And that would be hugely powerful because it would allow for
remote synchronization of tags with tools that exist *today* (and
perhaps[*] even through imap servers where the user cannot install
custom software).

[*] This is a point I'm not clear on. Would a tool like offlineimap be
able to push custom filenames through to the remote end with standard
imap servers?

But we could also have a well-documented default configuration
that happens to include two of the more complex cases:

R:replied; T* : deleted; S : ~unread;

So questions of syntax aside, I'm not convinced that this idea is
insane. And if it covers all of the synchronization needs that people
really have.

> Right, you pushed the ball in my court. The only problem is that -- with
> the arrival of maildir sync -- I lost my motivation to work on
> notmuchsync.

Hehe. Oh well, someone else will have to go play with
notmuch_message_get_filenames. I think the people interested in writing
a "gmail importer" want this as well.

> Seriously, what does notmuchsync still provide that notmuch
> cannot do? I wonder if I shouldn't stick a "deprecated" warning on it.

That's actually a question I wanted to ask you. If notmuch 0.5 actually
does everything that notmuchsync did, then that's great news. If there
is any missing functionality, then let's get that into notmuch.

Thanks for the discussion.

-Carl

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


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

notmuchsync: handling of the deleted tag

[Carl Worth]

On Fri, 12 Nov 2010 08:30:36 +0100, Sebastian Spaeth  
wrote:
> On Thu, 11 Nov 2010 17:27:34 -0800, Carl Worth  wrote:
> > 'R' on _any_ filename  -> "replied" tag gets added
> > 'T' on _all_ filenames -> "deleted" tag gets added
> > 'S' on _any_ filename  -> "unread" tag gets removed
> > So maybe something like that?
> 
> Maybe, but that sounds like a horribly complex configuration, in which
> the user has to really think through what he wants (and can still make
> blunders). :)

Yes. But a common user configurations could be as simple as:

R:replied; t:todo; d:done;

or so. And that would be hugely powerful because it would allow for
remote synchronization of tags with tools that exist *today* (and
perhaps[*] even through imap servers where the user cannot install
custom software).

[*] This is a point I'm not clear on. Would a tool like offlineimap be
able to push custom filenames through to the remote end with standard
imap servers?

But we could also have a well-documented default configuration
that happens to include two of the more complex cases:

R:replied; T* : deleted; S : ~unread;

So questions of syntax aside, I'm not convinced that this idea is
insane. And if it covers all of the synchronization needs that people
really have.

> Right, you pushed the ball in my court. The only problem is that -- with
> the arrival of maildir sync -- I lost my motivation to work on
> notmuchsync.

Hehe. Oh well, someone else will have to go play with
notmuch_message_get_filenames. I think the people interested in writing
a "gmail importer" want this as well.

> Seriously, what does notmuchsync still provide that notmuch
> cannot do? I wonder if I shouldn't stick a "deprecated" warning on it.

That's actually a question I wanted to ask you. If notmuch 0.5 actually
does everything that notmuchsync did, then that's great news. If there
is any missing functionality, then let's get that into notmuch.

Thanks for the discussion.

-Carl

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

Re: notmuchsync: handling of the deleted tag

[Dirk Hohndel]

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

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

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

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

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

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

notmuchsync: handling of the deleted tag

[Dirk Hohndel]

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

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

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

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

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

/D

[PATCH] emacs: Improved printing support.

[David Edmondson]

---

More usable (I'm trying 'muttprint then evince').

 emacs/Makefile.local   |3 +-
 emacs/notmuch-print.el |   75 
 emacs/notmuch-show.el  |   51 
 3 files changed, 128 insertions(+), 1 deletions(-)
 create mode 100644 emacs/notmuch-print.el

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index c5280f1..df87427 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -13,7 +13,8 @@ emacs_sources := \
$(dir)/notmuch-maildir-fcc.el \
$(dir)/notmuch-message.el \
$(dir)/coolj.el \
-   $(dir)/notmuch-lkml.el
+   $(dir)/notmuch-lkml.el \
+   $(dir)/notmuch-print.el

 emacs_images := \
$(dir)/notmuch-logo.png
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
new file mode 100644
index 000..62e380c
--- /dev/null
+++ b/emacs/notmuch-print.el
@@ -0,0 +1,75 @@
+;; notmuch-print.el --- printing messages from notmuch.
+;;
+;; Copyright ? David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see .
+;;
+;; Authors: David Edmondson 
+
+(defcustom notmuch-print-mechanism 'notmuch-print-lpr
+  "How should printing be done?"
+  :group 'notmuch
+  :type '(choice
+ (function :tag "Use lpr" notmuch-print-lpr)
+ (function :tag "Use ps-print" notmuch-print-ps-print)
+ (function :tag "Use ps-print then evince" 
notmuch-print-ps-print/evince)
+ (function :tag "Use muttprint" notmuch-print-muttprint)
+ (function :tag "Use muttprint then evince" 
notmuch-print-muttprint/evince)
+ (function :tag "Using a custom function")))
+
+(defmacro notmuch-print-with-file (filename &rest body)
+  `(with-temp-buffer
+ (insert-file-contents ,filename)
+ (setq buffer-modified-p nil)
+ , at body))
+
+(defun notmuch-print-lpr (filename)
+  (notmuch-print-with-file filename
+  (lpr-buffer)))
+
+(defun notmuch-print-ps-print (filename)
+  (notmuch-print-with-file filename
+  (ps-print-buffer)))
+
+(defun notmuch-print-ps-print/evince (filename)
+  (let ((ps-file (make-temp-file "notmuch")))
+(notmuch-print-with-file filename
+(ps-print-buffer ps-file)
+(async-shell-command (concat "evince " ps-file)
+
+(defun notmuch-print-muttprint (filename)
+  (shell-command
+   (concat "muttprint "
+  "--file " (shell-quote-argument filename) " "
+  ;; Show the tags.
+  "--printed-headers Date_To_From_CC_Newsgroups_*Subject*_/Tags/ ")))
+
+(defun notmuch-print-muttprint/evince (filename)
+  (let ((ps-file (make-temp-file "notmuch")))
+(call-process-shell-command
+ (concat "muttprint "
+"--file " (shell-quote-argument filename) " "
+;; Show the tags.
+"--printed-headers Date_To_From_CC_Newsgroups_*Subject*_/Tags/ "
+"--printer \"TO_FILE:" (shell-quote-argument ps-file) "\""))
+(async-shell-command (concat "evince " ps-file
+
+(defun notmuch-print-message (filename)
+  (funcall notmuch-print-mechanism filename))
+
+;;
+
+(provide 'notmuch-print)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index aa89cfd..002c2fd 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -32,6 +32,7 @@
 (require 'notmuch-query)
 (require 'notmuch-wash)
 (require 'notmuch-mua)
+(require 'notmuch-print)

 (declare-function notmuch-call-notmuch-process "notmuch" (&rest args))
 (declare-function notmuch-fontify-headers "notmuch" nil)
@@ -174,6 +175,51 @@ Set `notmuch-show-address-simplication' to:
   mm-handle (> (notmuch-count-attachments mm-handle) 1
   (message "Done"))

+(defun notmuch-show-with-message-as-text (fn)
+  "Apply function `fn' to a text representation of the current
+message."
+
+  ;; Remake the header to ensure that all information is available.
+  (let* ((to (notmuch-show-get-to))
+(cc (notmuch-show-get-cc))
+(from (notmuch-show-get-from))
+(subject (notmuch-show-get-subject))
+(date (notmuch-show-get-date))
+(tags (notmuch-show-get-tags))
+(depth (notmuch-show-get-depth))
+
+(header (concat
+ "Subject: " subject "\n"
+ "To: " to "\n"
+ (if (not (string= cc ""))
+ (concat "Cc: 

[PATCH] emacs: Avoid regexp overflow when tidying citations.

[David Edmondson]

Declare `notmuch-wash-tidy-citations-max', which is the largest region
that `notmuch-wash-tidy-citations' will attempt to improve.
---
 emacs/notmuch-wash.el |   61 -
 1 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index cfcfb21..a7ea5e9 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -187,6 +187,11 @@ is what to put on the button."

 ;;

+(defcustom notmuch-wash-tidy-citations-max (* 10 1024)
+  "Maximum size of region to tidy."
+  :group 'notmuch
+  :type 'int)
+
 (defun notmuch-wash-tidy-citations (depth)
   "Improve the display of cited regions of a message.

@@ -199,32 +204,36 @@ Perform four transformations on the message body:
 - Remove citation trailers standing alone after a block of cited
   text."

-  ;; Remove lines of repeated citation leaders with no other content.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^>[> ]*\n\\)\\{2,\\}" nil t)
-(replace-match "\\1"))
-
-  ;; Remove citation leaders standing alone before a block of cited
-  ;; text.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(\n\\|^[^>].*\\)\n\\(^>[> ]*\n\\)" nil t)
-(replace-match "\\1\n"))
-
-  ;; Remove citation trailers standing alone after a block of cited
-  ;; text.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^>[> ]*\n\\)\\(^$\\|^[^>].*\\)" nil t)
-(replace-match "\\2"))
-
-  ;; Insert a blank line before a citation if there isn't one.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^[^>]+\\)\n>" nil t)
-(replace-match "\\1\n\n>"))
-
-  ;; Insert a blank line after a citation if there isn't one.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^>.+\\)\n\\([^>]\\)" nil t)
-(replace-match "\\1\n\n\\2")))
+  ;; If the message is long, don't bother.
+  (unless (> (- (point-max) (point-min))
+notmuch-wash-tidy-citations-max)
+
+;; Remove lines of repeated citation leaders with no other content.
+(goto-char (point-min))
+(while (re-search-forward "\\(^>[> ]*\n\\)\\{2,\\}" nil t)
+  (replace-match "\\1"))
+
+;; Remove citation leaders standing alone before a block of cited
+;; text.
+(goto-char (point-min))
+(while (re-search-forward "\\(\n\\|^[^>].*\\)\n\\(^>[> ]*\n\\)" nil t)
+  (replace-match "\\1\n"))
+
+;; Remove citation trailers standing alone after a block of cited
+;; text.
+(goto-char (point-min))
+(while (re-search-forward "\\(^>[> ]*\n\\)\\(^$\\|^[^>].*\\)" nil t)
+  (replace-match "\\2"))
+
+;; Insert a blank line before a citation if there isn't one.
+(goto-char (point-min))
+(while (re-search-forward "\\(^[^>]+\\)\n>" nil t)
+  (replace-match "\\1\n\n>"))
+
+;; Insert a blank line after a citation if there isn't one.
+(goto-char (point-min))
+(while (re-search-forward "\\(^>.+\\)\n\\([^>]\\)" nil t)
+  (replace-match "\\1\n\n\\2"

 ;;

-- 
1.7.2.3

Re: Support for multiple filenames (in notmuch library)

[Jameson Rollins]

On Thu, 11 Nov 2010 05:11:09 -0800, Carl Worth  wrote:
> As part of my recent work to fix up the maildir-flags synchronization
> patches, I found myself needing to access the complete list of filenames
> for a given message. So I added the following, new public function to
> libnotmuch:
> 
>   notmuch_filenames_t *
>   notmuch_message_get_filenames (notmuch_message_t *message);

Hey, Carl.  This is really great.  Thanks so much for getting this
working.

> Others want similar support in the command-line tools, (to show
> duplicate files rather than suppressing them). This would be fairly easy
> to add now. Does anyone have recommendations for suitable command-line
> arguments?
> 
>   notmuch search --with-duplicates
> 
> Or something else??

I think this is definitely the way to go.  It at least makes sense from
my perspective, and then we could add a switch to the emacs ui to return
those messages so that those of us who wanted to could see them in our
search results.

Thanks again for all the great work.

jamie.


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

Re: [PATCH] emacs: remove thread archiving from show-advance function

[Jameson Rollins]

On Fri, 12 Nov 2010 17:12:18 +, David Edmondson  wrote:
> Whether space moves to the next thread should be configurable, I
> think. Similarly whether or not it archives the thread. I'm not worried
> about which is the default behaviour.

Hey, David.  I thought about that, but decided I'd go ahead and submit
this patch to see what kind of reaction it got.  I'm a little surprised
that anyone would actually like the current behavior, but to each their
own!  I'll look into making it a config option when I get the chance.

jamie.


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

[PATCH] emacs: remove thread archiving from show-advance function

[Jameson Rollins]

I believe it's important to have a function to scroll through open
messages in the currently viewed thread, and ' ' is the most logical
keybinding for that.  However, the current function is far too
agressive in automatically archiving the thread and moving to the next thread
when getting to the end of the current thread.  This patch changes this
function to just stop when it gets to the end of the thread, thereby
giving the user a chance to act on the thread how they wish.
---
 emacs/notmuch-show.el |   32 ++--
 1 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index d8773e6..b89b685 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -597,7 +597,7 @@ function is used. "
(define-key map "n" 'notmuch-show-next-open-message)
(define-key map "p" 'notmuch-show-previous-open-message)
(define-key map (kbd "DEL") 'notmuch-show-rewind)
-   (define-key map " " 'notmuch-show-advance-and-archive)
+   (define-key map " " 'notmuch-show-advance)
(define-key map (kbd "M-RET") 'notmuch-show-open-or-close-all)
(define-key map (kbd "RET") 'notmuch-show-toggle-message)
map)
@@ -617,14 +617,12 @@ pressing RET after positioning the cursor on a hidden 
part, (for
 which \\[notmuch-show-next-button] and \\[notmuch-show-previous-button] are 
helpful).

 Reading the thread sequentially is well-supported by pressing
-\\[notmuch-show-advance-and-archive]. This will scroll the current message (if 
necessary), advance
-to the next message, or advance to the next thread (if already on
-the last message of a thread).
+\\[notmuch-show-advance]. This will scroll the current message (if necessary), 
advance
+to the next message.

 Other commands are available to read or manipulate the thread
 more selectively, (such as '\\[notmuch-show-next-message]' and 
'\\[notmuch-show-previous-message]' to advance to messages
-without removing any tags, and '\\[notmuch-show-archive-thread]' to archive an 
entire thread
-without scrolling through with \\[notmuch-show-advance-and-archive]).
+without removing any tags, and '\\[notmuch-show-archive-thread]' to archive an 
entire thread.

 You can add or remove arbitary tags from the current message with
 '\\[notmuch-show-add-tag]' or '\\[notmuch-show-remove-tag]'.
@@ -809,8 +807,8 @@ All currently available key bindings:

 ;; Commands typically bound to keys.

-(defun notmuch-show-advance-and-archive ()
-  "Advance through thread and archive.
+(defun notmuch-show-advance ()
+  "Advance through thread.

 This command is intended to be one of the simplest ways to
 process a thread of email. It does the following:
@@ -819,13 +817,7 @@ If the current message in the thread is not yet fully 
visible,
 scroll by a near screenful to read more of the message.

 Otherwise, (the end of the current message is already within the
-current window), advance to the next open message.
-
-Finally, if there is no further message to advance to, and this
-last message is already read, then archive the entire current
-thread, (remove the \"inbox\" tag from each message). Also kill
-this buffer, and display the next thread from the search from
-which this thread was originally shown."
+current window), advance to the next open message."
   (interactive)
   (let ((end-of-this-message (notmuch-show-message-bottom)))
 (cond
@@ -843,14 +835,10 @@ which this thread was originally shown."

  ((not (= end-of-this-message (point-max)))
   ;; This is not the last message - move to the next visible one.
-  (notmuch-show-next-open-message))
-
- (t
-  ;; This is the last message - archive the thread.
-  (notmuch-show-archive-thread)
+  (notmuch-show-next-open-message)

 (defun notmuch-show-rewind ()
-  "Backup through the thread, (reverse scrolling compared to 
\\[notmuch-show-advance-and-archive]).
+  "Backup through the thread, (reverse scrolling compared to 
\\[notmuch-show-advance]).

 Specifically, if the beginning of the previous email is fewer
 than `window-height' lines from the current point, move to it
@@ -860,7 +848,7 @@ Otherwise, just scroll down a screenful of the current 
message.

 This command does not modify any message tags, (it does not undo
 any effects from previous calls to
-`notmuch-show-advance-and-archive'."
+`notmuch-show-advance'."
   (interactive)
   (let ((start-of-message (notmuch-show-message-top))
(start-of-window (window-start)))
-- 
1.7.2.3

[ann] (incomplete) go bindings to libnotmuch

[Sebastien Binet]

On Thu, 11 Nov 2010 16:50:06 -0800, Carl Worth  wrote:
> On Wed, 10 Nov 2010 18:37:00 +0100, Sebastien Binet  wrote:
> 
> > mainly to familiarize myself with the go language, I wrapped the
> > libnotmuch library and reaped off Sebastian's vala-addressbooklookup
> > program into a go version.
> > 
> > the buggy and incomplete code is there:
> >  http://bitbucket.org/binet/go-notmuch/src
> 
> Cool stuff.
> 
> Having wrappers and code for a library I'm familiar with like this would
> make it much easier for me to sit down and take a good look at go.
> 
> Would be you be interested in maintaining these within the bindings/
> directory of the main notmuch repository? Let me know.
sure, no problem.

cheers,
sebastien.

[PATCH] How to improve the mail handling workflow?

[Jameson Rollins]

On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> The emacs interface to notmuch gets in my way in at least several
> manners:

Hi, Matthieu.  Here are some of the things I've done to deal with
similar issues:

>  - I often find myself hitting the spacebar too much, which ends up with
>some of my new messages being removed from all of their tags, which
>make them very difficult to find. I don't think the spacebar should
>remove the inbox tag at all. It should only change the unread tag.

I agree that the function currently bound to space bar is annoying.  I
am actually in the middle of preparing a patch to fix this.  I think
that space should just scroll through the open messages.  I don't want
it to archive anything, or pop out of the currently viewed thread.  I
think this function is too aggressive as is.

>  - It does not provide a command for deleting mails. We were several
>people who provided patches to add a 'd' keybinding to support
>deletion. I provided a complex patch for that (that added "and not
>tag:deleted" to all requests", but I now think that just adding a
>"deleted" tag and removing the "inbox" tag would be sufficient).

I agree that some built-in support for handling "deleted" tags is called
for, but in the mean time it's very easy to make your own custom
functions to drop into your emacs config.  I have the following:

(define-key notmuch-search-mode-map "d"
  (lambda ()
"delete thread and advance"
(interactive)
(notmuch-search-add-tag "deleted")
(forward-line)))

(define-key notmuch-show-mode-map "d"
  (lambda ()
"delete current message and advance"
(interactive)
(notmuch-show-add-tag "deleted")
(notmuch-show-next-open-message-or-pop)))

(define-key notmuch-search-mode-map "u"
  (lambda ()
"undelete thread"
(interactive)
(notmuch-search-remove-tag "deleted")))

(define-key notmuch-show-mode-map "u"
  (lambda ()
"undelete current message"
(interactive)
(notmuch-show-remove-tag "deleted")))

I do *not* think that adding the "deleted" tag should remove the inbox
tag.  If you want to view your inbox without seeing the deleted
messages, then just use the search "tag:inbox and not tag:deleted".

>  - Processing mails which do not have any automatically added tag is
>boring, because I need to press several keys to archive them: "+" to
>add a tag, and then "a". If I forget about +, then my mail is
>impossible to find.

Again, I achieve archiving with some simple custom functions:

(define-key notmuch-search-mode-map "a"
  (lambda ()
"archive thread and advance"
(interactive)
(notmuch-search-remove-tag "inbox")
(notmuch-search-remove-tag "unread")
(forward-line)))

(define-key notmuch-show-mode-map "a"
  (lambda ()
"archive current message and advance"
(interactive)
(notmuch-show-remove-tag "inbox")
(notmuch-show-next-open-message-or-pop)))

(define-key notmuch-show-mode-map "i"
  (lambda ()
"add current message to inbox"
(interactive)
(notmuch-show-add-tag "inbox")))

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

Re: [PATCH] How to improve the mail handling workflow?

[David Edmondson]

On Fri, 12 Nov 2010 18:48:12 +0100, Matthieu Lemerre  wrote:
> It is just a way to ensure that all your mails are properly filed, and
> file them quickly.

We should just add a hook that you can use, then.

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

Re: [PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

On Fri, 12 Nov 2010 17:05:23 +, David Edmondson  wrote:
> On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> >  - Processing mails which do not have any automatically added tag is
> >boring, because I need to press several keys to archive them: "+" to
> >add a tag, and then "a". If I forget about +, then my mail is
> >impossible to find.
> 
> I don't understand this at all. You can find messages by searching for
> anything about them (sender, subject, body). In what way is it
> 'impossible'?

Impossible was a bit strong. But if for instance I hit space in a
inboxed mail in a thread with one mail, without taking too much time to
study it, then I will know that I forgot to process one mail without
knowing which one it is. I used to find such mails by searching for
mails without any tags, but this was cumbersome. My present patch is a
better attempt to fix this.
 
> Using tags to group things is great, I agree, but coercing me into
> adding tags that I don't really need seems strange.

It is just a way to ensure that all your mails are properly filed, and
file them quickly.

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

notmuch release 0.5 now available

[Nicolás Reynolds]

El 11/11/10 09:02, Carl Worth dijo:
> So, I said I was being foolhardy when I said I wanted to have 0.5 come
> just a week after 0.4. And, indeed, we missed that. But considering this
> release is only 10 days after 0.4, (where it was 6 months(!) after 0.3),
> I think we did pretty well.

http://aur.archlinux.org/packages.php?ID=36289 :)


-- 
Salud!
Nicol?s Reynolds,
xmpp:fauno at kiwwwi.com.ar
omb:http://identi.ca/fauno
blog:http://selfdandi.com.ar/
gnu/linux user #455044

http://librecultivo.org.ar
http://parabolagnulinux.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101112/d8bd231f/attachment.pgp>

Re: [PATCH] emacs: remove thread archiving from show-advance function

[David Edmondson]

On Fri, 12 Nov 2010 10:57:53 -0500, Jameson Rollins 
 wrote:
> I believe it's important to have a function to scroll through open
> messages in the currently viewed thread, and ' ' is the most logical
> keybinding for that.  However, the current function is far too
> agressive in automatically archiving the thread and moving to the next
> thread when getting to the end of the current thread.  This patch
> changes this function to just stop when it gets to the end of the
> thread, thereby giving the user a chance to act on the thread how they
> wish.

Whether space moves to the next thread should be configurable, I
think. Similarly whether or not it archives the thread. I'm not worried
about which is the default behaviour.

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

Re: [PATCH] How to improve the mail handling workflow?

[David Edmondson]

On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
>  - Processing mails which do not have any automatically added tag is
>boring, because I need to press several keys to archive them: "+" to
>add a tag, and then "a". If I forget about +, then my mail is
>impossible to find.

I don't understand this at all. You can find messages by searching for
anything about them (sender, subject, body). In what way is it
'impossible'?

Using tags to group things is great, I agree, but coercing me into
adding tags that I don't really need seems strange.

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

Re: [PATCH] How to improve the mail handling workflow?

[Darren McGuicken]

On Fri, 12 Nov 2010 17:35:22 +0100, Matthieu Lemerre  wrote:
> I prefer to add tags, for the following reasons:

It sounds like we do much the same things with our mail except that your
approach is quite disciplined and mine quite lazy :-)

>  - If I want to search through a mailing list, I don't have to
>  remember its address. Saved searchs solve the problem only partly,
>  because I am not able to make complex queries involving several saved
>  searches. This could be solved only by making notmuch aware of saved
>  searches.

[...]

> By default, hitting the space bar throughout a thread would remove
> every tag from the thread, so you keep asking "where was the mail in
> my inbox that I have read and I can't find anymore?"

As it's so quick, I tend to search my entire archive, even for new
messages, through progressive stages of filtering (which is really all
that a saved search is) starting off knowing only vaguely what it is
that I'm looking for.

For instance 'there was something on the notmuch list about printing
format issues recently' would be 's to:notmuch' 'f print' 'f format' etc
until I see what I'm looking for (or something similar) in the results.
That particular set of steps gives me a buffer with 24 threads in it,
the second of which is what I was looking for.  I tend not to even
bother with subject header based searches unless I know for sure that
what I'm looking for had an unusual subject.

It sounds like a lot of work when I write it out long-form, but it's
incredibly intuitive and so far always gets me what I need.

I can see your approach has its own merits though.


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

Combining threads

[Scott Henson]

Sometimes I get email from people with broken email clients that seem to
break threading.  I remember that sup had a method of combining two threads
into one.  Does notmuch have a similar feature?  Is it even possible to
force it to glue two threads together and treat them as one?

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

Combining threads

[Scott Henson]

Sometimes I get email from people with broken email clients that seem to
break threading.  I remember that sup had a method of combining two threads
into one.  Does notmuch have a similar feature?  Is it even possible to
force it to glue two threads together and treat them as one?

-- 
Scott Henson
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101112/4073e9b3/attachment.htm>

notmuchsync: handling of the deleted tag

[Sebastian Spaeth]

On Thu, 11 Nov 2010 17:27:34 -0800, Carl Worth  wrote:
> So, what we probably need here is for the user to be able to configure
> the mapping and in a fairly sophisticated way:
> 
>   'R' on _any_ filename  -> "replied" tag gets added
>   'T' on _all_ filenames -> "deleted" tag gets added
>   'S' on _any_ filename  -> "unread" tag gets removed
> So maybe something like that?

Maybe, but that sounds like a horribly complex configuration, in which
the user has to really think through what he wants (and can still make
blunders). :)

> > > If notmuch gave me at least all filenames that are associated with a
> > > mail id, I could introduce a command line option "--prune --safe"
> > > which would

Right, you pushed the ball in my court. The only problem is that -- with
the arrival of maildir sync -- I lost my motivation to work on
notmuchsync. Seriously, what does notmuchsync still provide that notmuch
cannot do? I wonder if I shouldn't stick a "deprecated" warning on it.

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

Re: [PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

Hi, Jamie.

> 
> >  - I often find myself hitting the spacebar too much, which ends up with
> >some of my new messages being removed from all of their tags, which
> >make them very difficult to find. I don't think the spacebar should
> >remove the inbox tag at all. It should only change the unread tag.
> 
> I agree that the function currently bound to space bar is annoying.  I
> am actually in the middle of preparing a patch to fix this.  I think
> that space should just scroll through the open messages.  I don't want
> it to archive anything, or pop out of the currently viewed thread.  I
> think this function is too aggressive as is.

Great! Then I'll be waiting for your patch.

> >  - It does not provide a command for deleting mails. We were several
> >people who provided patches to add a 'd' keybinding to support
> >deletion. I provided a complex patch for that (that added "and not
> >tag:deleted" to all requests", but I now think that just adding a
> >"deleted" tag and removing the "inbox" tag would be sufficient).
> 

[...]


> I do *not* think that adding the "deleted" tag should remove the inbox
> tag.  If you want to view your inbox without seeing the deleted
> messages, then just use the search "tag:inbox and not tag:deleted".

Good idea, yes.

> 
> >  - Processing mails which do not have any automatically added tag is
> >boring, because I need to press several keys to archive them: "+" to
> >add a tag, and then "a". If I forget about +, then my mail is
> >impossible to find.
> 
> Again, I achieve archiving with some simple custom functions:
> 

[...]

OK, but this does not solve the problem of forgetting to put a tag when
archiving a thread. Also my patch allows to put a tag without having to
press "+" (so you don't have to think about adding tags when you archive
your mail, you only have to press "a" and be reminded about it).

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

Re: [PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

On Fri, 12 Nov 2010 15:39:37 +, Darren McGuicken 
 wrote:
> On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> > Here is first a patch that copes with this last point. Whenever you
> > want to archive a thread, it finds whether you forgot to add a custom
> > "user" tag to a message, and if so asks you for a tag to add before
> > archiving. That way, I no longer have messages without any tags.
> 
> Hmm, this would be very irritating in my own workflow in which I really
> only use a small number of tags on a fraction of my total mail archive
> to differentiate mail type or content which can't otherwise be
> determined from the indexed plain text of the message (I don't like to
> add a 'notmuch' tag to mail from the list for instance since a saved
> search for mail sent to the list address does exactly the same thing).

I prefer to add tags, for the following reasons:

 - If I want to search through a mailing list, I don't have to remember
   its address. Saved searchs solve the problem only partly, because I
   am not able to make complex queries involving several saved
   searches. This could be solved only by making notmuch aware of saved
   searches.

 - I have some collection of emails that belong to a topic, even if the
   topic does not appear in it. For instance, if I receive mails about a
   project "foo", it can happen that foo is not mentionned in it.

 - I think that adding more informations to mail help find it, even if
   it fills my screen with tag names. Basically, I use tags for several
   different things:
 - to label information 
 - to indicate actions that have to be done (like todo, waiting, done, etc)
 - the other are mail-related tags (inbox, attachment, replied etc).

> I agree that the spacebar does too much if you're just using a search on
> the inbox tag and want something to stay visible even when you've
> quickly spacebar'd through a thread and archived it, but in my case that
> was easily solved by creating a new default saved search called 'todo'
> which collects unread, manually tagged 'todo' and mail matching a number
> of other criteria into one place.  When something has been followed-up
> on, I remove the tag.

But the space bar removes the unread tag, so I do not see how it
helps... By default, hitting the space bar throughout a thread would
remove every tag from the thread, so you keep asking "where was the mail
in my inbox that I have read and I can't find anymore?"
> 
> Colouring threads using notmuch-search-line-faces is also very useful in
> that one-stop 'todo' view.
> 
> Would any of that work for you?  Why are plain text or header searches
> not able to find the mail you're looking for?

Of course, I can change my patch so that its behaviour can be customized
using a variable.

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

[PATCH 2/2] emacs: Use truenames for Fcc paths.

[David Edmondson]

Appease the test suite by using the true name for the Fcc directory
path, otherwise a value for `notmuch-database-path' which includes
symbolic links causes test suite failures.
---
 emacs/notmuch-maildir-fcc.el |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index e5e0549..3f1c124 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -110,11 +110,12 @@ will NOT be removed or replaced."
 (when subdir
   (message-add-header
(concat "Fcc: "
-  ;; If the resulting directory is not an absolute path,
-  ;; prepend the standard notmuch database path.
-  (if (= (elt subdir 0) ?/)
-  subdir
-(concat (notmuch-database-path) "/" subdir
+  (file-truename
+   ;; If the resulting directory is not an absolute path,
+   ;; prepend the standard notmuch database path.
+   (if (= (elt subdir 0) ?/)
+   subdir
+ (concat (notmuch-database-path) "/" subdir)

   ;; finally test if fcc points to a valid maildir
   (let ((fcc-header (message-fetch-field "Fcc")))
-- 
1.7.2.3

[PATCH 1/2] test: Ignore files created during emacs testing.

[David Edmondson]

---
 test/.gitignore |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/test/.gitignore b/test/.gitignore
index b34778f..42a6647 100644
--- a/test/.gitignore
+++ b/test/.gitignore
@@ -1,3 +1,4 @@
 test-results
 corpus.mail
 smtp-dummy
+tmp.emacs
-- 
1.7.2.3

[PATCH] emacs: remove thread archiving from show-advance function

[Jameson Rollins]

I believe it's important to have a function to scroll through open
messages in the currently viewed thread, and ' ' is the most logical
keybinding for that.  However, the current function is far too
agressive in automatically archiving the thread and moving to the next thread
when getting to the end of the current thread.  This patch changes this
function to just stop when it gets to the end of the thread, thereby
giving the user a chance to act on the thread how they wish.
---
 emacs/notmuch-show.el |   32 ++--
 1 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index d8773e6..b89b685 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -597,7 +597,7 @@ function is used. "
(define-key map "n" 'notmuch-show-next-open-message)
(define-key map "p" 'notmuch-show-previous-open-message)
(define-key map (kbd "DEL") 'notmuch-show-rewind)
-   (define-key map " " 'notmuch-show-advance-and-archive)
+   (define-key map " " 'notmuch-show-advance)
(define-key map (kbd "M-RET") 'notmuch-show-open-or-close-all)
(define-key map (kbd "RET") 'notmuch-show-toggle-message)
map)
@@ -617,14 +617,12 @@ pressing RET after positioning the cursor on a hidden 
part, (for
 which \\[notmuch-show-next-button] and \\[notmuch-show-previous-button] are 
helpful).
 
 Reading the thread sequentially is well-supported by pressing
-\\[notmuch-show-advance-and-archive]. This will scroll the current message (if 
necessary), advance
-to the next message, or advance to the next thread (if already on
-the last message of a thread).
+\\[notmuch-show-advance]. This will scroll the current message (if necessary), 
advance
+to the next message.
 
 Other commands are available to read or manipulate the thread
 more selectively, (such as '\\[notmuch-show-next-message]' and 
'\\[notmuch-show-previous-message]' to advance to messages
-without removing any tags, and '\\[notmuch-show-archive-thread]' to archive an 
entire thread
-without scrolling through with \\[notmuch-show-advance-and-archive]).
+without removing any tags, and '\\[notmuch-show-archive-thread]' to archive an 
entire thread.
 
 You can add or remove arbitary tags from the current message with
 '\\[notmuch-show-add-tag]' or '\\[notmuch-show-remove-tag]'.
@@ -809,8 +807,8 @@ All currently available key bindings:
 
 ;; Commands typically bound to keys.
 
-(defun notmuch-show-advance-and-archive ()
-  "Advance through thread and archive.
+(defun notmuch-show-advance ()
+  "Advance through thread.
 
 This command is intended to be one of the simplest ways to
 process a thread of email. It does the following:
@@ -819,13 +817,7 @@ If the current message in the thread is not yet fully 
visible,
 scroll by a near screenful to read more of the message.
 
 Otherwise, (the end of the current message is already within the
-current window), advance to the next open message.
-
-Finally, if there is no further message to advance to, and this
-last message is already read, then archive the entire current
-thread, (remove the \"inbox\" tag from each message). Also kill
-this buffer, and display the next thread from the search from
-which this thread was originally shown."
+current window), advance to the next open message."
   (interactive)
   (let ((end-of-this-message (notmuch-show-message-bottom)))
 (cond
@@ -843,14 +835,10 @@ which this thread was originally shown."
 
  ((not (= end-of-this-message (point-max)))
   ;; This is not the last message - move to the next visible one.
-  (notmuch-show-next-open-message))
-
- (t
-  ;; This is the last message - archive the thread.
-  (notmuch-show-archive-thread)
+  (notmuch-show-next-open-message)
 
 (defun notmuch-show-rewind ()
-  "Backup through the thread, (reverse scrolling compared to 
\\[notmuch-show-advance-and-archive]).
+  "Backup through the thread, (reverse scrolling compared to 
\\[notmuch-show-advance]).
 
 Specifically, if the beginning of the previous email is fewer
 than `window-height' lines from the current point, move to it
@@ -860,7 +848,7 @@ Otherwise, just scroll down a screenful of the current 
message.
 
 This command does not modify any message tags, (it does not undo
 any effects from previous calls to
-`notmuch-show-advance-and-archive'."
+`notmuch-show-advance'."
   (interactive)
   (let ((start-of-message (notmuch-show-message-top))
(start-of-window (window-start)))
-- 
1.7.2.3

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

[PATCH] emacs: Show cleaner addresses during message display.

[David Edmondson]

Simplify the display of addresses by setting
`notmuch-show-address-simplication' to:

- 'full: Only the name component of the address, if present, is
  shown,
- 'partial: Addresses are stripped of redundant information (the
  default),
- 'none: Addresses are shown as-is.

`mail-header-parse-address' fails for some addresses, in particular
"undisclosed-recipients:;". Accommodate this by returning the original
address if the parser fails.

Adjust the test results accordingly.
---

Default is now 'partial (most similar to the old behaviour). Allow for
un-parseable addresses. Don't add unnecessary quotes. Oh, and, fix the
test suite.

Carl: You can ignore the notmuch-lkml.el chunk, as you don't have that
yet.

 emacs/notmuch-lkml.el  |4 +-
 emacs/notmuch-show.el  |   65 +++-
 .../notmuch-show-thread-maildir-storage|6 +-
 3 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/emacs/notmuch-lkml.el b/emacs/notmuch-lkml.el
index 750370b..fc04be6 100644
--- a/emacs/notmuch-lkml.el
+++ b/emacs/notmuch-lkml.el
@@ -29,7 +29,7 @@
 (declare-function notmuch-call-notmuch-process "notmuch" (&rest args))
 (declare-function notmuch-show "notmuch-show" (&rest args))
 (declare-function notmuch-show-strip-re "notmuch-show" (subject))
-(declare-function notmuch-show-clean-address "notmuch-show" (parsed-address))
+(declare-function notmuch-show-clean-address "notmuch-show" (address))
 (declare-function notmuch-show-spaces-n "notmuch-show" (n))

 (defcustom notmuch-lkml-author-width 30
@@ -71,7 +71,7 @@
 (notmuch-lkml-string-width 
  (concat (notmuch-show-spaces-n depth)
  (notmuch-show-clean-address
-  (mail-header-parse-address (plist-get headers :From
+  (plist-get headers :From)))
  notmuch-lkml-author-width)
 " "
 (if (string= notmuch-lkml-previous-subject
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index d8773e6..aa89cfd 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -26,6 +26,7 @@
 (require 'message)
 (require 'mm-decode)
 (require 'mailcap)
+(require 'mail-parse)

 (require 'notmuch-lib)
 (require 'notmuch-query)
@@ -82,6 +83,21 @@ any given message."
 notmuch-wash-elide-blank-lines
 notmuch-wash-excerpt-citations))

+(defcustom notmuch-show-address-simplification 'partial
+  "How should addresses be displayed?
+
+Set `notmuch-show-address-simplication' to:
+
+- 'full: Only the name component of the address, if present, is
+  shown,
+- 'partial: Addresses are stripped of redundant information,
+- 'none: Addresses are shown as-is."
+  :group 'notmuch
+  :type '(choice
+ (const :tag "Full simplification" full)
+ (const :tag "Partial simplification" partial)
+ (const :tag "No simplification" none)))
+
 (defmacro with-current-notmuch-show-message (&rest body)
   "Evaluate body with current buffer set to the text of current message"
   `(save-excursion
@@ -198,12 +214,46 @@ any given message."
 'face 'notmuch-tag-face)
 ")"))

+(defun notmuch-show-clean-address (original-address)
+  "Prepare a single email address for display."
+  (let* ((parsed-address (mail-header-parse-address original-address))
+(address (car parsed-address))
+(name (cdr parsed-address))
+(displayed-name name))
+
+;; If the parser failed, use the original string.
+(if (not parsed-address)
+   original-address
+
+  ;; If the address is 'foo at bar.com ' then show just
+  ;; 'foo at bar.com'.
+  (when (string= displayed-name address)
+   (setq displayed-name nil))
+
+  (cond
+   ((eq notmuch-show-address-simplification 'full)
+   (if displayed-name
+   (propertize displayed-name 'help-echo address)
+ address))
+
+   ((eq notmuch-show-address-simplification 'partial)
+   (if displayed-name
+   ;; `mail-header-make-address' is enthusiastic about
+   ;; quoting the displayed name if it contains spaces (which
+   ;; is visually unappealing) so generate the displayed
+   ;; string directly here.
+   (concat displayed-name " <" address ">")
+ address))
+
+   (t ;; All other settings, but mostly 'none.
+   original-address)
+
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
 (insert (notmuch-show-spaces-n depth)
-   (plist-get headers :From)
+   (notmuch-show-clean-address (plist-get headers :From))
" ("
date
") ("
@@ -214,7 +264,18 @@ message at DEPTH in the current thread."

 (defun notmuch-show-insert-header (header header-value)
   "Inser

Re: [PATCH] How to improve the mail handling workflow?

[Darren McGuicken]

On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> Here is first a patch that copes with this last point. Whenever you
> want to archive a thread, it finds whether you forgot to add a custom
> "user" tag to a message, and if so asks you for a tag to add before
> archiving. That way, I no longer have messages without any tags.

Hmm, this would be very irritating in my own workflow in which I really
only use a small number of tags on a fraction of my total mail archive
to differentiate mail type or content which can't otherwise be
determined from the indexed plain text of the message (I don't like to
add a 'notmuch' tag to mail from the list for instance since a saved
search for mail sent to the list address does exactly the same thing).

I agree that the spacebar does too much if you're just using a search on
the inbox tag and want something to stay visible even when you've
quickly spacebar'd through a thread and archived it, but in my case that
was easily solved by creating a new default saved search called 'todo'
which collects unread, manually tagged 'todo' and mail matching a number
of other criteria into one place.  When something has been followed-up
on, I remove the tag.

Colouring threads using notmuch-search-line-faces is also very useful in
that one-stop 'todo' view.

Would any of that work for you?  Why are plain text or header searches
not able to find the mail you're looking for?


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

Re: [PATCH] How to improve the mail handling workflow?

[Jameson Rollins]

On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> The emacs interface to notmuch gets in my way in at least several
> manners:

Hi, Matthieu.  Here are some of the things I've done to deal with
similar issues:

>  - I often find myself hitting the spacebar too much, which ends up with
>some of my new messages being removed from all of their tags, which
>make them very difficult to find. I don't think the spacebar should
>remove the inbox tag at all. It should only change the unread tag.

I agree that the function currently bound to space bar is annoying.  I
am actually in the middle of preparing a patch to fix this.  I think
that space should just scroll through the open messages.  I don't want
it to archive anything, or pop out of the currently viewed thread.  I
think this function is too aggressive as is.

>  - It does not provide a command for deleting mails. We were several
>people who provided patches to add a 'd' keybinding to support
>deletion. I provided a complex patch for that (that added "and not
>tag:deleted" to all requests", but I now think that just adding a
>"deleted" tag and removing the "inbox" tag would be sufficient).

I agree that some built-in support for handling "deleted" tags is called
for, but in the mean time it's very easy to make your own custom
functions to drop into your emacs config.  I have the following:

(define-key notmuch-search-mode-map "d"
  (lambda ()
"delete thread and advance"
(interactive)
(notmuch-search-add-tag "deleted")
(forward-line)))

(define-key notmuch-show-mode-map "d"
  (lambda ()
"delete current message and advance"
(interactive)
(notmuch-show-add-tag "deleted")
(notmuch-show-next-open-message-or-pop)))

(define-key notmuch-search-mode-map "u"
  (lambda ()
"undelete thread"
(interactive)
(notmuch-search-remove-tag "deleted")))

(define-key notmuch-show-mode-map "u"
  (lambda ()
"undelete current message"
(interactive)
(notmuch-show-remove-tag "deleted")))

I do *not* think that adding the "deleted" tag should remove the inbox
tag.  If you want to view your inbox without seeing the deleted
messages, then just use the search "tag:inbox and not tag:deleted".

>  - Processing mails which do not have any automatically added tag is
>boring, because I need to press several keys to archive them: "+" to
>add a tag, and then "a". If I forget about +, then my mail is
>impossible to find.

Again, I achieve archiving with some simple custom functions:

(define-key notmuch-search-mode-map "a"
  (lambda ()
"archive thread and advance"
(interactive)
(notmuch-search-remove-tag "inbox")
(notmuch-search-remove-tag "unread")
(forward-line)))

(define-key notmuch-show-mode-map "a"
  (lambda ()
"archive current message and advance"
(interactive)
(notmuch-show-remove-tag "inbox")
(notmuch-show-next-open-message-or-pop)))

(define-key notmuch-show-mode-map "i"
  (lambda ()
"add current message to inbox"
(interactive)
(notmuch-show-add-tag "inbox")))

jamie.


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

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

Hi,

I think that there are several irritating nitpicks when using notmuch in
a typical mail workflow.

I don't know how other people process their email. I for myself use the
following method:

1. The script I use to fetch new mails tries to add tags if it can. For
   instance, all new mails from the notmuch mailing lists appears with
   tags "(inbox,unread,notmuch)".

2. When processing mails, I manually add some tag to the mails for which
   no tags were added automatically. Then I archive the mail (remove its
   inbox tag).

3. Sometimes I keep mails in my inbox, for instance if I am expecting a
   specific mail and do not want to take the time to process the others.

The emacs interface to notmuch gets in my way in at least several
manners:

 - I often find myself hitting the spacebar too much, which ends up with
   some of my new messages being removed from all of their tags, which
   make them very difficult to find. I don't think the spacebar should
   remove the inbox tag at all. It should only change the unread tag.

 - It does not provide a command for deleting mails. We were several
   people who provided patches to add a 'd' keybinding to support
   deletion. I provided a complex patch for that (that added "and not
   tag:deleted" to all requests", but I now think that just adding a
   "deleted" tag and removing the "inbox" tag would be sufficient).

 - Processing mails which do not have any automatically added tag is
   boring, because I need to press several keys to archive them: "+" to
   add a tag, and then "a". If I forget about +, then my mail is
   impossible to find.

Here is first a patch that copes with this last point. Whenever you want
to archive a thread, it finds whether you forgot to add a custom "user"
tag to a message, and if so asks you for a tag to add before
archiving. That way, I no longer have messages without any tags.

I probably will send patches to handle the other bullet points to, but
first I would be happy to hear your comments about this, or learn about
how you process your mail using the current interface.

Thanks,
Matthieu Lemerre

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index d8773e6..57ff72e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1054,11 +1054,35 @@ argument, hide all of the messages."
   (interactive)
   (backward-button 1))
 
+(defun notmuch-is-user-tag (tag)
+  ;; Returns true if tag is not one of 
+  ;; inbox, deleted, replied, draft, 
+  (not (member tag '("inbox" "replied" "draft" "deleted" 
+		"attachment" "unread"
+
 (defun notmuch-show-archive-thread-internal (show-next)
   ;; Remove the tag from the current set of messages.
   (goto-char (point-min))
-  (loop do (notmuch-show-remove-tag "inbox")
-	until (not (notmuch-show-goto-message-next)))
+  (let ((has-empty-tags))
+;; 1st pass: try to see if adding a tag is necessary.
+(loop do (let ((user-tags (remove-if-not #'notmuch-is-user-tag 
+	 (notmuch-show-get-tags
+	   (setq has-empty-tags 
+		 (or has-empty-tags (eq user-tags nil
+	  until (not (notmuch-show-goto-message-next)))
+;; Only ask for a tag to add if has-empty-tags is non-nil. Use
+;; tags-to-apply to propose a default value.
+(let ((tags-to-add '()))
+  (if has-empty-tags
+	  (setq tags-to-add (list (notmuch-select-tag-with-completion 
+   "Some messages in the thread have no user tags. Add: "
+  ;; 2nd pass: tag all the messages with the user-selected tag,
+  ;; and remove the "inbox" tag
+  (goto-char (point-min))
+  (loop do (progn 
+		 (apply #'notmuch-show-add-tag tags-to-add)
+		 (notmuch-show-remove-tag "inbox"))
+	  until (not (notmuch-show-goto-message-next)
   ;; Move to the next item in the search results, if any.
   (let ((parent-buffer notmuch-show-parent-buffer))
 (notmuch-kill-this-buffer)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 5933747..eeff18c 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -560,7 +560,9 @@ thread or threads in the current region."
 
 This function advances the next thread when finished."
   (interactive)
-  (notmuch-search-remove-tag-thread "inbox")
+  (save-excursion
+(notmuch-search-show-thread)
+(notmuch-show-archive-thread-internal nil))
   (forward-line))
 
 (defun notmuch-search-process-sentinel (proc msg)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: Improved printing support.

[David Edmondson]

---

More usable (I'm trying 'muttprint then evince').

 emacs/Makefile.local   |3 +-
 emacs/notmuch-print.el |   75 
 emacs/notmuch-show.el  |   51 
 3 files changed, 128 insertions(+), 1 deletions(-)
 create mode 100644 emacs/notmuch-print.el

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index c5280f1..df87427 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -13,7 +13,8 @@ emacs_sources := \
$(dir)/notmuch-maildir-fcc.el \
$(dir)/notmuch-message.el \
$(dir)/coolj.el \
-   $(dir)/notmuch-lkml.el
+   $(dir)/notmuch-lkml.el \
+   $(dir)/notmuch-print.el
 
 emacs_images := \
$(dir)/notmuch-logo.png
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
new file mode 100644
index 000..62e380c
--- /dev/null
+++ b/emacs/notmuch-print.el
@@ -0,0 +1,75 @@
+;; notmuch-print.el --- printing messages from notmuch.
+;;
+;; Copyright © David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see .
+;;
+;; Authors: David Edmondson 
+
+(defcustom notmuch-print-mechanism 'notmuch-print-lpr
+  "How should printing be done?"
+  :group 'notmuch
+  :type '(choice
+ (function :tag "Use lpr" notmuch-print-lpr)
+ (function :tag "Use ps-print" notmuch-print-ps-print)
+ (function :tag "Use ps-print then evince" 
notmuch-print-ps-print/evince)
+ (function :tag "Use muttprint" notmuch-print-muttprint)
+ (function :tag "Use muttprint then evince" 
notmuch-print-muttprint/evince)
+ (function :tag "Using a custom function")))
+
+(defmacro notmuch-print-with-file (filename &rest body)
+  `(with-temp-buffer
+ (insert-file-contents ,filename)
+ (setq buffer-modified-p nil)
+ ,@body))
+
+(defun notmuch-print-lpr (filename)
+  (notmuch-print-with-file filename
+  (lpr-buffer)))
+
+(defun notmuch-print-ps-print (filename)
+  (notmuch-print-with-file filename
+  (ps-print-buffer)))
+
+(defun notmuch-print-ps-print/evince (filename)
+  (let ((ps-file (make-temp-file "notmuch")))
+(notmuch-print-with-file filename
+(ps-print-buffer ps-file)
+(async-shell-command (concat "evince " ps-file)
+
+(defun notmuch-print-muttprint (filename)
+  (shell-command
+   (concat "muttprint "
+  "--file " (shell-quote-argument filename) " "
+  ;; Show the tags.
+  "--printed-headers Date_To_From_CC_Newsgroups_*Subject*_/Tags/ ")))
+
+(defun notmuch-print-muttprint/evince (filename)
+  (let ((ps-file (make-temp-file "notmuch")))
+(call-process-shell-command
+ (concat "muttprint "
+"--file " (shell-quote-argument filename) " "
+;; Show the tags.
+"--printed-headers Date_To_From_CC_Newsgroups_*Subject*_/Tags/ "
+"--printer \"TO_FILE:" (shell-quote-argument ps-file) "\""))
+(async-shell-command (concat "evince " ps-file
+
+(defun notmuch-print-message (filename)
+  (funcall notmuch-print-mechanism filename))
+
+;;
+
+(provide 'notmuch-print)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index aa89cfd..002c2fd 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -32,6 +32,7 @@
 (require 'notmuch-query)
 (require 'notmuch-wash)
 (require 'notmuch-mua)
+(require 'notmuch-print)
 
 (declare-function notmuch-call-notmuch-process "notmuch" (&rest args))
 (declare-function notmuch-fontify-headers "notmuch" nil)
@@ -174,6 +175,51 @@ Set `notmuch-show-address-simplication' to:
   mm-handle (> (notmuch-count-attachments mm-handle) 1
   (message "Done"))
 
+(defun notmuch-show-with-message-as-text (fn)
+  "Apply function `fn' to a text representation of the current
+message."
+
+  ;; Remake the header to ensure that all information is available.
+  (let* ((to (notmuch-show-get-to))
+(cc (notmuch-show-get-cc))
+(from (notmuch-show-get-from))
+(subject (notmuch-show-get-subject))
+(date (notmuch-show-get-date))
+(tags (notmuch-show-get-tags))
+(depth (notmuch-show-get-depth))
+
+(header (concat
+ "Subject: " subject "\n"
+ "To: " to "\n"
+ (if (not (string= cc ""))
+ (concat "Cc: 

[PATCH] emacs: Avoid regexp overflow when tidying citations.

[David Edmondson]

Declare `notmuch-wash-tidy-citations-max', which is the largest region
that `notmuch-wash-tidy-citations' will attempt to improve.
---
 emacs/notmuch-wash.el |   61 -
 1 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index cfcfb21..a7ea5e9 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -187,6 +187,11 @@ is what to put on the button."
 
 ;;
 
+(defcustom notmuch-wash-tidy-citations-max (* 10 1024)
+  "Maximum size of region to tidy."
+  :group 'notmuch
+  :type 'int)
+
 (defun notmuch-wash-tidy-citations (depth)
   "Improve the display of cited regions of a message.
 
@@ -199,32 +204,36 @@ Perform four transformations on the message body:
 - Remove citation trailers standing alone after a block of cited
   text."
 
-  ;; Remove lines of repeated citation leaders with no other content.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^>[> ]*\n\\)\\{2,\\}" nil t)
-(replace-match "\\1"))
-
-  ;; Remove citation leaders standing alone before a block of cited
-  ;; text.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(\n\\|^[^>].*\\)\n\\(^>[> ]*\n\\)" nil t)
-(replace-match "\\1\n"))
-
-  ;; Remove citation trailers standing alone after a block of cited
-  ;; text.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^>[> ]*\n\\)\\(^$\\|^[^>].*\\)" nil t)
-(replace-match "\\2"))
-
-  ;; Insert a blank line before a citation if there isn't one.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^[^>]+\\)\n>" nil t)
-(replace-match "\\1\n\n>"))
-
-  ;; Insert a blank line after a citation if there isn't one.
-  (goto-char (point-min))
-  (while (re-search-forward "\\(^>.+\\)\n\\([^>]\\)" nil t)
-(replace-match "\\1\n\n\\2")))
+  ;; If the message is long, don't bother.
+  (unless (> (- (point-max) (point-min))
+notmuch-wash-tidy-citations-max)
+
+;; Remove lines of repeated citation leaders with no other content.
+(goto-char (point-min))
+(while (re-search-forward "\\(^>[> ]*\n\\)\\{2,\\}" nil t)
+  (replace-match "\\1"))
+
+;; Remove citation leaders standing alone before a block of cited
+;; text.
+(goto-char (point-min))
+(while (re-search-forward "\\(\n\\|^[^>].*\\)\n\\(^>[> ]*\n\\)" nil t)
+  (replace-match "\\1\n"))
+
+;; Remove citation trailers standing alone after a block of cited
+;; text.
+(goto-char (point-min))
+(while (re-search-forward "\\(^>[> ]*\n\\)\\(^$\\|^[^>].*\\)" nil t)
+  (replace-match "\\2"))
+
+;; Insert a blank line before a citation if there isn't one.
+(goto-char (point-min))
+(while (re-search-forward "\\(^[^>]+\\)\n>" nil t)
+  (replace-match "\\1\n\n>"))
+
+;; Insert a blank line after a citation if there isn't one.
+(goto-char (point-min))
+(while (re-search-forward "\\(^>.+\\)\n\\([^>]\\)" nil t)
+  (replace-match "\\1\n\n\\2"
 
 ;;
 
-- 
1.7.2.3

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

Re: notmuch release 0.5 now available

[Nicolás Reynolds]

El 11/11/10 09:02, Carl Worth dijo:
> So, I said I was being foolhardy when I said I wanted to have 0.5 come
> just a week after 0.4. And, indeed, we missed that. But considering this
> release is only 10 days after 0.4, (where it was 6 months(!) after 0.3),
> I think we did pretty well.

http://aur.archlinux.org/packages.php?ID=36289 :)


-- 
Salud!
Nicolás Reynolds,
xmpp:fa...@kiwwwi.com.ar
omb:http://identi.ca/fauno
blog:http://selfdandi.com.ar/
gnu/linux user #455044

http://librecultivo.org.ar
http://parabolagnulinux.org


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

Re: [ann] (incomplete) go bindings to libnotmuch

[Sebastien Binet]

On Thu, 11 Nov 2010 16:50:06 -0800, Carl Worth  wrote:
> On Wed, 10 Nov 2010 18:37:00 +0100, Sebastien Binet  wrote:
> 
> > mainly to familiarize myself with the go language, I wrapped the
> > libnotmuch library and reaped off Sebastian's vala-addressbooklookup
> > program into a go version.
> > 
> > the buggy and incomplete code is there:
> >  http://bitbucket.org/binet/go-notmuch/src
> 
> Cool stuff.
> 
> Having wrappers and code for a library I'm familiar with like this would
> make it much easier for me to sit down and take a good look at go.
> 
> Would be you be interested in maintaining these within the bindings/
> directory of the main notmuch repository? Let me know.
sure, no problem.

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

[PATCH 2/2] emacs: Use truenames for Fcc paths.

[David Edmondson]

Appease the test suite by using the true name for the Fcc directory
path, otherwise a value for `notmuch-database-path' which includes
symbolic links causes test suite failures.
---
 emacs/notmuch-maildir-fcc.el |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index e5e0549..3f1c124 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -110,11 +110,12 @@ will NOT be removed or replaced."
 (when subdir
   (message-add-header
(concat "Fcc: "
-  ;; If the resulting directory is not an absolute path,
-  ;; prepend the standard notmuch database path.
-  (if (= (elt subdir 0) ?/)
-  subdir
-(concat (notmuch-database-path) "/" subdir
+  (file-truename
+   ;; If the resulting directory is not an absolute path,
+   ;; prepend the standard notmuch database path.
+   (if (= (elt subdir 0) ?/)
+   subdir
+ (concat (notmuch-database-path) "/" subdir)
   
   ;; finally test if fcc points to a valid maildir
   (let ((fcc-header (message-fetch-field "Fcc")))
-- 
1.7.2.3

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

[PATCH 1/2] test: Ignore files created during emacs testing.

[David Edmondson]

---
 test/.gitignore |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/test/.gitignore b/test/.gitignore
index b34778f..42a6647 100644
--- a/test/.gitignore
+++ b/test/.gitignore
@@ -1,3 +1,4 @@
 test-results
 corpus.mail
 smtp-dummy
+tmp.emacs
-- 
1.7.2.3

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

[PATCH] emacs: Show cleaner addresses during message display.

[David Edmondson]

Simplify the display of addresses by setting
`notmuch-show-address-simplication' to:

- 'full: Only the name component of the address, if present, is
  shown,
- 'partial: Addresses are stripped of redundant information (the
  default),
- 'none: Addresses are shown as-is.

`mail-header-parse-address' fails for some addresses, in particular
"undisclosed-recipients:;". Accommodate this by returning the original
address if the parser fails.

Adjust the test results accordingly.
---

Default is now 'partial (most similar to the old behaviour). Allow for
un-parseable addresses. Don't add unnecessary quotes. Oh, and, fix the
test suite.

Carl: You can ignore the notmuch-lkml.el chunk, as you don't have that
yet.

 emacs/notmuch-lkml.el  |4 +-
 emacs/notmuch-show.el  |   65 +++-
 .../notmuch-show-thread-maildir-storage|6 +-
 3 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/emacs/notmuch-lkml.el b/emacs/notmuch-lkml.el
index 750370b..fc04be6 100644
--- a/emacs/notmuch-lkml.el
+++ b/emacs/notmuch-lkml.el
@@ -29,7 +29,7 @@
 (declare-function notmuch-call-notmuch-process "notmuch" (&rest args))
 (declare-function notmuch-show "notmuch-show" (&rest args))
 (declare-function notmuch-show-strip-re "notmuch-show" (subject))
-(declare-function notmuch-show-clean-address "notmuch-show" (parsed-address))
+(declare-function notmuch-show-clean-address "notmuch-show" (address))
 (declare-function notmuch-show-spaces-n "notmuch-show" (n))
 
 (defcustom notmuch-lkml-author-width 30
@@ -71,7 +71,7 @@
 (notmuch-lkml-string-width 
  (concat (notmuch-show-spaces-n depth)
  (notmuch-show-clean-address
-  (mail-header-parse-address (plist-get headers :From
+  (plist-get headers :From)))
  notmuch-lkml-author-width)
 " "
 (if (string= notmuch-lkml-previous-subject
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index d8773e6..aa89cfd 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -26,6 +26,7 @@
 (require 'message)
 (require 'mm-decode)
 (require 'mailcap)
+(require 'mail-parse)
 
 (require 'notmuch-lib)
 (require 'notmuch-query)
@@ -82,6 +83,21 @@ any given message."
 notmuch-wash-elide-blank-lines
 notmuch-wash-excerpt-citations))
 
+(defcustom notmuch-show-address-simplification 'partial
+  "How should addresses be displayed?
+
+Set `notmuch-show-address-simplication' to:
+
+- 'full: Only the name component of the address, if present, is
+  shown,
+- 'partial: Addresses are stripped of redundant information,
+- 'none: Addresses are shown as-is."
+  :group 'notmuch
+  :type '(choice
+ (const :tag "Full simplification" full)
+ (const :tag "Partial simplification" partial)
+ (const :tag "No simplification" none)))
+
 (defmacro with-current-notmuch-show-message (&rest body)
   "Evaluate body with current buffer set to the text of current message"
   `(save-excursion
@@ -198,12 +214,46 @@ any given message."
 'face 'notmuch-tag-face)
 ")"))
 
+(defun notmuch-show-clean-address (original-address)
+  "Prepare a single email address for display."
+  (let* ((parsed-address (mail-header-parse-address original-address))
+(address (car parsed-address))
+(name (cdr parsed-address))
+(displayed-name name))
+
+;; If the parser failed, use the original string.
+(if (not parsed-address)
+   original-address
+
+  ;; If the address is 'f...@bar.com ' then show just
+  ;; 'f...@bar.com'.
+  (when (string= displayed-name address)
+   (setq displayed-name nil))
+
+  (cond
+   ((eq notmuch-show-address-simplification 'full)
+   (if displayed-name
+   (propertize displayed-name 'help-echo address)
+ address))
+
+   ((eq notmuch-show-address-simplification 'partial)
+   (if displayed-name
+   ;; `mail-header-make-address' is enthusiastic about
+   ;; quoting the displayed name if it contains spaces (which
+   ;; is visually unappealing) so generate the displayed
+   ;; string directly here.
+   (concat displayed-name " <" address ">")
+ address))
+
+   (t ;; All other settings, but mostly 'none.
+   original-address)
+
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
 (insert (notmuch-show-spaces-n depth)
-   (plist-get headers :From)
+   (notmuch-show-clean-address (plist-get headers :From))
" ("
date
") ("
@@ -214,7 +264,18 @@ message at DEPTH in the current thread."
 
 (defun notmuch-show-insert-header (header header-value)
   "Inse