unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
* proposal for more streamlined mail flow in notmuch
@ 2010-01-16 20:49 Jameson Rollins
  2010-01-25 21:07 ` martin f krafft
  2010-01-26  3:19 ` Ben Gamari
  0 siblings, 2 replies; 3+ messages in thread
From: Jameson Rollins @ 2010-01-16 20:49 UTC (permalink / raw)
  To: Notmuch Mail

[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]

I would like to put forth here a proposal for a couple of changes to
notmuch that I believe will considerably streamline message handling
and new message flow through notmuch.  Notmuch is still new and I
believe it hasn't quite figured out the best way to handle message
flow in the new mail handling paradigm that it is working.  This is a
proposal to fix that.

I believe that most people are syncing their mail from remote IMAP or
POP servers to local maildirs (via offlineimap for instance), and that
most people's IMAP servers have limited storage capacity.  This
practically means that people can not keep all of their mail in a
single directory.  However, notmuch currently basically assumes that
this is what is happening.  In order to keep synced maildirs from
growing out of hand, messages need to be either deleted or moved out
of the "inbox" where they initially show up.  This is why it was so
important for notmuch to get support for deletion/renaming/moving of
messages.

However, we still need to get notmuch to fundamentally understand this
flow (mail comes into inbox, and is then moved elsewhere), and provide
the functions to easily facilitate this flow for users.

To this end, here is how I believe the notmuch flow should look:

- New messages are delivered into a maildir "inbox".  When notmuch new
  is run, these new messages are tagged 'inbox' and 'unread'.

- When a user views a message with their reader, the 'unread' tag is
  automatically removed, the maildir S flag is added and the message
  is moved from inbox/new to inbox/cur.

- If the user wishes to delete a message, a 'delete' tag is added to
  the message.  If the user does a "purge", all messages tagged
  'delete' are erased from disk and/or a "delete hook" is run.

- If the user wishes to archive a message the 'inbox' tag is removed
  and the messages is actually moved from the inbox maildir into an
  archive maildir and/or an "archive hook" is run.

To fascilitate this, two new functions should be implemented at the
notmuch CLI level, so that things don't get fractured by different
mail reader implementations:

notmuch purge

  delete all 'delete' tagged messages, and/or execute "delete hooks"

notmuch archive <search-terms>

  remove 'inbox' flags from messages and move messages an archive
  maildir, and/or execute "archive hooks"

I believe this is a simple, intuitive flow, that will be easy to
understand and work with by pretty much all users, but is still very
nicely extensible for advanced users.  For instance, a delete hook
might move the message to a trash instead of deleting it outright, or
an "archive hook" could filter archived messages into folders.  Hooks
could also be used to do nothing to messages other than just modifying
the tags (which would completely mimic the current notmuch behavior).
The config file could be kept very simple (only two hooks would need
to be defined), without having to move to some crazy script-based
config scheme (like lua) that is overly complicated and very hard for
new users to understand.  It would also great simplify the mail
readers themselves (like the emacs UI), because it would greatly
reduce the number of commands (ie. essentially just "view", "delete",
"archive", or "search").

What do folks think of this proposal?  I am convinced that this flow
is simple, would be intuitive to new users, and extensible such that
it could provide the functionality that anyone could desire.  I would
be curious to hear of anyone interested in using notmuch who thinks
they could *not* achieve the mail flow that they desire with this
scheme.

Any and all feedback on this proposal is welcome.  If people think
this flow is a good idea, I would be psyched to start fleshing it out.

jamie.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: proposal for more streamlined mail flow in notmuch
  2010-01-16 20:49 proposal for more streamlined mail flow in notmuch Jameson Rollins
@ 2010-01-25 21:07 ` martin f krafft
  2010-01-26  3:19 ` Ben Gamari
  1 sibling, 0 replies; 3+ messages in thread
From: martin f krafft @ 2010-01-25 21:07 UTC (permalink / raw)
  To: notmuch

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

also sprach Jameson Rollins <jrollins@finestructure.net> [2010.01.17.0949 +1300]:
> I would like to put forth here a proposal for a couple of changes
> to notmuch that I believe will considerably streamline message
> handling and new message flow through notmuch.  Notmuch is still
> new and I believe it hasn't quite figured out the best way to
> handle message flow in the new mail handling paradigm that it is
> working.  This is a proposal to fix that.
>
> I believe that most people are syncing their mail from remote IMAP or
> POP servers to local maildirs (via offlineimap for instance), and that
> most people's IMAP servers have limited storage capacity.  This
> practically means that people can not keep all of their mail in a
> single directory.  However, notmuch currently basically assumes that
> this is what is happening.  In order to keep synced maildirs from
> growing out of hand, messages need to be either deleted or moved out
> of the "inbox" where they initially show up.

We should keep this in mind when designing an object store, whether
or not that's based on Git. If we use Git, then a local branch is
all we really need to support this. \o/

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
above all, we should not wish to divest
our existence of its rich ambiguity.
                                                 --friedrich nietzsche
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: proposal for more streamlined mail flow in notmuch
  2010-01-16 20:49 proposal for more streamlined mail flow in notmuch Jameson Rollins
  2010-01-25 21:07 ` martin f krafft
@ 2010-01-26  3:19 ` Ben Gamari
  1 sibling, 0 replies; 3+ messages in thread
From: Ben Gamari @ 2010-01-26  3:19 UTC (permalink / raw)
  To: notmuch

Excerpts from Jameson Rollins's message of Sat Jan 16 15:49:55 -0500 2010:
> To fascilitate this, two new functions should be implemented at the
> notmuch CLI level, so that things don't get fractured by different
> mail reader implementations:
> 
> notmuch purge
> 
>   delete all 'delete' tagged messages, and/or execute "delete hooks"
> 
> notmuch archive <search-terms>
> 
>   remove 'inbox' flags from messages and move messages an archive
>   maildir, and/or execute "archive hooks"
> 
I'm a little suspicious of this. Again, it seems like there is nothing
whatsoever preventing one from implementing this at a higher-level than
notmuch, which I believe should be little more than a thin-wrapper
around Xapian unless more functionality is absolutely necessary. I don't
understand why these sorts of proposals keep coming up when the above,
for example, could be easily implemented in a pair of ten line shell
scripts. Am I missing something?

In my opinion, the "fractured implementations" argument is mislead at
best. We currently have exactly two (in the case of vim, somewhat)
usable UIs.  It's not difficult to see to it that they obey similar
conventions. If another UI pops up that fails to obey your favorite
convention, feel free to patch it. IMHO, it is not the place of notmuch
to force semantics onto the user (in fact, it tries to avoid this
wherever possible).

- Ben

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-01-26  3:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-16 20:49 proposal for more streamlined mail flow in notmuch Jameson Rollins
2010-01-25 21:07 ` martin f krafft
2010-01-26  3:19 ` Ben Gamari

Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).