[notmuch] Request for high-priority improvements to notmuch

[Jameson Rollins]

Hello Carl et. al.

I know you're trying to work through a boat load of backlog patches, but
after using notmuch for a couple weeks now, I would like to highlight
what I think are the two most important things that need to be be
implemented in the notmuch CLI and why.

Ability to apply tags based on folder paths in "notmuch new"
------------------------------------------------------------
Notmuch needs to be able to be configured to tag messages differently if
they appear in different folders (mentioned previously in
id:87tyu9dfhs.fsf at servo.finestructure.net).  For instance, for
"inbox"/"sent"/"drafts"/"archive" maildir subdirectories of your primary
mail directory "/home/user/mail", a notmuch config could look like this:

   [database]
   path=/home/user/mail

   [tags]
   inbox = +inbox,+unread
   sent = +sent
   drafts = +draft
   archive = -inbox

In other words, a user could specify that new messages to the maildir
"/home/user/mail/sent" would be tagged *only* with the "sent" tag.

This is very important for being able to handle different kinds of new
messages differently, which is very important for being able to have
notmuch handle things that it is currently unable to handle.  If this is
*not* implemented, then there is no way to distinguish different kinds
of new mail in notmuch, which severely restricts subtle handling of
different mail situations.

For instance, this feature would deal with the following problems:

* Notmuch currently does not handle sent mail.  If sent messages are to
be indexed, then they need to be delivered or fcc'd to a maildir which
is indexed by notmuch.  But this means they currently always show up as
"inbox"/"unread", which means they always appear in the inbox.  Folder
based tagging would allow sent mail to instead be delivered or fcc'd to
a sent mail or archive folder that would not get the "inbox"/"unread"
tags.

* Notmuch currently does not handle draft messages.  If this folder
tagging scheme is available, draft messages could be stored in an
indexed directory, which would allow viewing of draft messages
(currently also not supported), and therefore building simple functions
to resume saved drafts.

I really believe this needs to be implemented in "notmuch new".  If it
were implemented in a separate function it would require two calls to
notmuch for every notmuch new, which would be a waste.

JSON output for "notmuch search/show" with ability to filter output fields
--------------------------------------------------------------------------
This is very important to enable more effective, streamlined, and faster
notmuch helper functions and scripts.  There has been a lot of
discussion about what notmuch should or should not be handling.  No
matter what eventually happens, it is clear that notmuch needs to make
it as easy as possible for external applications to parse it's output.
Clearly the best way to do that is to provide JSON output, which is a
widely adopted standard that is well supported in any language one
might want to use to build a notmuch wrapper.

If notmuch could also be told to output only certain desired fields,
then parsing by clients would be made significantly more efficient.  Not
to mention the notmuch UI itself could be streamlined as the "search"
and "show" functions could be combined into a single subcommand:

"search" --> "search --output=thread_id,date,number,author,subject,tags"
 "show"  --> "search --output=message_id,tags,path,header,body,attachments"

This would all make things *much* easier for clients.  For instance,
here are just a couple of things that could handled in wrapper scripts
that would be greatly facilitated by this proposal (including proposed
notmuch search filtered output commands):

* Proper maildir sync ("search --output=message_id,tags,path" ...)

* Purging "delete" tagged messages ("search --output=path" tags:delete)

* Moving/archiving messages based on search results ("search --output=path" ...)

* New client viewers

I believe there is already a patch in the queue to move to JSON output,
so hopefully this can be implemented without much further work.

--------------------------------------------------

I really think these enhancements are very important, and notmuch should
be aiming to implement them soon.  They would greatly extend the
capabilities of notmuch, without restricting it's usage at all.  They
would blow open the doors for making notmuch helper applications, which
would essentially eliminate further discussion on what notmuch should
be handling natively or not.  A lot of the current shortcomings of
notmuch could be easily dealt with if these enhancements are
implemented.

Thanks so much for the time, and I look forward to any discussion on
these ideas, and to seeing them in near-future releases.

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/20100201/7ba85655/attachment.pgp>