date:20100226

On Fri, 26 Feb 2010 11:55:19 -0800, Carl Worth  wrote:
> On Fri, 26 Feb 2010 07:53:29 -0500, James Vasile  
> wrote:
> > Maybe this retry loop should be put in notmuch itself?
> 
> Perhaps it should. I've even imagined something that would queue a
> request into a daemon if the database isn't currently available.
> 
> But of course there are issues about whether the caller would want to
> know about the locking error, (or might actually need to block until the
> operation is complete). So I'm not sure about the right answer here.

--block and/or --queue?

[notmuch] Initial tagging

On Fri, 26 Feb 2010 20:33:08 -0500, micah anderson  wrote:
> 
> Hey james,
> 
> i really like your notmuch-retry bits, I've taken that shell script and
> integrated it into my tagging script, thanks! I'm curious if you are
> going to update your patch for notmuch.el ("Calls to notmuch get queued
> and executed asynchronously") to use this, or if you are going to have
> those two continue to be separate ways of retrying?

Ah, I updated my local version and am putting it through its paces, but
it's already so much better that I should just send in the revised
patch.  I'll clean it up and do that tomorrow.

> Why do you tag new mail with tags, rather than construct folder searches
> to create views? 

I do a lot of on-the-fly searching and don't want to have to remember
notmuch's email address.  I suppose I could go to my notmuch folder and
then filter from there, but right now I'm much more likely to do M-x
notmuch-search/tag:notmuch and micah.

[notmuch] Initial tagging

On Fri, 26 Feb 2010 12:14:45 -0500, micah anderson  wrote:
> On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile  
> wrote:
> This stuff should go up on the wiki! There is a "Tips and Tricks for
> using notmuch with Emacs" section, but more general things like James'
> script and other people's scripts really should be put up there so
> people who are new can figure out how to get started faster.

Good point.  I will put some stuff on the wiki.

> 0. indirectly I believe am also responsible, through 3rd party
> evangelizing, for James entering the scene as well, and I'm happy about
> that because I have been quite pleased with his enhancements, thanks
> james!. now I just need to buy him a drink and talk him into fixing the
> openpgp bits ;)

Yes, you are my upstream evangelist.  You put the bug in Karl Fogel's
ear (although he hasn't actually tried it) and he put it in mine.  Glad
you're liking my elisp.

I've spent a bunch of time thinking about mail setups (I actually
sketched out what I'd need to do to mutt to get virtual folders there),
so it's great to see people making serious strides toward getting it
right.

Notmuch isn't a mail client so much as a mail kit.  I'm happy to be
hacking on it and making my mail work the way I want.

-J

[notmuch] Initial tagging

2010-02-26 Thread micah anderson

Hey james,

i really like your notmuch-retry bits, I've taken that shell script and
integrated it into my tagging script, thanks! I'm curious if you are
going to update your patch for notmuch.el ("Calls to notmuch get queued
and executed asynchronously") to use this, or if you are going to have
those two continue to be separate ways of retrying?

On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile  
wrote:

> The tagging script uses the inbox tag to identify new mail, tags it
> according to criteria, then removes the inbox tag from anything it found
> a match for.  Uncategorized mail keeps the inbox tag so I can inspect it
> later and make rules for it (or tag it manually).

Why do you tag new mail with tags, rather than construct folder searches
to create views? 

For example, rather than adding more and more data to the database every
time your script runs and does something like the following:

tag_new "+list +notmuch" "to:notmuchmail.org or notmuch"

Why don't you instead create a folder in your .emacs like this:

(setq notmuch-folders '(("inbox" . "tag:inbox")
("unread" . "tag:inbox AND tag:unread")
("notmuch" . "to:notmuchmail.org")))

That way, if you want to read the notmuch mailing list, you would simply
open that folder, which would present you with the results of that
search. 

You could do different things with the tag:unread and tag:inbox flags,
depending on what you wanted to accomplish. Namely, you may wish to only
have a view of all the unread notmuch mailing list messages, in which
case you would make that query "tag:unread AND to:notmuchmail.org".

I'm just curious about the rationale for doing it one way, over the
other. 

micah
-- 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/20100226/46369fa3/attachment.pgp>

[notmuch] [PATCH v2 3/4] Configure the database separately from mail store

2010-02-26 Thread David Benjamin

Signed-off-by: David Benjamin 
---

 Apparently I never ran the last-minute tweak I did to
 notmuch_config_set_database_path. Oops. Oh well, here's the trivially fixed
 version.

 notmuch-client.h |7 ++
 notmuch-config.c |   62 --
 notmuch-new.c|   14 ---
 3 files changed, 58 insertions(+), 25 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 1a676d2..010fdc7 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -148,6 +148,13 @@ void
 notmuch_config_set_database_path (notmuch_config_t *config,
  const char *database_path);

+const char *
+notmuch_config_get_database_notmuch_path (notmuch_config_t *config);
+
+void
+notmuch_config_set_database_notmuch_path (notmuch_config_t *config,
+ const char *database_notmuch_path);
+
 notmuch_database_t *
 notmuch_config_open_database (notmuch_config_t *config,
  notmuch_database_mode_t mode);
diff --git a/notmuch-config.c b/notmuch-config.c
index 58a28b1..ccae35d 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -58,6 +58,7 @@ struct _notmuch_config {
 GKeyFile *key_file;

 char *database_path;
+char *database_notmuch_path;
 char *user_name;
 char *user_primary_email;
 char **user_other_email;
@@ -151,6 +152,8 @@ get_username_from_passwd_file (void *ctx)
  *
  * database_path:  $HOME/mail
  *
+ * database_notmuch_path:  database_path/.notmuch
+ *
  * user_name:  From /etc/passwd
  *
  * user_primary_mail:  $EMAIL variable if set, otherwise
@@ -195,6 +198,7 @@ notmuch_config_open (void *ctx,
 config->key_file = g_key_file_new ();

 config->database_path = NULL;
+config->database_notmuch_path = NULL;
 config->user_name = NULL;
 config->user_primary_email = NULL;
 config->user_other_email = NULL;
@@ -351,6 +355,45 @@ notmuch_config_set_database_path (notmuch_config_t *config,

 talloc_free (config->database_path);
 config->database_path = NULL;
+/* In case this path is dynamically generated */
+talloc_free (config->database_notmuch_path);
+config->database_notmuch_path = NULL;
+}
+
+const char *
+notmuch_config_get_database_notmuch_path (notmuch_config_t *config)
+{
+const char *path;
+char *notmuch_path;
+
+if (config->database_notmuch_path == NULL) {
+   notmuch_path = g_key_file_get_string (config->key_file,
+ "database", "notmuch_path", NULL);
+   if (notmuch_path) {
+   config->database_notmuch_path = talloc_strdup (config, 
notmuch_path);
+   free (notmuch_path);
+   } else {
+   path = notmuch_config_get_database_path (config);
+   if (path != NULL) {
+   notmuch_path = talloc_asprintf (config, "%s/%s",
+   path, ".notmuch");
+   config->database_notmuch_path = notmuch_path;
+   }
+   }
+}
+
+return config->database_notmuch_path;
+}
+
+void
+notmuch_config_set_database_notmuch_path (notmuch_config_t *config,
+ const char *database_notmuch_path)
+{
+g_key_file_set_string (config->key_file,
+  "database", "notmuch_path", database_notmuch_path);
+
+talloc_free (config->database_notmuch_path);
+config->database_notmuch_path = NULL;
 }

 notmuch_database_t *
@@ -358,26 +401,13 @@ notmuch_config_open_database (notmuch_config_t *config,
  notmuch_database_mode_t mode)
 {
 const char *path = NULL;
-char *db_path = NULL;
+const char *notmuch_path = NULL;
 notmuch_database_t *notmuch = NULL;

 path = notmuch_config_get_database_path (config);
-if (path == NULL) {
-   fprintf (stderr, "Error: Cannot create a database for a NULL path.\n");
-   goto DONE;
-}
-
-if (asprintf (_path, "%s/%s", path, ".notmuch") == -1) {
-   db_path = NULL;
-   fprintf (stderr, "Out of memory\n");
-   goto DONE;
-}
-
-notmuch = notmuch_database_open (path, db_path, mode);
+notmuch_path = notmuch_config_get_database_notmuch_path (config);

-DONE:
-if (db_path)
-   free(db_path);
+notmuch = notmuch_database_open (path, notmuch_path, mode);

 return notmuch;
 }
diff --git a/notmuch-new.c b/notmuch-new.c
index d24dab9..d36edd5 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -713,7 +713,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
 int ret = 0;
 struct stat st;
 const char *db_path;
-char *dot_notmuch_path;
+const char *notmuch_path;
 struct sigaction action;
 _filename_node_t *f;
 int renamed_files, removed_files;
@@ -737,10 +737,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
return 1;

 db_path = notmuch_config_get_database_path (config);
+notmuch_path =

[notmuch] Thoughts on not seeing messages I can't deal with (yet, or now, or here...)

2010-02-26 Thread Mark Anderson

Carl,

There's a post from a while ago about using GTD on Remember The Milk.

Remember the Milk as described here is mainly a todo manager, but the
saved search (as a list of todo tasks that match the criterion) is
what's being utilized here that makes me think so much of notmuch.

This seems to capture some of the things that you want to see, since you
are trying to manage action items which happen to live in mail bodies.

http://blog.rememberthemilk.com/2008/05/guest-post-advanced-gtd-with-remember-the-milk/

apparently another post has expired on the topic, with some focus on
contexts:

http://web.archive.org/web/20080331121051/http://www.geektronica.com/2007-01-15-gtd-with-rtm-getting-things-done-with-remember-the-milk

The main tool in use here is a viewport on the collection of things that
might need to be reviewed. RTM tabs (which are saved searches) which you
have designed to be the contexts you might be executing in, in this
case.

I know this is related pretty heavily to what you are looking for, but
how to bring this about specifically, that's going to be up to you.

Enjoy,
-Mark

On Fri, 26 Feb 2010 14:00:06 -0600, Carl Worth  wrote:
> [This mail started as some off-topic rambling in my reply to the
> notmuch-reply script. So that's why it starts on one topic and ends
> somewhere else entirely.]
> 
> I'm currently avoiding any locking failures with notmuch commands by
> running "notmuch new" manually, (rather than from a cron job). And it
> occurs to me that running "notmuch new" manually has a certain
> benefit---it allows me to bring in a chunk of mail, and then process all
> of that (either by replying, or setting aside to a particular project or
> "todo" tag, etc.) without getting distracted by other mail coming in.
> 
> It almost makes me want to just run "notmuch new" something like once
> per day.
> 
> But then, of course, there are times where there are important messages
> I need to get to quickly, or fast-moving threads where I need to reply
> several times throughout the day.
> 
> But I do have particular mailing lists that I don't want to read more
> than once a day, for instance. If I wait until I have about a days worth
> of mail in those lists, then I can deal with them very efficiently,
> (just scan all the subjects, read a thread or two and the "* -inbox" the
> rest). This gets a lot less efficient if I have to deal with those lists
> on a regular basis throughout the day, (particularly before we have
> support for "muted" threads).
> 
> So I'd like to be able to deal with important messages as they come in,
> but postpone bulk stuff.
> 
> But I also notice that there's a bad tendency I have if I try to do this
> postponing manually. Mail starts collecting in one of these bulk-list
> folders, and I start training myself to ignore the folder, then it gets
> huge, (which discourages me even more from looking at it, etc.). [*]
> 
> So I want better support from notmuch to tell me what things deserve my
> attention, so that I can avoid training myself to ignore things. I think
> what I want here is the ability to set a threshold on a particular
> folder based on number of messages or date. Something like: "Don't show
> me this folder at all until it has more than X messages or until the
> oldest message is at least Y hours old".
> 
> [*] A similar, (but more dangerous), problem occurs with manually
> postponing things into a "todo" folder. If I just added a bunch of
> things to my todo folder then I have a tendency to think, "I don't need
> to look at that---that's got a bunch of things I just decided to
> postpone". But then I forget that I put some things in there previously
> that really need my attention now.
> 
> I know that what I really want instead of "todo" is a way to express the
> reason I'm postponing a message. There's probably some resource I'm
> missing that I need before I can deal with it. Perhaps that's:
> 
>   * I can't decide on this until I'm with co-workers and can talk about
> this.
> 
>   * I can't resolve this until I'm at the office with the right hardware
> to test.
> 
>   * I need to remember to do something with this when I'm at home.
> 
>   * I need a nice block of "discretionary time" to be able to give this
> topic the attention I want to.
> 
>   * I need to look at this message again on this Saturday.
> 
> So what I really want to do is to tag things based on those criteria,
> ("office", "magic-hardware", "home", "discretionary", "2010-02-27"),
> which I can at least do now.
> 
> But what I'm currently missing is a way for the folders based on these
> tags to only appear at the right times, (when the resource is
> available).
> 
> When the messages appear at the wrong times, it just trains me to ignore
> things, and that's when I start forgetting things and let things fall
> through.
> 
> No concrete proposal here, but just some musings on the kinds of issues
> I'd really like to be exploring with notmuch, (once we can get past all
>

[notmuch] Initial tagging

2010-02-26 Thread martin f krafft

also sprach Jameson Rollins  [2010.02.26.1600 
+0100]:
> > Me too! :-)
> 
> Isn't that what "folders" are?  At least that's what they seem to me.  I
> define a specific search, give it a name, and save it as a folder.

There's a 1:? relationship between folders and messages. I might
want a message associated with multiple contexts.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems

"you know you're a hopeless geek when you misspell 'date' as 'data'"
   -- branden robinson
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100226/84366df4/attachment.pgp>

[notmuch] [PATCH] Simplify "unread" tag handling in emacs UI.

On Thu, 25 Feb 2010 11:23:40 +0100, "Sebastian Spaeth"  wrote:
> Well, it is fatal in the sense that it makes that function useless. But
> it's not as bad as it is currently unused.

Right. I didn't want to push something out with a known-broken function.

I would have rather the patch just remove the function in that case,
(but the fact that someone noticed the broken function meant that
someone actually *was* using it and removing it wouldn't be nice
either).

> I still think it's worth taking this patch and fixing it then.

Done and pushed out now.

> - split into a "notmuch-show-next-message"
>   and a notmuch-show-show-next-message (what a naming!) function. 
>   One would merely skip to the next and one actually show and mark
>   unread.

That's the approach I took, with naming of
notmuch-show-next-message-without-marking-read. And yes, the naming we
have for our emacs functions is awful. I really dislike "notmuch-show"
as a prefix because it puts a verb in the prefix, (where I'd instead
like to just have a verb for the actual functionality of the function).

But we have to have at least *something* to separate the search-results
and message-viewing modes, (since we have commands like "archive" in
both of them). The lack of nice scoping here is really awkward.

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

[notmuch] [PATCH 2/2] document new `notmuch new` behavior

---
 notmuch.1 |8 +---
 notmuch.c |3 ++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/notmuch.1 b/notmuch.1
index 282ad98..f03529e 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -93,9 +93,11 @@ The
 .B new
 command scans all sub-directories of the database, performing
 full-text indexing on new messages that are found. Each new message
-will automatically be tagged with both the
-.BR inbox " and " unread
-tags.
+will automatically be tagged with the
+.BR inbox
+tag, and, unless it was already "seen" by another client, the
+.BR unread
+tag.

 You should run
 .B "notmuch new"
diff --git a/notmuch.c b/notmuch.c
index 87479f8..fc6bb7f 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -127,7 +127,8 @@ command_t commands[] = {
   "\t\tFind and import new messages to the notmuch database.",
   "\t\tScans all sub-directories of the mail directory, performing\n"
   "\t\tfull-text indexing on new messages that are found. Each new\n"
-  "\t\tmessage will be tagged as both \"inbox\" and \"unread\".\n"
+  "\t\tmessage will be tagged as \"inbox\" and, unless it is\n"
+  "\t\tmarked as \"seen\", \"unread\".\n"
   "\n"
   "\t\tYou should run \"notmuch new\" once after first running\n"
   "\t\t\"notmuch setup\" to create the initial database. The first\n"
-- 
1.7.0

[notmuch] [PATCH 1/2] Initial support for maildir flags.

When adding new messages, if they have the 'S' (seen) flag, do not add
them to the 'unread' tag.
---
 lib/message.cc |   25 +
 lib/notmuch.h  |5 +
 notmuch-new.c  |3 ++-
 3 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index f0e905b..61c9cc3 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -516,6 +516,31 @@ notmuch_message_set_flag (notmuch_message_t *message,
message->flags &= ~(1 << flag);
 }

+notmuch_bool_t
+notmuch_message_md_flag (notmuch_message_t *message,
+const char flag)
+{
+const char *filename;
+const char *p;
+
+filename = notmuch_message_get_filename (message);
+
+p = strstr (filename, ":2,");
+if (p == NULL) {
+/* Not a valid maildir filename */
+return FALSE;
+}
+
+for (p += 3; *p != '\0'; p++) {
+if (*p == flag) {
+return TRUE;
+}
+}
+
+return FALSE;
+}
+
+
 time_t
 notmuch_message_get_date (notmuch_message_t *message)
 {
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 15c9db4..db9e917 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -753,6 +753,11 @@ void
 notmuch_message_set_flag (notmuch_message_t *message,
  notmuch_message_flag_t flag, notmuch_bool_t value);

+/* See if a given maildir flag is set, based on the message's filename. */
+notmuch_bool_t
+notmuch_message_md_flag (notmuch_message_t *message,
+const char flag);
+
 /* Get the date of 'message' as a time_t value.
  *
  * For the original textual representation of the Date header from the
diff --git a/notmuch-new.c b/notmuch-new.c
index b740ee2..6d62f3f 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -97,7 +97,8 @@ static void
 tag_inbox_and_unread (notmuch_message_t *message)
 {
 notmuch_message_add_tag (message, "inbox");
-notmuch_message_add_tag (message, "unread");
+if (! notmuch_message_md_flag(message, 'S'))
+notmuch_message_add_tag (message, "unread");
 }

 static void
-- 
1.7.0

[notmuch] [PATCH] A simple approach to maildir flags

The following patches attempt to provide a simple, extendable approach
to handling the 'Seen' maildir flag. To appease (hopefully) everyone, it
will only do this for new messages. This means that people coming from
another MUA won't be stuck with 30,000 unread messages, for example.

It should be simple to extend this to other maildir flags, too, if
people want them and can decide on what tags they should correspond to.

[notmuch] Initial tagging

2010-02-26 Thread micah anderson

On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile  
wrote:

> I'm curious as to what people are doing in this regard.

I am pretty good at evangelizing notmuch and converted another
person[0]... in doing so I realized I had to walk through a few issues
to get them started. 

The initial documentation for notmuch is really great, but the other
magical bits are missing, like "holy cow all my email is in my inbox
now!"; "how do I deal with folders?"; "do i run notmuch new every
time?"; "do you auto-tag things?"; "how do you deal with attachments?";
"how do you read encrypted email"? etc. etc. all of these getting
started with notmuch things... including the script that James just
posted, the getmail tagging stuff that was posted a little while back,
etc. 

This stuff should go up on the wiki! There is a "Tips and Tricks for
using notmuch with Emacs" section, but more general things like James'
script and other people's scripts really should be put up there so
people who are new can figure out how to get started faster.

So this is just a call out to try and encourage people to put these
useful things that they have sent out to the list up onto the wiki! Most
people don't read all the past archives of a list when they first join,
but do check out the website for info on how to get going. I'm not
saying don't send things to the list either, just don't let the list be
the sink where these great tips go to die.

micah


0. indirectly I believe am also responsible, through 3rd party
evangelizing, for James entering the scene as well, and I'm happy about
that because I have been quite pleased with his enhancements, thanks
james!. now I just need to buy him a drink and talk him into fixing the
openpgp bits ;)
-- 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/20100226/26c6d986/attachment.pgp>

[notmuch] What's so great about notmuch?

It seems clear that I'll have some opportunities to present notmuch to
various audiences at varying levels of formality. Since notmuch is
already a bigger project than me, I'd love to get some ideas from others
about what you think are the "big ideas" in notmuch.

So here are a few different phrasings of what's basically the same
question. And I'd love to hear some brief opinions on any one of these,
(or similar topics):

   What's your favorite thing about notmuch?

   What about notmuch makes it distinctive compared to other email
   programs?

   If someone were to implement a new email system from scratch, but
   capturing the "ideas" of notmuch, what would it have to have?

I'll put some of my own answers together in a reply as well.

And obviously, we should probably put a wiki page together to give a
good exposition on the "philosphy of notmuch" (once we can figure out
what that is).

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

[notmuch] Thoughts on not seeing messages I can't deal with (yet, or now, or here...)

[This mail started as some off-topic rambling in my reply to the
notmuch-reply script. So that's why it starts on one topic and ends
somewhere else entirely.]

I'm currently avoiding any locking failures with notmuch commands by
running "notmuch new" manually, (rather than from a cron job). And it
occurs to me that running "notmuch new" manually has a certain
benefit---it allows me to bring in a chunk of mail, and then process all
of that (either by replying, or setting aside to a particular project or
"todo" tag, etc.) without getting distracted by other mail coming in.

It almost makes me want to just run "notmuch new" something like once
per day.

But then, of course, there are times where there are important messages
I need to get to quickly, or fast-moving threads where I need to reply
several times throughout the day.

But I do have particular mailing lists that I don't want to read more
than once a day, for instance. If I wait until I have about a days worth
of mail in those lists, then I can deal with them very efficiently,
(just scan all the subjects, read a thread or two and the "* -inbox" the
rest). This gets a lot less efficient if I have to deal with those lists
on a regular basis throughout the day, (particularly before we have
support for "muted" threads).

So I'd like to be able to deal with important messages as they come in,
but postpone bulk stuff.

But I also notice that there's a bad tendency I have if I try to do this
postponing manually. Mail starts collecting in one of these bulk-list
folders, and I start training myself to ignore the folder, then it gets
huge, (which discourages me even more from looking at it, etc.). [*]

So I want better support from notmuch to tell me what things deserve my
attention, so that I can avoid training myself to ignore things. I think
what I want here is the ability to set a threshold on a particular
folder based on number of messages or date. Something like: "Don't show
me this folder at all until it has more than X messages or until the
oldest message is at least Y hours old".

[*] A similar, (but more dangerous), problem occurs with manually
postponing things into a "todo" folder. If I just added a bunch of
things to my todo folder then I have a tendency to think, "I don't need
to look at that---that's got a bunch of things I just decided to
postpone". But then I forget that I put some things in there previously
that really need my attention now.

I know that what I really want instead of "todo" is a way to express the
reason I'm postponing a message. There's probably some resource I'm
missing that I need before I can deal with it. Perhaps that's:

  * I can't decide on this until I'm with co-workers and can talk about
this.

  * I can't resolve this until I'm at the office with the right hardware
to test.

  * I need to remember to do something with this when I'm at home.

  * I need a nice block of "discretionary time" to be able to give this
topic the attention I want to.

  * I need to look at this message again on this Saturday.

So what I really want to do is to tag things based on those criteria,
("office", "magic-hardware", "home", "discretionary", "2010-02-27"),
which I can at least do now.

But what I'm currently missing is a way for the folders based on these
tags to only appear at the right times, (when the resource is
available).

When the messages appear at the wrong times, it just trains me to ignore
things, and that's when I start forgetting things and let things fall
through.

No concrete proposal here, but just some musings on the kinds of issues
I'd really like to be exploring with notmuch, (once we can get past all
these little things like maildir flags, keybindings, failed HTML
rendering, missing FCC support, etc. etc. etc.).

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

[notmuch] [PATCH] Add shell script notmuch-retry

On Fri, 26 Feb 2010 07:53:29 -0500, James Vasile  
wrote:
> Maybe this retry loop should be put in notmuch itself?

Perhaps it should. I've even imagined something that would queue a
request into a daemon if the database isn't currently available.

But of course there are issues about whether the caller would want to
know about the locking error, (or might actually need to block until the
operation is complete). So I'm not sure about the right answer here.

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

[notmuch] A few patches

Hi Mike, welcome to notmuch!

On Thu, 21 Jan 2010 15:42:00 -0500 (EST), "Mike Kelly"  
wrote:
> I've got a few patches available in my notmuch repo:
>
>   http://git.pioto.org/gitweb/notmuch.git

Thanks for sharing these! I really like how the distributed nature of
git makes it so easy for us to mix and match patches like this.

> The 'noarg-count' branch makes `notmuch count` without any argument
> simply return the total number of messages in the database. This seems
> like it could be useful.

The functionality does seem very useful, but I'd like it to be a tiny
bit more general. There are cases where it would be useful to return all
results from any the various search-based commands, (notmuch search,
notmuch show, etc.). But I think it would be unkind if "notmuch show"
with no arguments spewed the entire contents of the mail collection at
the user.

So what I would like to see is that any of these commands given no
argument would instead give some helpful information---I think it should
be either the information currently available in "notmuch help
search-terms" or perhaps an abbreviated version of it.

Then, I'd like to have a new, succinct and explicit syntax to indicate a
search that should return all results. For example, we could use '*' but
that has the issue that it would need escaping from the shell. But the
idea would be to be able to run:

notmuch count '*'

to count everything. Anyone have a better option for what the
give-me-everything syntax should be?

> The 'new-unread' branch makes `notmuch new` only tag messages as
> 'unread' if they don't have a maildir 'seen' flag. This shouldn't affect
> anyones existing database, but should make initial imports for people
> migrating from other mail setups (like me) go much better.

One of the longest-standing items on our TODO list has been to provide
proper support for these maildir flags. In fact, look at the top of our
current TODO file:

Fix the things that are causing the most pain to new users
--
1. A new import is tagging all messages as "inbox" -- total pain

There are various proposals and patches on the list already, and we need
to figure out exactly what we want, (it's easy to get bogged down once
we think about handling changes to these flags later, whether notmuch
should changes the maildir flag when the tags are changed,
etc.). Perhaps just starting with a patch like yours and going from
there is the right plan.

Would you please send it to the list so I've got a reminder about it
here, and can reply with any review?

Thanks,

-Carl

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

[notmuch] Initial tagging

2010-02-26 Thread Jameson Rollins

On Fri, 26 Feb 2010 01:13:52 -0800, Carl Worth  wrote:
> > Saved searches is a very good idea.  I look forward to it.
> 
> Me too! :-)

Isn't that what "folders" are?  At least that's what they seem to me.  I
define a specific search, give it a name, and save it as a folder.

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/20100226/1c1238ac/attachment.pgp>

[notmuch] [PATCH] notmuch.el: add a hook to notmuch-reply

2010-02-26 Thread da...@tethera.net

From: David Bremner 

This patch introduces a variable notmuch-reply-hook and calls it using
run-hooks. This allows people to easily override the header setup and
so forth done by notmuch.
---

This is my solution to trying to rationalize the headers of 'm' versus 'r';
now I just call the same hook in both cases. There is actually only 2 lines 
of code added; the rest is a defcustom, docstrings and so on.

 notmuch.el |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6482170..f47f134 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -471,6 +471,8 @@ buffer."
   (progn
(insert "--text follows this line--")
(forward-line)))
+  (save-excursion
+(run-hooks 'notmuch-reply-hook))
   (message-mode))

 (defun notmuch-show-reply ()
@@ -1107,6 +1109,14 @@ All currently available key bindings:
   :options '(hl-line-mode)
   :group 'notmuch)

+(defcustom notmuch-reply-hook nil
+  "List of functions to call when replying to a message.
+Run after the buffer content is returned from notmuch and before
+handing off to message mode. The function `notmuch-reply' runs
+this hook."
+  :type 'hook
+  :group 'notmuch)
+
 (defun notmuch-show-do-stash (text)
 (kill-new text)
 (message (concat "Saved: " text)))
-- 
1.6.5

[notmuch] [PATCH] Add shell script notmuch-retry

It occurs to me that having generic ability to tell notmuch to retry
until the DB isn't locked might useful.  So I put the functionality in a
script that can sit between notmuch and various clients.  It will
simplify my emacs setup, and improve it since emacs's handling of
asynchronous processes isn't great.

This script calls notmuch and passes on all commandline arguments.  If
DB is locked, keep trying notmuch until the DB isn't locked.  Notmuch's
stdout and stderr go to stdout and stderr.  Returns notmuch's return
code.

Maybe this retry loop should be put in notmuch itself?

---
 notmuch-retry |   51 +++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100755 notmuch-retry

diff --git a/notmuch-retry b/notmuch-retry
new file mode 100755
index 000..2d7fcbc
--- /dev/null
+++ b/notmuch-retry
@@ -0,0 +1,51 @@
+#!/bin/bash
+#
+# notmuch-retry --- call notmuch and retry if DB is locked
+#
+# Calls notmuch and passes on all commandline arguments.  If DB is
+# locked, keep trying notmuch until the DB isn't locked.  Notmuch's
+# stdout and stderr go to stdout and stderr.  Returns notmuch's return
+# code.
+#
+# Copyright 2010 James Vasile
+#
+# This 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.
+#
+# This software 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 this software.  If not, see
+# .
+#
+# Authors: James Vasile 
+
+bin=`which notmuch`
+
+notmuch_retry () {
+regex="already locked"
+while [ 1 -gt 0 ]; do
+   $bin $@ 2>$err
+   retcode=$?
+   result=$(<$err)
+   if [[ $result =~ $regex ]]; then
+   sleep 2.5
+   else
+   if [ -n "$result" ]; then
+   echo $result >&2
+   fi
+   return $retcode
+   fi
+done
+}
+
+err=$(mktemp)
+notmuch_retry $@
+retcode=$?
+rm $err
+exit $retcode
-- 
1.6.3.3

[notmuch] Initial tagging

> Sometimes I manually override a rule-based tag.  If automatic tagging
> operated on old messages, overrides could be superseded.  When I add
> automatic tag rules, I first execute them manually and globally from the
> command line.

Right. With my global automatic tags, I don't want to be able to
override them, (and the fact that I *can* by adding/removing tags is a
bug---since, as you point out, the next run of my script will destroy my
changes). That's one of the reasons I want to switch to saved searches
for my own use of automatic tags.

Meanwhile, Martin has talked about having some machine-learning
algorithm apply tags, and have it notice when the user adds/removes
for feedback to improve its learning. So that kind of use case is
something that definitely isn't covered by saved searches.

> > To do my "global" searches quickly, I do a similar subsetting, but it's
> > much simpler. If I'm adding the "notmuch" tag I do "and not
> > tag:notmuch". We've even had the proposal of making "notmuch tag" do
> > that automatically.
> 
> That sounds like a good idea.  What happened with that proposal?

Like many other proposals, it's simply waiting for someone to implement
it.

> Saved searches is a very good idea.  I look forward to it.

Me too! :-)

-Carl

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

Re: [notmuch] Initial tagging

 Sometimes I manually override a rule-based tag.  If automatic tagging
 operated on old messages, overrides could be superseded.  When I add
 automatic tag rules, I first execute them manually and globally from the
 command line.

Right. With my global automatic tags, I don't want to be able to
override them, (and the fact that I *can* by adding/removing tags is a
bug---since, as you point out, the next run of my script will destroy my
changes). That's one of the reasons I want to switch to saved searches
for my own use of automatic tags.

Meanwhile, Martin has talked about having some machine-learning
algorithm apply tags, and have it notice when the user adds/removes
for feedback to improve its learning. So that kind of use case is
something that definitely isn't covered by saved searches.

  To do my global searches quickly, I do a similar subsetting, but it's
  much simpler. If I'm adding the notmuch tag I do and not
  tag:notmuch. We've even had the proposal of making notmuch tag do
  that automatically.
 
 That sounds like a good idea.  What happened with that proposal?

Like many other proposals, it's simply waiting for someone to implement
it.

 Saved searches is a very good idea.  I look forward to it.

Me too! :-)

-Carl



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

[notmuch] [PATCH] notmuch.el: add a hook to notmuch-reply

2010-02-26 Thread david

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

This patch introduces a variable notmuch-reply-hook and calls it using
run-hooks. This allows people to easily override the header setup and
so forth done by notmuch.
---

This is my solution to trying to rationalize the headers of 'm' versus 'r';
now I just call the same hook in both cases. There is actually only 2 lines 
of code added; the rest is a defcustom, docstrings and so on.

 notmuch.el |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6482170..f47f134 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -471,6 +471,8 @@ buffer.
   (progn
(insert --text follows this line--)
(forward-line)))
+  (save-excursion
+(run-hooks 'notmuch-reply-hook))
   (message-mode))
 
 (defun notmuch-show-reply ()
@@ -1107,6 +1109,14 @@ All currently available key bindings:
   :options '(hl-line-mode)
   :group 'notmuch)
 
+(defcustom notmuch-reply-hook nil
+  List of functions to call when replying to a message.
+Run after the buffer content is returned from notmuch and before
+handing off to message mode. The function `notmuch-reply' runs
+this hook.
+  :type 'hook
+  :group 'notmuch)
+
 (defun notmuch-show-do-stash (text)
 (kill-new text)
 (message (concat Saved:  text)))
-- 
1.6.5

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

[notmuch] [PATCH] Add shell script notmuch-retry

It occurs to me that having generic ability to tell notmuch to retry
until the DB isn't locked might useful.  So I put the functionality in a
script that can sit between notmuch and various clients.  It will
simplify my emacs setup, and improve it since emacs's handling of
asynchronous processes isn't great.

This script calls notmuch and passes on all commandline arguments.  If
DB is locked, keep trying notmuch until the DB isn't locked.  Notmuch's
stdout and stderr go to stdout and stderr.  Returns notmuch's return
code.

Maybe this retry loop should be put in notmuch itself?

---
 notmuch-retry |   51 +++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100755 notmuch-retry

diff --git a/notmuch-retry b/notmuch-retry
new file mode 100755
index 000..2d7fcbc
--- /dev/null
+++ b/notmuch-retry
@@ -0,0 +1,51 @@
+#!/bin/bash
+#
+# notmuch-retry --- call notmuch and retry if DB is locked
+#
+# Calls notmuch and passes on all commandline arguments.  If DB is
+# locked, keep trying notmuch until the DB isn't locked.  Notmuch's
+# stdout and stderr go to stdout and stderr.  Returns notmuch's return
+# code.
+#
+# Copyright 2010 James Vasile
+#
+# This 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.
+#
+# This software 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 this software.  If not, see
+# http://www.gnu.org/licenses/.
+#
+# Authors: James Vasile ja...@hackervisions.org
+
+bin=`which notmuch`
+
+notmuch_retry () {
+regex=already locked
+while [ 1 -gt 0 ]; do
+   $bin $@ 2$err
+   retcode=$?
+   result=$($err)
+   if [[ $result =~ $regex ]]; then
+   sleep 2.5
+   else
+   if [ -n $result ]; then
+   echo $result 2
+   fi
+   return $retcode
+   fi
+done
+}
+
+err=$(mktemp)
+notmuch_retry $@
+retcode=$?
+rm $err
+exit $retcode
-- 
1.6.3.3

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

Re: [notmuch] Initial tagging

2010-02-26 Thread martin f krafft

also sprach Jameson Rollins jroll...@finestructure.net [2010.02.26.1600 
+0100]:
  Me too! :-)
 
 Isn't that what folders are?  At least that's what they seem to me.  I
 define a specific search, give it a name, and save it as a folder.

There's a 1:∞ relationship between folders and messages. I might
want a message associated with multiple contexts.

-- 
 .''`.   martin f. krafft madd...@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
you know you're a hopeless geek when you misspell 'date' as 'data'
   -- branden robinson


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Initial tagging

2010-02-26 Thread micah anderson

On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile ja...@hackervisions.org 
wrote:

 I'm curious as to what people are doing in this regard.

I am pretty good at evangelizing notmuch and converted another
person[0]... in doing so I realized I had to walk through a few issues
to get them started. 

The initial documentation for notmuch is really great, but the other
magical bits are missing, like holy cow all my email is in my inbox
now!; how do I deal with folders?; do i run notmuch new every
time?; do you auto-tag things?; how do you deal with attachments?;
how do you read encrypted email? etc. etc. all of these getting
started with notmuch things... including the script that James just
posted, the getmail tagging stuff that was posted a little while back,
etc. 

This stuff should go up on the wiki! There is a Tips and Tricks for
using notmuch with Emacs section, but more general things like James'
script and other people's scripts really should be put up there so
people who are new can figure out how to get started faster.

So this is just a call out to try and encourage people to put these
useful things that they have sent out to the list up onto the wiki! Most
people don't read all the past archives of a list when they first join,
but do check out the website for info on how to get going. I'm not
saying don't send things to the list either, just don't let the list be
the sink where these great tips go to die.

micah


0. indirectly I believe am also responsible, through 3rd party
evangelizing, for James entering the scene as well, and I'm happy about
that because I have been quite pleased with his enhancements, thanks
james!. now I just need to buy him a drink and talk him into fixing the
openpgp bits ;)


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

Re: [notmuch] A few patches

Hi Mike, welcome to notmuch!

On Thu, 21 Jan 2010 15:42:00 -0500 (EST), Mike Kelly pi...@pioto.org wrote:
 I've got a few patches available in my notmuch repo:

   http://git.pioto.org/gitweb/notmuch.git

Thanks for sharing these! I really like how the distributed nature of
git makes it so easy for us to mix and match patches like this.

 The 'noarg-count' branch makes `notmuch count` without any argument
 simply return the total number of messages in the database. This seems
 like it could be useful.

The functionality does seem very useful, but I'd like it to be a tiny
bit more general. There are cases where it would be useful to return all
results from any the various search-based commands, (notmuch search,
notmuch show, etc.). But I think it would be unkind if notmuch show
with no arguments spewed the entire contents of the mail collection at
the user.

So what I would like to see is that any of these commands given no
argument would instead give some helpful information---I think it should
be either the information currently available in notmuch help
search-terms or perhaps an abbreviated version of it.

Then, I'd like to have a new, succinct and explicit syntax to indicate a
search that should return all results. For example, we could use '*' but
that has the issue that it would need escaping from the shell. But the
idea would be to be able to run:

notmuch count '*'

to count everything. Anyone have a better option for what the
give-me-everything syntax should be?

 The 'new-unread' branch makes `notmuch new` only tag messages as
 'unread' if they don't have a maildir 'seen' flag. This shouldn't affect
 anyones existing database, but should make initial imports for people
 migrating from other mail setups (like me) go much better.

One of the longest-standing items on our TODO list has been to provide
proper support for these maildir flags. In fact, look at the top of our
current TODO file:

Fix the things that are causing the most pain to new users
--
1. A new import is tagging all messages as inbox -- total pain

There are various proposals and patches on the list already, and we need
to figure out exactly what we want, (it's easy to get bogged down once
we think about handling changes to these flags later, whether notmuch
should changes the maildir flag when the tags are changed,
etc.). Perhaps just starting with a patch like yours and going from
there is the right plan.

Would you please send it to the list so I've got a reminder about it
here, and can reply with any review?

Thanks,

-Carl




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

[notmuch] [PATCH 1/2] Initial support for maildir flags.

When adding new messages, if they have the 'S' (seen) flag, do not add
them to the 'unread' tag.
---
 lib/message.cc |   25 +
 lib/notmuch.h  |5 +
 notmuch-new.c  |3 ++-
 3 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index f0e905b..61c9cc3 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -516,6 +516,31 @@ notmuch_message_set_flag (notmuch_message_t *message,
message-flags = ~(1  flag);
 }
 
+notmuch_bool_t
+notmuch_message_md_flag (notmuch_message_t *message,
+const char flag)
+{
+const char *filename;
+const char *p;
+
+filename = notmuch_message_get_filename (message);
+
+p = strstr (filename, :2,);
+if (p == NULL) {
+/* Not a valid maildir filename */
+return FALSE;
+}
+
+for (p += 3; *p != '\0'; p++) {
+if (*p == flag) {
+return TRUE;
+}
+}
+
+return FALSE;
+}
+
+
 time_t
 notmuch_message_get_date (notmuch_message_t *message)
 {
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 15c9db4..db9e917 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -753,6 +753,11 @@ void
 notmuch_message_set_flag (notmuch_message_t *message,
  notmuch_message_flag_t flag, notmuch_bool_t value);
 
+/* See if a given maildir flag is set, based on the message's filename. */
+notmuch_bool_t
+notmuch_message_md_flag (notmuch_message_t *message,
+const char flag);
+
 /* Get the date of 'message' as a time_t value.
  *
  * For the original textual representation of the Date header from the
diff --git a/notmuch-new.c b/notmuch-new.c
index b740ee2..6d62f3f 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -97,7 +97,8 @@ static void
 tag_inbox_and_unread (notmuch_message_t *message)
 {
 notmuch_message_add_tag (message, inbox);
-notmuch_message_add_tag (message, unread);
+if (! notmuch_message_md_flag(message, 'S'))
+notmuch_message_add_tag (message, unread);
 }
 
 static void
-- 
1.7.0

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

Re: [notmuch] [PATCH] Add shell script notmuch-retry

On Fri, 26 Feb 2010 07:53:29 -0500, James Vasile ja...@hackervisions.org 
wrote:
 Maybe this retry loop should be put in notmuch itself?

Perhaps it should. I've even imagined something that would queue a
request into a daemon if the database isn't currently available.

But of course there are issues about whether the caller would want to
know about the locking error, (or might actually need to block until the
operation is complete). So I'm not sure about the right answer here.

-Carl


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

[notmuch] Thoughts on not seeing messages I can't deal with (yet, or now, or here...)

[This mail started as some off-topic rambling in my reply to the
notmuch-reply script. So that's why it starts on one topic and ends
somewhere else entirely.]

I'm currently avoiding any locking failures with notmuch commands by
running notmuch new manually, (rather than from a cron job). And it
occurs to me that running notmuch new manually has a certain
benefit---it allows me to bring in a chunk of mail, and then process all
of that (either by replying, or setting aside to a particular project or
todo tag, etc.) without getting distracted by other mail coming in.

It almost makes me want to just run notmuch new something like once
per day.

But then, of course, there are times where there are important messages
I need to get to quickly, or fast-moving threads where I need to reply
several times throughout the day.

But I do have particular mailing lists that I don't want to read more
than once a day, for instance. If I wait until I have about a days worth
of mail in those lists, then I can deal with them very efficiently,
(just scan all the subjects, read a thread or two and the * -inbox the
rest). This gets a lot less efficient if I have to deal with those lists
on a regular basis throughout the day, (particularly before we have
support for muted threads).

So I'd like to be able to deal with important messages as they come in,
but postpone bulk stuff.

But I also notice that there's a bad tendency I have if I try to do this
postponing manually. Mail starts collecting in one of these bulk-list
folders, and I start training myself to ignore the folder, then it gets
huge, (which discourages me even more from looking at it, etc.). [*]

So I want better support from notmuch to tell me what things deserve my
attention, so that I can avoid training myself to ignore things. I think
what I want here is the ability to set a threshold on a particular
folder based on number of messages or date. Something like: Don't show
me this folder at all until it has more than X messages or until the
oldest message is at least Y hours old.

[*] A similar, (but more dangerous), problem occurs with manually
postponing things into a todo folder. If I just added a bunch of
things to my todo folder then I have a tendency to think, I don't need
to look at that---that's got a bunch of things I just decided to
postpone. But then I forget that I put some things in there previously
that really need my attention now.

I know that what I really want instead of todo is a way to express the
reason I'm postponing a message. There's probably some resource I'm
missing that I need before I can deal with it. Perhaps that's:

  * I can't decide on this until I'm with co-workers and can talk about
this.

  * I can't resolve this until I'm at the office with the right hardware
to test.

  * I need to remember to do something with this when I'm at home.

  * I need a nice block of discretionary time to be able to give this
topic the attention I want to.

  * I need to look at this message again on this Saturday.

So what I really want to do is to tag things based on those criteria,
(office, magic-hardware, home, discretionary, 2010-02-27),
which I can at least do now.

But what I'm currently missing is a way for the folders based on these
tags to only appear at the right times, (when the resource is
available).

When the messages appear at the wrong times, it just trains me to ignore
things, and that's when I start forgetting things and let things fall
through.

No concrete proposal here, but just some musings on the kinds of issues
I'd really like to be exploring with notmuch, (once we can get past all
these little things like maildir flags, keybindings, failed HTML
rendering, missing FCC support, etc. etc. etc.).

-Carl


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

[notmuch] What's so great about notmuch?

It seems clear that I'll have some opportunities to present notmuch to
various audiences at varying levels of formality. Since notmuch is
already a bigger project than me, I'd love to get some ideas from others
about what you think are the big ideas in notmuch.

So here are a few different phrasings of what's basically the same
question. And I'd love to hear some brief opinions on any one of these,
(or similar topics):

   What's your favorite thing about notmuch?

   What about notmuch makes it distinctive compared to other email
   programs?

   If someone were to implement a new email system from scratch, but
   capturing the ideas of notmuch, what would it have to have?

I'll put some of my own answers together in a reply as well.

And obviously, we should probably put a wiki page together to give a
good exposition on the philosphy of notmuch (once we can figure out
what that is).

-Carl


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

[notmuch] [PATCH v2 3/4] Configure the database separately from mail store

2010-02-26 Thread David Benjamin

Signed-off-by: David Benjamin david...@mit.edu
---

 Apparently I never ran the last-minute tweak I did to
 notmuch_config_set_database_path. Oops. Oh well, here's the trivially fixed
 version.

 notmuch-client.h |7 ++
 notmuch-config.c |   62 --
 notmuch-new.c|   14 ---
 3 files changed, 58 insertions(+), 25 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 1a676d2..010fdc7 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -148,6 +148,13 @@ void
 notmuch_config_set_database_path (notmuch_config_t *config,
  const char *database_path);
 
+const char *
+notmuch_config_get_database_notmuch_path (notmuch_config_t *config);
+
+void
+notmuch_config_set_database_notmuch_path (notmuch_config_t *config,
+ const char *database_notmuch_path);
+
 notmuch_database_t *
 notmuch_config_open_database (notmuch_config_t *config,
  notmuch_database_mode_t mode);
diff --git a/notmuch-config.c b/notmuch-config.c
index 58a28b1..ccae35d 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -58,6 +58,7 @@ struct _notmuch_config {
 GKeyFile *key_file;
 
 char *database_path;
+char *database_notmuch_path;
 char *user_name;
 char *user_primary_email;
 char **user_other_email;
@@ -151,6 +152,8 @@ get_username_from_passwd_file (void *ctx)
  *
  * database_path:  $HOME/mail
  *
+ * database_notmuch_path:  database_path/.notmuch
+ *
  * user_name:  From /etc/passwd
  *
  * user_primary_mail:  $EMAIL variable if set, otherwise
@@ -195,6 +198,7 @@ notmuch_config_open (void *ctx,
 config-key_file = g_key_file_new ();
 
 config-database_path = NULL;
+config-database_notmuch_path = NULL;
 config-user_name = NULL;
 config-user_primary_email = NULL;
 config-user_other_email = NULL;
@@ -351,6 +355,45 @@ notmuch_config_set_database_path (notmuch_config_t *config,
 
 talloc_free (config-database_path);
 config-database_path = NULL;
+/* In case this path is dynamically generated */
+talloc_free (config-database_notmuch_path);
+config-database_notmuch_path = NULL;
+}
+
+const char *
+notmuch_config_get_database_notmuch_path (notmuch_config_t *config)
+{
+const char *path;
+char *notmuch_path;
+
+if (config-database_notmuch_path == NULL) {
+   notmuch_path = g_key_file_get_string (config-key_file,
+ database, notmuch_path, NULL);
+   if (notmuch_path) {
+   config-database_notmuch_path = talloc_strdup (config, 
notmuch_path);
+   free (notmuch_path);
+   } else {
+   path = notmuch_config_get_database_path (config);
+   if (path != NULL) {
+   notmuch_path = talloc_asprintf (config, %s/%s,
+   path, .notmuch);
+   config-database_notmuch_path = notmuch_path;
+   }
+   }
+}
+
+return config-database_notmuch_path;
+}
+
+void
+notmuch_config_set_database_notmuch_path (notmuch_config_t *config,
+ const char *database_notmuch_path)
+{
+g_key_file_set_string (config-key_file,
+  database, notmuch_path, database_notmuch_path);
+
+talloc_free (config-database_notmuch_path);
+config-database_notmuch_path = NULL;
 }
 
 notmuch_database_t *
@@ -358,26 +401,13 @@ notmuch_config_open_database (notmuch_config_t *config,
  notmuch_database_mode_t mode)
 {
 const char *path = NULL;
-char *db_path = NULL;
+const char *notmuch_path = NULL;
 notmuch_database_t *notmuch = NULL;
 
 path = notmuch_config_get_database_path (config);
-if (path == NULL) {
-   fprintf (stderr, Error: Cannot create a database for a NULL path.\n);
-   goto DONE;
-}
-
-if (asprintf (db_path, %s/%s, path, .notmuch) == -1) {
-   db_path = NULL;
-   fprintf (stderr, Out of memory\n);
-   goto DONE;
-}
-
-notmuch = notmuch_database_open (path, db_path, mode);
+notmuch_path = notmuch_config_get_database_notmuch_path (config);
 
-DONE:
-if (db_path)
-   free(db_path);
+notmuch = notmuch_database_open (path, notmuch_path, mode);
 
 return notmuch;
 }
diff --git a/notmuch-new.c b/notmuch-new.c
index d24dab9..d36edd5 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -713,7 +713,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
 int ret = 0;
 struct stat st;
 const char *db_path;
-char *dot_notmuch_path;
+const char *notmuch_path;
 struct sigaction action;
 _filename_node_t *f;
 int renamed_files, removed_files;
@@ -737,10 +737,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
return 1;
 
 db_path = notmuch_config_get_database_path (config);
+notmuch_path =

Re: [notmuch] Thoughts on not seeing messages I can't deal with (yet, or now, or here...)

2010-02-26 Thread Mark Anderson

Carl,

There's a post from a while ago about using GTD on Remember The Milk.

Remember the Milk as described here is mainly a todo manager, but the
saved search (as a list of todo tasks that match the criterion) is
what's being utilized here that makes me think so much of notmuch.

This seems to capture some of the things that you want to see, since you
are trying to manage action items which happen to live in mail bodies.

http://blog.rememberthemilk.com/2008/05/guest-post-advanced-gtd-with-remember-the-milk/

apparently another post has expired on the topic, with some focus on
contexts:

http://web.archive.org/web/20080331121051/http://www.geektronica.com/2007-01-15-gtd-with-rtm-getting-things-done-with-remember-the-milk

The main tool in use here is a viewport on the collection of things that
might need to be reviewed. RTM tabs (which are saved searches) which you
have designed to be the contexts you might be executing in, in this
case.

I know this is related pretty heavily to what you are looking for, but
how to bring this about specifically, that's going to be up to you.

Enjoy,
-Mark

On Fri, 26 Feb 2010 14:00:06 -0600, Carl Worth cwo...@cworth.org wrote:
[This mail started as some off-topic rambling in my reply to the
notmuch-reply script. So that's why it starts on one topic and ends
somewhere else entirely.]

I'm currently avoiding any locking failures with notmuch commands by
running notmuch new manually, (rather than from a cron job). And it
occurs to me that running notmuch new manually has a certain
benefit---it allows me to bring in a chunk of mail, and then process all
of that (either by replying, or setting aside to a particular project or
todo tag, etc.) without getting distracted by other mail coming in.

It almost makes me want to just run notmuch new something like once
per day.

But then, of course, there are times where there are important messages
I need to get to quickly, or fast-moving threads where I need to reply
several times throughout the day.

But I do have particular mailing lists that I don't want to read more
than once a day, for instance. If I wait until I have about a days worth
of mail in those lists, then I can deal with them very efficiently,
(just scan all the subjects, read a thread or two and the * -inbox the
rest). This gets a lot less efficient if I have to deal with those lists
on a regular basis throughout the day, (particularly before we have
support for muted threads).

So I'd like to be able to deal with important messages as they come in,
but postpone bulk stuff.

But I also notice that there's a bad tendency I have if I try to do this
postponing manually. Mail starts collecting in one of these bulk-list
folders, and I start training myself to ignore the folder, then it gets
huge, (which discourages me even more from looking at it, etc.). [*]

So I want better support from notmuch to tell me what things deserve my
attention, so that I can avoid training myself to ignore things. I think
what I want here is the ability to set a threshold on a particular
folder based on number of messages or date. Something like: Don't show
me this folder at all until it has more than X messages or until the
oldest message is at least Y hours old.

[*] A similar, (but more dangerous), problem occurs with manually
postponing things into a todo folder. If I just added a bunch of
things to my todo folder then I have a tendency to think, I don't need
to look at that---that's got a bunch of things I just decided to
postpone. But then I forget that I put some things in there previously
that really need my attention now.

I know that what I really want instead of todo is a way to express the
reason I'm postponing a message. There's probably some resource I'm
missing that I need before I can deal with it. Perhaps that's:

* I can't decide on this until I'm with co-workers and can talk about
this.

* I can't resolve this until I'm at the office with the right hardware
to test.

* I need to remember to do something with this when I'm at home.

* I need a nice block of discretionary time to be able to give this
topic the attention I want to.

* I need to look at this message again on this Saturday.

So what I really want to do is to tag things based on those criteria,
(office, magic-hardware, home, discretionary, 2010-02-27),
which I can at least do now.

But what I'm currently missing is a way for the folders based on these
tags to only appear at the right times, (when the resource is
available).

When the messages appear at the wrong times, it just trains me to ignore
things, and that's when I start forgetting things and let things fall
through.

No concrete proposal here, but just some musings on the kinds of issues
I'd really like to be exploring with notmuch, (once we can get past all
these little things like maildir flags, keybindings, failed HTML
rendering, missing FCC support,

Re: [notmuch] Initial tagging