Re: RFC/PATCH emacs attachment handling

[Matthieu Lemerre]

 Finally, I have also mapped the key o (other/open with) on a button to
 open with user chosen program. This could be split out into a separate
 patch if preferred.

This is great! In particular many people send PDF attachments to me with
mime-type attachment/octet-stream, and notmuch could not view them and
only offered to save them... I have wanted this functionality for long!

Matthieu

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

RFC/PATCH emacs attachment handling

[Matthieu Lemerre]

> Finally, I have also mapped the key "o" (other/open with) on a button to
> open with user chosen program. This could be split out into a separate
> patch if preferred.

This is great! In particular many people send PDF attachments to me with
mime-type attachment/octet-stream, and notmuch could not view them and
only offered to save them... I have wanted this functionality for long!

Matthieu

Re: notmuch.el: bind 'd' to new function notmuch-search-delete-thread-or-region

[Matthieu Lemerre]

On Fri, 15 Jul 2011 00:11:29 -0400, anarcat anar...@koumbit.org wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
 I can confirm this patch works for me.
 
 I think this would be a great addition to notmuch, and I could add it
 directly to Debian's 0.6 package install.
 

I also strongly in favor for the addition of this patch, having a
similar one in my own branch.

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

Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Matthieu Lemerre]

On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements  wrote:
> Had I replaced it, though, there are two variations I would have
> tried.? Have you guys considered these and, if so, any thoughts?
> 
> * Make SPC mark the *current* message read and move to the next one,
> rather than moving to the next and marking it read.? This way, you're
> acknowledging the message as read once you've actually read it, rather
> than having notmuch mark it read before you've actually read it.

I agree. I think it's up to the user to define whether he read the
message. In fact as a consequence, I have no use of the 'unread' tag.

> * At the end of the thread, return to the index view.? This way, if
> you want to archive the thread, you can still just press 'a', but if
> you don't, you're already set to navigate to another thread.

I would prefer just to do nothing (or bell) at the end of the
thread. Sometimes the end of a message is just at the end of the screen,
and I want to hit space to see the next message, so I think that
returning to the index would surprise me (as going to the next thread
does).

But this could be a third option if some people prefer that. So we would
have:
- do nothing
- archive go to the next thread
- return to the index

Matthieu

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Matthieu Lemerre]

On Mon, 04 Jul 2011 17:03:51 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
Non-text part: multipart/signed
 On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre ra...@free.fr wrote:
  I like to use the space (and sometimes the backspace key) to read
  threads back and forth, but sometimes I might read stuff to quickly and
  archive a thread without wanting it. It is then complex to find it back
  (especially if the thread contained a single message and I hit space
  before actually reading the message, so I can't find it again).
  
  As a workaround, I have changed the space key function
  notmuch-show-advance-and-archive to not archive the thread if we are
  at the end of the thread, but to just do nothing. Thus I have to
  expicitely archive the thread when I have finished reading it, which I
  find much safer.
 
 I completely agree with your discomfort with the current function bound
 to space.  I don't like it at all, and I similarly rebound space to be a
 much more sensible function:

[...]

 Notice I also made it so that this does not exit the current thread
 view.

I patched notmuch to use exactly the same function... Given that we are
two people who independently requested for this behaviour, I think this
should at least be a customisable option, and imo the default should do
nothing and not archive the thread because of this dangerous
behaviour. And, hitting 'a' instead of space to go to the next thread is
the same number of keypresses...

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

Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Matthieu Lemerre]

On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green gree...@greenrd.org wrote:
 It's really dangerous to use the 'a' key in notmuch-mode in an inbox
 thread which has multiple unread replies! Yes, the other unread replies
 will still be tagged unread, but the user might not immediately be aware
 of them. It would be really useful to have an optional warning (More
 unread messages in this thread, are you sure?) for this situation!

I take advantage of this thread to tell about another dangerous
situation I've found related to the use of the space key in show mode.

I like to use the space (and sometimes the backspace key) to read
threads back and forth, but sometimes I might read stuff to quickly and
archive a thread without wanting it. It is then complex to find it back
(especially if the thread contained a single message and I hit space
before actually reading the message, so I can't find it again).

As a workaround, I have changed the space key function
notmuch-show-advance-and-archive to not archive the thread if we are
at the end of the thread, but to just do nothing. Thus I have to
expicitely archive the thread when I have finished reading it, which I
find much safer.

I think the and-archive part of the space bar key should be at least
configurable. The patch is pretty simple but I can provide it if needed.

Note: The n and p keys are not good replacement for space/backspace.
First, because they do not remove the 'read' tag. Second, when you are
in the middle of a message, the p key go to the previous message instead
of going on top of the current one. (Actually, the behaviour of n is
fine, only p is annoying me). I think this is inconsistent with what
others mode do (e.g. C-M-u in programming modes, or C-c C-p in
org-mode), and the p key when in a message should go to the beginning of
the current message.

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

Warning when GMime is parsing broken email addresses

[Matthieu Lemerre]

On Wed, 27 Apr 2011 21:59:09 +0200, Pieter Praet  wrote:
> On Wed, 27 Apr 2011 18:30:09 +0200, Xavier Maillard  
> wrote:
> > On Mon, 25 Apr 2011 15:23:41 -0700, Carl Worth  wrote:
> > > On Wed, 17 Nov 2010 23:20:26 +0100, Matthieu Lemerre  
> > > wrote:
> > > > Maybe it would also be interesting to add a warning/assertion to check
> > > > that all email adresses added to the database are correct email
> > > > addresses? I.e. check that the `addr' variable in _index_address_mailbox
> > > > always has a @. This check is in fact already done using the function
> > > > strchr, but a bad value is explicitly ignored...
> > > 
> > > Since GMime is fixed upstream (as of version 2.4.18) another option
> > > would be to simply make the notmuch build system require a sufficiently
> > > new version of GMime in order to build.
> > > 
> > > What do you think?
> 
> I'd say both.
> 
> Unfortunately, regressions are not uncommon, and regardless, it'd be
> nice to be notified when what we stuff in the db is not sane.
> 
> It would however be a good idea IMHO to check email address more
> thorougly [1] than simply verifying whether an "@" is present.

I agree with that, unless it is undesirable to add a dependency to a
regex library to notmuch? If so, the @ check could still be done (and is
_already_ present).

I don't see the warnings either, but maybe with proper differentiation
between stdout and stderr, I could arrange to print stderr and see the
warning messages in emacs when I explicitely launch my mail
synchronization script.

Matthieu

Re: Warning when GMime is parsing broken email addresses

[Matthieu Lemerre]

On Wed, 27 Apr 2011 21:59:09 +0200, Pieter Praet pie...@praet.org wrote:
 On Wed, 27 Apr 2011 18:30:09 +0200, Xavier Maillard xav...@maillard.im 
 wrote:
  On Mon, 25 Apr 2011 15:23:41 -0700, Carl Worth cwo...@cworth.org wrote:
   On Wed, 17 Nov 2010 23:20:26 +0100, Matthieu Lemerre ra...@free.fr 
   wrote:
Maybe it would also be interesting to add a warning/assertion to check
that all email adresses added to the database are correct email
addresses? I.e. check that the `addr' variable in _index_address_mailbox
always has a @. This check is in fact already done using the function
strchr, but a bad value is explicitly ignored...
   
   Since GMime is fixed upstream (as of version 2.4.18) another option
   would be to simply make the notmuch build system require a sufficiently
   new version of GMime in order to build.
   
   What do you think?
 
 I'd say both.
 
 Unfortunately, regressions are not uncommon, and regardless, it'd be
 nice to be notified when what we stuff in the db is not sane.
 
 It would however be a good idea IMHO to check email address more
 thorougly [1] than simply verifying whether an @ is present.

I agree with that, unless it is undesirable to add a dependency to a
regex library to notmuch? If so, the @ check could still be done (and is
_already_ present).

I don't see the warnings either, but maybe with proper differentiation
between stdout and stderr, I could arrange to print stderr and see the
warning messages in emacs when I explicitely launch my mail
synchronization script.

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

Debugging strangeness in To: field

[Matthieu Lemerre]

On Wed, 6 Apr 2011 12:58:25 -0600, Mark Anderson  
wrote:
> Hello all,
> 
> Do you have any hints about how I could figure out why gmime doesn't
> like this To: list?
> 

Hi,

I have encountered this problem before; see id:"87ipzvk2xh.fsf at free.fr".

Basically you have to upgrade gmime, but the debian package is not
up-to-date.

Matthieu

Re: Debugging strangeness in To: field

[Matthieu Lemerre]

On Wed, 6 Apr 2011 12:58:25 -0600, Mark Anderson markr.ander...@amd.com wrote:
 Hello all,
 
 Do you have any hints about how I could figure out why gmime doesn't
 like this To: list?
 

Hi,

I have encountered this problem before; see id:87ipzvk2xh@free.fr.

Basically you have to upgrade gmime, but the debian package is not
up-to-date.

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

Org-mode support

[Matthieu Lemerre]

Hi Micah,

> Thanks so much for sending this, its very interesting! I've just started
> trying it and have managed to use M-x org-store-link on your email to
> add an org-mode todo item to try out org-mode support for notmuch :)

Great, that's how it is supposed to be used! :)

> I have one question, how do you add multiple query arguments? For
> example, in my org file I tried 'notmuch-search:tag:notmuch' - this
> worked great, but if I did 'notmuch-search:tag:notmuch and subject:Org'
> the link only works up until the first space.

This is because org-mode links must be url encoded (this is a org-mode
limitation, could do nothing about it). So in links that contain spaces,
such as yours, spaces must be replaced by %20, like this:

[[notmuch-search:toto%20and%20tata][Notmuch search: toto and tata]]

> I also noticed that David Bremner has done something similar[0] and I
> wonder if you have looked at his code[1], or if David has looked at
> yours. Perhaps the start of a collaboration?

If I remember correctly, I specifically forbid myself to look into this
code because David had copyright issues with its employer. But I believe
that both codes are doing essentially the same thing.

Matthieu

Re: Org-mode support

[Matthieu Lemerre]

Hi Micah,

 Thanks so much for sending this, its very interesting! I've just started
 trying it and have managed to use M-x org-store-link on your email to
 add an org-mode todo item to try out org-mode support for notmuch :)

Great, that's how it is supposed to be used! :)

 I have one question, how do you add multiple query arguments? For
 example, in my org file I tried 'notmuch-search:tag:notmuch' - this
 worked great, but if I did 'notmuch-search:tag:notmuch and subject:Org'
 the link only works up until the first space.

This is because org-mode links must be url encoded (this is a org-mode
limitation, could do nothing about it). So in links that contain spaces,
such as yours, spaces must be replaced by %20, like this:

[[notmuch-search:toto%20and%20tata][Notmuch search: toto and tata]]

 I also noticed that David Bremner has done something similar[0] and I
 wonder if you have looked at his code[1], or if David has looked at
 yours. Perhaps the start of a collaboration?

If I remember correctly, I specifically forbid myself to look into this
code because David had copyright issues with its employer. But I believe
that both codes are doing essentially the same thing.

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

Org-mode support

[Matthieu Lemerre]

On Sun, 13 Feb 2011 19:25:05 +, Darren McGuicken  wrote:
> On Mon, 07 Feb 2011 22:22:17 +0100, Matthieu Lemerre  wrote:
> > I have written the org-mode support for notmuch a while ago. It allows
> > to open links to notmuch from org-mode and create org-mode link from
> > notmuch buffers.
> 
> Excellent, thanks for this, I'll check it out - how does this compare to
> the org support for something like gnus?

I don't know exactly how org-mode supports gnus, but I think pretty much
the same... Basically what it allows is: 

1. When calling org-store-link (or org-capture) from a notmuch-message
or notmuch-search window, store a link to this buffer.

2. When opening a link in org-mode, if the link is a notmuch link, open
the corresponding notmuch buffer.

I use this to empty my inbox and quickly store todo items to my TODO
list/gtd file along the way.

I believe that further org/notmuch integration could be beneficial, and
this represents a first step.

Org-mode support

[Matthieu Lemerre]

Hi everyone,

I have written the org-mode support for notmuch a while ago. It allows
to open links to notmuch from org-mode and create org-mode link from
notmuch buffers.

The current maintainer of the package is looking for feedback for
inclusion of the package in the org-mode trunk, so if anyone is using
org-mode, I think it would be a good idea to say so on the orgmode
mailing list!

I have attached the corresponding file.

Matthieu

-- next part --
A non-text attachment was scrubbed...
Name: org-notmuch.el
Type: application/emacs-lisp
Size: 3626 bytes
Desc: not available
URL: 

Org-mode support

[Matthieu Lemerre]

Hi everyone,

I have written the org-mode support for notmuch a while ago. It allows
to open links to notmuch from org-mode and create org-mode link from
notmuch buffers.

The current maintainer of the package is looking for feedback for
inclusion of the package in the org-mode trunk, so if anyone is using
org-mode, I think it would be a good idea to say so on the orgmode
mailing list!

I have attached the corresponding file.

Matthieu



org-notmuch.el
Description: application/emacs-lisp
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Add a few tests for searching LWN emails.

[Matthieu Lemerre]

> Yes, I believe this is related to the dot in the name. From my
> recollection a name with an address requires quoting. So the header that
> is currently formatted as:
> 
>   From: LWN.net Weekly Notification 
> 
> should instead be:
> 
>   From: "LWN.net Weekly Notification" 

Hi all,

I had already reported this problem in id:"87ipzvk2xh.fsf at free.fr".

Recent versions of GMime perform more robust parsing that fix the
problem, but unfortunately debian only ship old versions of the package.

I don't believe we will be able to make all people from whom we receive
email always send RFC2822-compliant email addresses :)

Matthieu

Warning when GMime is parsing broken email addresses

[Matthieu Lemerre]

On Thu, 18 Nov 2010 13:51:59 -0500, Daniel Kahn Gillmor  wrote:
> Re: Warning when GMime is parsing broken email addresses:
> 
> On 11/18/2010 01:37 PM, Matthieu Lemerre wrote:
> > The problem is solved in version 2.4.18 (current is
> > 2.4.20). Unfortunately the last version packaged for Debian is 2.4.14...
> 
> is the patch that fixes the problem it backportable to 2.4.14 ?  I'm
> sure a report to the debian bts with a patch would be appreciated.  even
> if it doesn't make it into the release because of the freeze, a
> narrowly-targeted patch might be acceptable for a future point release.

Don't know. The main problem is that the package seems to have been more
or less abandoned by its maintainer though... 

Re: Warning when GMime is parsing broken email addresses

[Matthieu Lemerre]

On Thu, 18 Nov 2010 13:51:59 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 Re: Warning when GMime is parsing broken email addresses:
 
 On 11/18/2010 01:37 PM, Matthieu Lemerre wrote:
  The problem is solved in version 2.4.18 (current is
  2.4.20). Unfortunately the last version packaged for Debian is 2.4.14...
 
 is the patch that fixes the problem it backportable to 2.4.14 ?  I'm
 sure a report to the debian bts with a patch would be appreciated.  even
 if it doesn't make it into the release because of the freeze, a
 narrowly-targeted patch might be acceptable for a future point release.

Don't know. The main problem is that the package seems to have been more
or less abandoned by its maintainer though... 
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Warning when GMime is parsing broken email addresses

[Matthieu Lemerre]

The problem is solved in version 2.4.18 (current is
2.4.20). Unfortunately the last version packaged for Debian is 2.4.14...

Matthieu

Re: Warning when GMime is parsing broken email addresses

[Matthieu Lemerre]

The problem is solved in version 2.4.18 (current is
2.4.20). Unfortunately the last version packaged for Debian is 2.4.14...

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

Warning when GMime is parsing broken email addresses

[Matthieu Lemerre]

Hi,

I just realized that GMime is not robust to some broken email addresses
sent by broken email clients. I received a mail, with the to field being

. 

The email client (Exchange) had forgotten to put a "" around
".", which is necessary because `.' is a special character, and
this confused GMime. This resulted in notmuch storing . as the
email address, instead of using - at gmail.com. Because of that I
had trouble finding one of my mail using a to: in the search terms.

I have filed a bug report for GMime
(https://bugzilla.gnome.org/show_bug.cgi?id=545333), but I just wanted
to make people using notmuch aware of this problem, because I guess that
such problems might be extremely common.

Maybe it would also be interesting to add a warning/assertion to check
that all email adresses added to the database are correct email
addresses? I.e. check that the `addr' variable in _index_address_mailbox
always has a @. This check is in fact already done using the function
strchr, but a bad value is explicitly ignored...

Matthieu

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

On Sun, 14 Nov 2010 22:34:38 +0100, Sebastian Spaeth  
wrote:
> On Fri, 12 Nov 2010 17:35:22 +0100, Matthieu Lemerre  wrote:
> > 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?"
> 
> If you accidentally switch to the next thread, it's very easy to just
> hit 'q' to get back to the initial search and go one message up to get
> to the message you just left.

I'd rather not remove the inbox tag from the thread in the first place.

Matthieu

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

On Sun, 14 Nov 2010 14:13:26 -0500, Jameson Rollins  wrote:
> On Sun, 14 Nov 2010 18:01:48 +0100, Matthieu Lemerre  wrote:
> > Now when you consistently label all your mails, you just don't want to
> > have unclassified mails. That is what we meant by "mail you can't find".
> 
> It sounds like this would just as easily be accomplished with a way to
> search for all messages that don't have any tags.  

I think this would be something complementary and indeed very
useful. But the solution I have proposed is not only to ensure that
there are no unclassified mails, but also to help you classify your
mails if it is not done automatically.

I think there are a lot of people used to classify their emails, so I
think this behaviour could be an option in notmuch (even if not set by
default).

Matthieu

[PATCH] How to improve the mail handling workflow?

[Matthieu Lemerre]

> I think you guys may have a misunderstanding about how notmuch indexes
> mail.  Notmuch indexes multiple headers (To, From, Subject, Date) and
> the *entire* body of the message.  That's kind of the whole point.  In
> other words, messages don't have to have tags in order to be found.  

[...]

Not at all. Tags are just a useful complement of information, that
allows to quickly exclude irrelevant results from your search (and
avoids some noisy disk activity). It is just that some of us like to
have all their archived mails "classified" in some way (i.e. by adding a
label or tag), which can be used as a complementary information to help
refine your search. If archiving with a label is seemless, there is no
harm in adding informations to your mail, and it can be a real help when
you don't remember well what you're searching.

Now when you consistently label all your mails, you just don't want to
have unclassified mails. That is what we meant by "mail you can't find".

Matthieu.

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

[Matthieu Lemerre]

 I think you guys may have a misunderstanding about how notmuch indexes
 mail.  Notmuch indexes multiple headers (To, From, Subject, Date) and
 the *entire* body of the message.  That's kind of the whole point.  In
 other words, messages don't have to have tags in order to be found.  

[...]

Not at all. Tags are just a useful complement of information, that
allows to quickly exclude irrelevant results from your search (and
avoids some noisy disk activity). It is just that some of us like to
have all their archived mails classified in some way (i.e. by adding a
label or tag), which can be used as a complementary information to help
refine your search. If archiving with a label is seemless, there is no
harm in adding informations to your mail, and it can be a real help when
you don't remember well what you're searching.

Now when you consistently label all your mails, you just don't want to
have unclassified mails. That is what we meant by mail you can't find.

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 Sun, 14 Nov 2010 14:13:26 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Sun, 14 Nov 2010 18:01:48 +0100, Matthieu Lemerre ra...@free.fr wrote:
  Now when you consistently label all your mails, you just don't want to
  have unclassified mails. That is what we meant by mail you can't find.
 
 It sounds like this would just as easily be accomplished with a way to
 search for all messages that don't have any tags.  

I think this would be something complementary and indeed very
useful. But the solution I have proposed is not only to ensure that
there are no unclassified mails, but also to help you classify your
mails if it is not done automatically.

I think there are a lot of people used to classify their emails, so I
think this behaviour could be an option in notmuch (even if not set by
default).

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 Sun, 14 Nov 2010 22:34:38 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On Fri, 12 Nov 2010 17:35:22 +0100, Matthieu Lemerre ra...@free.fr wrote:
  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?
 
 If you accidentally switch to the next thread, it's very easy to just
 hit 'q' to get back to the initial search and go one message up to get
 to the message you just left.

I'd rather not remove the inbox tag from the thread in the first place.

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

[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

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

[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

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

[Matthieu Lemerre]

On Fri, 12 Nov 2010 15:39:37 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre ra...@free.fr 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

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

[Matthieu Lemerre]

On Fri, 12 Nov 2010 17:05:23 +, David Edmondson d...@dme.org wrote:
 On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre ra...@free.fr 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] [PATCH] Support for deletion (patch included)

[Matthieu Lemerre]

I forgot the attachment..

-- next part --
A non-text attachment was scrubbed...
Name: notmuch-deletion.patch
Type: text/x-diff
Size: 4002 bytes
Desc: not available
URL: 

[notmuch] [PATCH] Support for deletion by the emacs client

[Matthieu Lemerre]

Hello,

I tried notmuch and I really like it. I like having an emacs email
client, but was proficient with none of them (neither with non-emacs
clients, btw). Notmuch really seems the way to go.

However, support for deletion is important to me. Here is a first patch
that implements it for the emacs interface.

Here is how I did it: notmuch-search no longer list arguments with the
deleted tag, unless you execute it with a prefix arg. When you launch it
with C-u s, the query string changes, and it provides you the current
query string by default.

That way, if you want to search for mail, and then decide that you may
have deleted it, you just have to type C-u s to find it. The good part
is that it works even if you didn't knew about it, i.e. if you type C-u
s to launch a new query.


I also added a command history to notmuch-search.


Now I'd like to write a command to expunge deleted mails; this shouldn't
be difficult. Having notmuch detect that some mails disappeared and
update the database seems more difficult, though.

Regards,
Matthieu Lemerre


PS: I have trouble understanding why space on the last message on a
thread deletes the inbox tag. If you do it, then you mail becomes
untagged and imo quite difficult to search. How is the mail flow
supposed to work?

[notmuch] [PATCH] Support for deletion by the emacs client

[Matthieu Lemerre]

Hello,

I tried notmuch and I really like it. I like having an emacs email
client, but was proficient with none of them (neither with non-emacs
clients, btw). Notmuch really seems the way to go.

However, support for deletion is important to me. Here is a first patch
that implements it for the emacs interface.

Here is how I did it: notmuch-search no longer list arguments with the
deleted tag, unless you execute it with a prefix arg. When you launch it
with C-u s, the query string changes, and it provides you the current
query string by default.

That way, if you want to search for mail, and then decide that you may
have deleted it, you just have to type C-u s to find it. The good part
is that it works even if you didn't knew about it, i.e. if you type C-u
s to launch a new query.


I also added a command history to notmuch-search.


Now I'd like to write a command to expunge deleted mails; this shouldn't
be difficult. Having notmuch detect that some mails disappeared and
update the database seems more difficult, though.

Regards,
Matthieu Lemerre


PS: I have trouble understanding why space on the last message on a
thread deletes the inbox tag. If you do it, then you mail becomes
untagged and imo quite difficult to search. How is the mail flow
supposed to work?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Support for deletion (patch included)

[Matthieu Lemerre]

I forgot the attachment..

diff --git a/notmuch.el b/notmuch.el
index 97914f2..f770dd0 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -991,6 +991,7 @@ matching this search term are shown if non-nil. 
 (define-key map [mouse-1] 'notmuch-search-show-thread)
 (define-key map * 'notmuch-search-operate-all)
 (define-key map a 'notmuch-search-archive-thread)
+(define-key map d 'notmuch-search-mark-as-deleted)
 (define-key map - 'notmuch-search-remove-tag)
 (define-key map + 'notmuch-search-add-tag)
 (define-key map (kbd RET) 'notmuch-search-show-thread)
@@ -999,6 +1000,7 @@ matching this search term are shown if non-nil. 
 (fset 'notmuch-search-mode-map notmuch-search-mode-map)
 
 (defvar notmuch-search-query-string)
+(defvar notmuch-search-history nil)
 (defvar notmuch-search-oldest-first t
   Show the oldest mail first in the search-mode)
 
@@ -1210,6 +1212,15 @@ This function advances the next thread when finished.
   (notmuch-search-remove-tag inbox)
   (forward-line))
 
+
+(defun notmuch-search-mark-as-deleted ()
+  Mark the currently selected thread as deleted (set its \deleted\ tag).
+This function advances the next thread when finished.
+  (interactive)
+  (notmuch-search-add-tag deleted)
+  (forward-line))
+
+
 (defun notmuch-search-process-sentinel (proc msg)
   Add a message to let user know when \notmuch search\ exits
   (let ((buffer (process-buffer proc))
@@ -1284,10 +1295,22 @@ characters as well as `_.+-'.
 	   (append action-split (list notmuch-search-query-string) nil
 
 ;;;###autoload
-(defun notmuch-search (query optional oldest-first)
-  Run \notmuch search\ with the given query string and display results.
-  (interactive sNotmuch search: )
-  (let ((buffer (get-buffer-create (concat *notmuch-search- query *
+(defun notmuch-search (query optional oldest-first include-deleted)
+  Run \notmuch search\ with the given query string and display results.
+
+With prefix argument, include deleted items.
+
+  (interactive (let* ((prefix current-prefix-arg)
+		  (query (if prefix
+ (read-string Notmuch search (including deleted): 
+	  notmuch-search-query-string
+	  'notmuch-search-history)
+			   (read-string Notmuch search:  nil
+	'notmuch-search-history
+		 (list query nil prefix)))
+  (let ((real-query (if include-deleted query 
+		  (concat not tag:deleted and ( query 
+	(buffer (get-buffer-create (concat *notmuch-search- query *
 (switch-to-buffer buffer)
 (notmuch-search-mode)
 (set 'notmuch-search-query-string query)
@@ -1303,7 +1326,7 @@ characters as well as `_.+-'.
 	(let ((proc (start-process-shell-command
 		 notmuch-search buffer notmuch-command search
 		 (if oldest-first --sort=oldest-first --sort=newest-first)
-		 (shell-quote-argument query
+		 (shell-quote-argument real-query
 	  (set-process-sentinel proc 'notmuch-search-process-sentinel)
 	  (set-process-filter proc 'notmuch-search-process-filter
 (run-hooks 'notmuch-search-hook)))
@@ -1351,7 +1374,6 @@ search.
 
 Runs a new search matching only messages that match both the
 current search results AND the additional query string provided.
-  (interactive sFilter search: )
   (let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp query) (concat (  query  )) query)))
 (notmuch-search (concat notmuch-search-query-string  and  grouped-query) notmuch-search-oldest-first)))
 
@@ -1391,7 +1413,9 @@ current search results AND that are tagged with the given tag.
 
 (fset 'notmuch-folder-mode-map notmuch-folder-mode-map)
 
-(defcustom notmuch-folders (quote ((inbox . tag:inbox) (unread . tag:unread)))
+(defcustom notmuch-folders (quote ((inbox . tag:inbox) 
+   (unread . tag:unread)
+   (deleted . tag:deleted)))
   List of searches for the notmuch folder view
   :type '(alist :key-type (string) :value-type (string))
   :group 'notmuch)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch