notmuch-next branch
On Tue, 12 Oct 2010 16:19:35 -0700, Carl Worth wrote: > On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras gmail.com> wrote: > > I'm proposing to have notmuch-next branch, either on github or > > gitorious (please vote). > > I'd be glad to host something on notmuchmail.org too. > > I suppose I should just set that up... > +1 for carl just setting that up :) d
Re: notmuch-next branch
On Tue, 12 Oct 2010 16:19:35 -0700, Carl Worth wrote: > On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras > wrote: > > I'm proposing to have notmuch-next branch, either on github or > > gitorious (please vote). > > I'd be glad to host something on notmuchmail.org too. > > I suppose I should just set that up... > +1 for carl just setting that up :) d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-next branch
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras wrote: > I'm proposing to have notmuch-next branch, either on github or > gitorious (please vote). I'd be glad to host something on notmuchmail.org too. I suppose I should just set that up... -Carl pgp5KIeDjUuhO.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-next branch
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras wrote: > I'm proposing to have notmuch-next branch, either on github or > gitorious (please vote). I'd be glad to host something on notmuchmail.org too. I suppose I should just set that up... -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/20101012/579786a8/attachment.pgp>
[PATCH] Allow user to specify ignored directories
Hi list,
this is my first post. I found notmuch a couple of days ago and it works
great. However I wanted to be able to ignore certain directories (mostly
.git in my case) when "notmuch new" is running.
With this patch the user can provide a list of directories which are
ignored during the recursive search for new messages. An "ignore"
label in the "new" section of the configuration file is added for this
purpose to enable for example something like
[new]
ignore=.git;.notmuch;
tags=unread;inbox;
in the .notmuch-config file. Feel free to apply if you find it useful.
Andreas
---
notmuch-client.h |8 +++
notmuch-config.c | 57 +-
notmuch-new.c| 43 +++-
3 files changed, 93 insertions(+), 15 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 20be43b..9bc6ef1 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -191,6 +191,14 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
const char *new_tags[],
size_t length);
+const char **
+notmuch_config_get_new_ignore (notmuch_config_t *config,
+ size_t *length);
+void
+notmuch_config_set_new_ignore (notmuch_config_t *config,
+ const char *new_ignore[],
+ size_t length);
+
notmuch_bool_t
debugger_is_active (void);
diff --git a/notmuch-config.c b/notmuch-config.c
index cf30603..8841eaf 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -43,7 +43,10 @@ static const char new_config_comment[] =
" The following options are supported here:\n"
"\n"
"\ttagsA list (separated by ';') of the tags that will be\n"
-"\tadded to all messages incorporated by \"notmuch new\".\n";
+"\tadded to all messages incorporated by \"notmuch new\".\n"
+"\n"
+"\tignore A list (separated by ';') of directories that will not\n"
+"\tbe searched for messages by \"notmuch new\".\n";
static const char user_config_comment[] =
" User configuration\n"
@@ -72,6 +75,8 @@ struct _notmuch_config {
size_t user_other_email_length;
const char **new_tags;
size_t new_tags_length;
+const char **new_ignore;
+size_t new_ignore_length;
};
static int
@@ -221,6 +226,8 @@ notmuch_config_open (void *ctx,
config->user_other_email_length = 0;
config->new_tags = NULL;
config->new_tags_length = 0;
+config->new_ignore = NULL;
+config->new_ignore_length = 0;
if (! g_key_file_load_from_file (config->key_file,
config->filename,
@@ -313,6 +320,11 @@ notmuch_config_open (void *ctx,
notmuch_config_set_new_tags (config, tags, 2);
}
+if (notmuch_config_get_new_ignore (config, &tmp) == NULL) {
+const char *ignore[] = { ".notmuch" };
+ notmuch_config_set_new_ignore (config, ignore, 2);
+}
+
/* Whenever we know of configuration sections that don't appear in
* the configuration file, we add some comments to help the user
* understand what can be done. */
@@ -562,3 +574,46 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
config->new_tags = NULL;
}
+const char **
+notmuch_config_get_new_ignore (notmuch_config_t *config,
+ size_t *length)
+{
+char **ignore;
+size_t ignore_length;
+unsigned int i;
+
+if (config->new_ignore == NULL) {
+ ignore = g_key_file_get_string_list (config->key_file,
+ "new", "ignore",
+ &ignore_length, NULL);
+ if (ignore) {
+ config->new_ignore = talloc_size (config,
+ sizeof (char *) *
+ (ignore_length + 1));
+ for (i = 0; i < ignore_length; i++)
+ config->new_ignore[i] = talloc_strdup (config->new_ignore,
+ ignore[i]);
+ config->new_ignore[i] = NULL;
+
+ g_strfreev (ignore);
+
+ config->new_ignore_length = ignore_length;
+ }
+}
+
+*length = config->new_ignore_length;
+return config->new_ignore;
+}
+
+void
+notmuch_config_set_new_ignore (notmuch_config_t *config,
+ const char *new_ignore[],
+ size_t length)
+{
+g_key_file_set_string_list (config->key_file,
+ "new", "ignore",
+ new_ignore, length);
+
+talloc_free (config->new_ignore);
+config->new_ignore = NULL;
+}
diff --git a/notmuch-new.c b/notmuch-new.c
index 8818728..0e9c4d7 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -164,6 +164,23 @@ _entries_resemble_maildir (struct dirent **entries, int
count)
return 0;
}
+/* Check if use
First draft of logging functionality.
On Tue, 12 Oct 2010, David Bremner wrote: > On Tue, 12 Oct 2010 11:06:17 +0200, Michal Sojka > wrote: > > > I'm not sure whether implementing logging facility outside of notmuch > > library is a good thing. If somebody will use a third-party tool (such > > as python bindings) to manipulate his tags, they won't appear in the > > log. > > Yeah, thanks for that. I had been worrying about the same thing, but > your message helped clarify things for me. > > I guess log files should be opened in notmuch_database_open, and the > actual logging in this case could happen from notmuch_message_add_tag. > > From an atomicity point of view it might make more sense to store up a > list of log lines, and dump them all from _notmuch_message_sync. > One could attach a log buffer to a message, and flush that atomically > when syncing the message back to the database. Yes, the above sounds good to me. > In this context, it is a little more tedious to have more than one log > file. Why multiple log files? You may have the buffers for message logs in memory, right? Another thing to keep in mind is how it will behave with 'notmuch restore'. If do dump followed by resore you will have a very long log with no useful information in it. Some optimization may be employed here. Bye -Michal
notmuch-next branch
On 2010-10-11, Jesse Rosenthal wrote: > I don't know how official this has to be -- just an agreed upon branch > that people keep around next to their own personal one. Sebastian used > to have one that served this purpose a while back, I think. Well, it wasn't really semi-official or even blessed, I just announced it loudest :-). Meanwhile, I don't feel like maintaining my own notmuch anymore. I am still using it though and would love to follow someone's branch :-). Sebastian
First draft of logging functionality.
On Mon, 11 Oct 2010, david at tethera.net wrote: > The patches following this message are my first attempt at > implementing atomic logging for notmuch. The idea is that such logs > could be useful in synchronizing notmuch instances. > > Feedback of any kind is welcome. I'm particularly interested in > comments about the log format and performance. Hi David, I'm not sure whether implementing logging facility outside of notmuch library is a good thing. If somebody will use a third-party tool (such as python bindings) to manipulate his tags, they won't appear in the log. -Michal
opening attachment
On Sun, 10 Oct 2010, Daniel Goldin wrote: > > Setting my .mailcap doesn't seem to have any effect on how notmuch/emacs > handles attachments. Hitting return saves no matter what. I use 'v' key to display attachments. This shows all attachments at once with the programs configured in .mailcap. -Michal
First draft of logging functionality.
On Tue, 12 Oct 2010 13:38:42 +0200, Michal Sojka wrote: > > Why multiple log files? You may have the buffers for message logs in > memory, right? Well, maybe one log for tag operations, one for adding messages, etc... But it is easy enough to mark log entries by what they are. > > Another thing to keep in mind is how it will behave with 'notmuch > restore'. If do dump followed by resore you will have a very long log > with no useful information in it. Some optimization may be employed here. > Yes. This seems hard to optimize internally, but I was thinking of some "log compression" function that comes up with a minimal equivalent set of operations. I had in mind that this could be used to sync: concatenate all the logs, and then compress to a minimal set of operations. This is still not completely thought out... Another issue is that the buffer could get rather big during a restore, but this is presumably fixable by flushing it if it gets too large. All the best, David
First draft of logging functionality.
david at tethera.net writes: > The patches following this message are my first attempt at > implementing atomic logging for notmuch. The idea is that such logs > could be useful in synchronizing notmuch instances. For this to be completely safe, I suspect it may need to be adjusted to do write ahead logging or something similar. Otherwise operations could be lost. i.e. notmuch would atomically and safely write the intended (tag) operation to the log, then perform the tag. On startup, notmuch would need to scan the log to detect and apply operations that hadn't been fully completed (presumably due to a crash). More generally, while thinking about sync/logging a few days ago, I wondered about using sqlite. That would help with atomicity, rollback, synchronizing multiple readers/writers, etc. It might also make operations more efficient once we implement all the features we want. For example, with the log information in sqlite, a separate notmuch sync to another machine could be reading from the log (and with limitations, writing) in parallel with normal notmuch operations. Depending on how we decide to handle sync with multiple peers, the log may also need to track which peers have seen what, prune appropriately, etc. Of course sqlite may not be appropriate, and would require performance testing, etc., but we should probably think about the features we'll eventually want, and consider how much work they're likely to require with any given approach, regardless. Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
First draft of logging functionality.
On Tue, 12 Oct 2010 11:06:17 +0200, Michal Sojka wrote: > I'm not sure whether implementing logging facility outside of notmuch > library is a good thing. If somebody will use a third-party tool (such > as python bindings) to manipulate his tags, they won't appear in the > log. Yeah, thanks for that. I had been worrying about the same thing, but your message helped clarify things for me. I guess log files should be opened in notmuch_database_open, and the actual logging in this case could happen from notmuch_message_add_tag. >From an atomicity point of view it might make more sense to store up a list of log lines, and dump them all from _notmuch_message_sync. One could attach a log buffer to a message, and flush that atomically when syncing the message back to the database. In this context, it is a little more tedious to have more than one log file. d
Re: First draft of logging functionality.
da...@tethera.net writes: > The patches following this message are my first attempt at > implementing atomic logging for notmuch. The idea is that such logs > could be useful in synchronizing notmuch instances. For this to be completely safe, I suspect it may need to be adjusted to do write ahead logging or something similar. Otherwise operations could be lost. i.e. notmuch would atomically and safely write the intended (tag) operation to the log, then perform the tag. On startup, notmuch would need to scan the log to detect and apply operations that hadn't been fully completed (presumably due to a crash). More generally, while thinking about sync/logging a few days ago, I wondered about using sqlite. That would help with atomicity, rollback, synchronizing multiple readers/writers, etc. It might also make operations more efficient once we implement all the features we want. For example, with the log information in sqlite, a separate notmuch sync to another machine could be reading from the log (and with limitations, writing) in parallel with normal notmuch operations. Depending on how we decide to handle sync with multiple peers, the log may also need to track which peers have seen what, prune appropriately, etc. Of course sqlite may not be appropriate, and would require performance testing, etc., but we should probably think about the features we'll eventually want, and consider how much work they're likely to require with any given approach, regardless. Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: First draft of logging functionality.
On Tue, 12 Oct 2010 13:38:42 +0200, Michal Sojka wrote: > > Why multiple log files? You may have the buffers for message logs in > memory, right? Well, maybe one log for tag operations, one for adding messages, etc... But it is easy enough to mark log entries by what they are. > > Another thing to keep in mind is how it will behave with 'notmuch > restore'. If do dump followed by resore you will have a very long log > with no useful information in it. Some optimization may be employed here. > Yes. This seems hard to optimize internally, but I was thinking of some "log compression" function that comes up with a minimal equivalent set of operations. I had in mind that this could be used to sync: concatenate all the logs, and then compress to a minimal set of operations. This is still not completely thought out... Another issue is that the buffer could get rather big during a restore, but this is presumably fixable by flushing it if it gets too large. All the best, David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: First draft of logging functionality.
On Tue, 12 Oct 2010, David Bremner wrote: > On Tue, 12 Oct 2010 11:06:17 +0200, Michal Sojka wrote: > > > I'm not sure whether implementing logging facility outside of notmuch > > library is a good thing. If somebody will use a third-party tool (such > > as python bindings) to manipulate his tags, they won't appear in the > > log. > > Yeah, thanks for that. I had been worrying about the same thing, but > your message helped clarify things for me. > > I guess log files should be opened in notmuch_database_open, and the > actual logging in this case could happen from notmuch_message_add_tag. > > From an atomicity point of view it might make more sense to store up a > list of log lines, and dump them all from _notmuch_message_sync. > One could attach a log buffer to a message, and flush that atomically > when syncing the message back to the database. Yes, the above sounds good to me. > In this context, it is a little more tedious to have more than one log > file. Why multiple log files? You may have the buffers for message logs in memory, right? Another thing to keep in mind is how it will behave with 'notmuch restore'. If do dump followed by resore you will have a very long log with no useful information in it. Some optimization may be employed here. Bye -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: First draft of logging functionality.
On Tue, 12 Oct 2010 11:06:17 +0200, Michal Sojka wrote: > I'm not sure whether implementing logging facility outside of notmuch > library is a good thing. If somebody will use a third-party tool (such > as python bindings) to manipulate his tags, they won't appear in the > log. Yeah, thanks for that. I had been worrying about the same thing, but your message helped clarify things for me. I guess log files should be opened in notmuch_database_open, and the actual logging in this case could happen from notmuch_message_add_tag. >From an atomicity point of view it might make more sense to store up a list of log lines, and dump them all from _notmuch_message_sync. One could attach a log buffer to a message, and flush that atomically when syncing the message back to the database. In this context, it is a little more tedious to have more than one log file. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-next branch
On 2010-10-11, Jesse Rosenthal wrote: > I don't know how official this has to be -- just an agreed upon branch > that people keep around next to their own personal one. Sebastian used > to have one that served this purpose a while back, I think. Well, it wasn't really semi-official or even blessed, I just announced it loudest :-). Meanwhile, I don't feel like maintaining my own notmuch anymore. I am still using it though and would love to follow someone's branch :-). Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: First draft of logging functionality.
On Mon, 11 Oct 2010, da...@tethera.net wrote: > The patches following this message are my first attempt at > implementing atomic logging for notmuch. The idea is that such logs > could be useful in synchronizing notmuch instances. > > Feedback of any kind is welcome. I'm particularly interested in > comments about the log format and performance. Hi David, I'm not sure whether implementing logging facility outside of notmuch library is a good thing. If somebody will use a third-party tool (such as python bindings) to manipulate his tags, they won't appear in the log. -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: opening attachment
On Sun, 10 Oct 2010, Daniel Goldin wrote: > > Setting my .mailcap doesn't seem to have any effect on how notmuch/emacs > handles attachments. Hitting return saves no matter what. I use 'v' key to display attachments. This shows all attachments at once with the programs configured in .mailcap. -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-next branch
On Mon, Oct 11, 2010 at 10:01 PM, Jameson Rollins wrote: > On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras gmail.com> wrote: >> I think many people agree notmuch mainline has been rather slow. So >> I'm proposing to have notmuch-next branch, either on github or >> gitorious (please vote). >> >> More than one person should have write access to this repo, but some >> guidelines should be in place. I propose that patches should be >> signed-off-by at least another person in the mailing list before >> pushing. It would be nice if this is how the mainline branch works, >> but we don't need to wait for that to happen. We need to vote on who >> are the people to have write access. > > I think this generally sounds like a fine idea, but I don't see why we > need a single central repo that multiple people need access to. ?The > whole point of git is to allow for distributed development without need > for a central repo. And yet, git is hosted in a central repo. Different projects have different needs, and this one seems to need a place to cook up patches, having multiple committers there seems like it would work. Note that this wouldn't be the main repo, it would be preparing stage. > In this case, folks can just merge the patches they're interested in > into a "next" branch in their own personal repos, publish them where > ever they want, and then every body can just keep their "next" branches > synced with each other. ?As consensus is reached, the next release will > emerge. That might also work, it would be the first project I see doing that though. But what I worry is the ordering of the patches; we might have applied the same patches, but they would appear as totally different branches to a 3rd party, and of course merging other people's 'next' branches would create a total mess. There should be one repo that has the latest and greatest 'next' branch that everybody can rebase into, like the current 'master'. -- Felipe Contreras
