[notmuch] Quick thoughts on a notmuch daemon
On 14:27, Thu 03 Dec 09, Carl Worth wrote: > A simple solution would be a notmuch daemon that can accept commands on > stdin, (in basically the exact same form as the current notmuch > command-line interface). If the daemon does the job of periodically > incorporating new mail, then the only command necessary to solve (1) > above would be the tag command. I like the idea. I didn't liked to fork for each command, so I started to play with the library for create a UI. But with a demon like that I guess will be nicer to use it than to call directly to the library. Why use stdin? Why not sockets? With them at could be possible to use several concurrent clients with the same server. (I really love moc for play music, and one of its greatest features is that) -- Rub?n Poll?n | jabber:meskio at jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- No vamos a reivindicar nada, no vamos a pedir nada. Tomaremos, okuparemos. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091209/c77e2427/attachment.pgp>
[notmuch] [PATCH] Added regress option to tags iterator
On 14:21, Wed 09 Dec 09, Mark Anderson wrote: > advance/retreat Jeffrey already suggested retreat. I let you (English speakers) decide, my English level is not enough for it. -- Rub?n Poll?n | jabber:meskio at jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ?sta es la historia de una sociedad que se hunde y mientras cae se repite: hasta ahora todo va bien, hasta ahora todo va bien ... Pero lo importante no es la caida sino el aterrizaje. el odio -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091209/53ee0903/attachment-0001.pgp>
[notmuch] [PATCH] Added regress option to tags iterator
On 12:08, Wed 09 Dec 09, Carl Worth wrote: > On Wed, 9 Dec 2009 14:24:46 +0100, Ruben Pollan > wrote: > > Do you like to call them regress? Should I change that? > > I don't love the name, (since it's so close to the word "regression" > which has a totally different meaning in software context). But I also > don't have an immediate suggestion for an improved name yet either. Me neither, but as I don't have any better idea I just use regress. But we can try to come up with something better. > > > What about the functions notmuch_*_is_first? Is kind of reversed logic than > > notmuch_*_has_more, the last are true when is not reach the limit but the > > first ones are true when the limit is reached. But I think it make sense > > like > > that. > > I'd like a more symmetric API here. Anyone have a favorite set of names > for iterating a list in two directions? Yes, but actually are a bit different somehow. When you advance the last iterator you can reach is a non-valid (outside the list) iterator. When you 'regress' the iterator at the end is a valid iterator, I don't see the need on get outside of the list like with advance. So, maybe because of it have sense the functions notmuch_*_is_first. Anyway I really don't mind, one or other. To change it is trivial. It's harder to find a good pair of names. -- Rub?n Poll?n | jabber:meskio at jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- La felicidad no es hacer lo que deseas es desear lo que haces. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091209/687fa4f0/attachment.pgp>
[notmuch] [PATCH] Nuke the remainings of _notmuch_message_add_thread_id.
The function _notmuch_message_add_thread_id has been removed from the private interface of notmuch. There's no reason for one to keep a declaration of its prototype in the code base. Also, lets update a commentary that referenced that function and escaped from previous scrutiny. Signed-off-by: Fernando Carrijo --- lib/database.cc |9 - lib/notmuch-private.h |4 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 23ddd4a..b6c4d07 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -855,12 +855,11 @@ _notmuch_database_link_message_to_children (notmuch_database_t *notmuch, * * We first look at 'message_file' and its link-relevant headers * (References and In-Reply-To) for message IDs. We also look in the - * database for existing message that reference 'message'.p + * database for existing message that reference 'message'. * - * The end result is to call _notmuch_message_add_thread_id with one - * or more thread IDs to which this message belongs, (including - * generating a new thread ID if necessary if the message doesn't - * connect to any existing threads). + * The end result is to call _notmuch_message_ensure_thread_id which + * generates a new thread ID if the message doesn't connect to any + * existing threads. */ static notmuch_status_t _notmuch_database_link_message (notmuch_database_t *notmuch, diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h index 0c340a7..116f63d 100644 --- a/lib/notmuch-private.h +++ b/lib/notmuch-private.h @@ -194,10 +194,6 @@ _notmuch_message_set_filename (notmuch_message_t *message, const char *filename); void -_notmuch_message_add_thread_id (notmuch_message_t *message, - const char *thread_id); - -void _notmuch_message_ensure_thread_id (notmuch_message_t *message); void -- 1.5.6.3
[notmuch] Threading
I was wondering if there's a way in notmuch to group un-associated threads into a single thread. I have a bug tracking system that doesn't give me emails that thread naturally in notmuch. I wouldn't mind writing a filter that could help identify a thread id which should apply to a message, and suggest that to notmuch. Is there a method for this existing in notmuch yet? Mark Anderson
[notmuch] [PATCH] Added regress option to tags iterator
With the last 4 patches there is more or less all I wanted implemented. Do you like to call them regress? Should I change that? What about the functions notmuch_*_is_first? Is kind of reversed logic than notmuch_*_has_more, the last are true when is not reach the limit but the first ones are true when the limit is reached. But I think it make sense like that. On 14:10, Wed 09 Dec 09, Ruben Pollan wrote: > Added the functions notmuch_tags_regress and notmuch_tags_is_first to > notmuch library. With them is possible to iterate backwards on tags. > [...] -- Rub?n Poll?n | jabber:meskio at jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sed realistas, exigid lo imposible. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091209/f9234189/attachment.pgp>
[notmuch] [PATCH] Added regress option to tags iterator
Excerpts from Carl Worth's message of Wed Dec 09 13:08:43 -0700 2009: > On Wed, 9 Dec 2009 14:24:46 +0100, Ruben Pollan > wrote: > > Do you like to call them regress? Should I change that? > > I don't love the name, (since it's so close to the word "regression" > which has a totally different meaning in software context). But I also > don't have an immediate suggestion for an improved name yet either. > > > What about the functions notmuch_*_is_first? Is kind of reversed logic than > > notmuch_*_has_more, the last are true when is not reach the limit but the > > first ones are true when the limit is reached. But I think it make sense > > like > > that. > > I'd like a more symmetric API here. Anyone have a favorite set of names > for iterating a list in two directions? I like vocabulary games: fwd/bck forward/reverse next/prev advance/retreat inc/dec iter_fwd/iter_back earlier/later younger/older I think that changing has_more is going to be a requirement to come up with a consistent set of names. > > -Carl
[notmuch] [PATCH] Added regress option to tags iterator
Added the functions notmuch_tags_regress and notmuch_tags_is_first to
notmuch library. With them is possible to iterate backwards on tags.
* notmuch_tags_regress do the opposite than notmuch_tags_advance,
getting the tags iterator one position backwards.
* notmuch_tags_is_first return TRUE if the iterator is in the first
tag.
---
lib/notmuch.h |8
lib/tags.c| 19 +++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index e28ce46..db051c8 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -917,6 +917,10 @@ notmuch_message_destroy (notmuch_message_t *message);
notmuch_bool_t
notmuch_tags_has_more (notmuch_tags_t *tags);
+/* Is the given notmuch_tags_t object on the first tags */
+notmuch_bool_t
+notmuch_tags_is_first (notmuch_tags_t *tags);
+
/* Get the current tag from 'tags' as a string.
*
* Note: The returned string belongs to 'tags' and has a lifetime
@@ -936,6 +940,10 @@ notmuch_tags_get (notmuch_tags_t *tags);
void
notmuch_tags_advance (notmuch_tags_t *tags);
+/* Regress the 'tags' iterator to the previous result. */
+void
+notmuch_tags_regress (notmuch_tags_t *tags);
+
/* Destroy a notmuch_tags_t object.
*
* It's not strictly necessary to call this function. All memory from
diff --git a/lib/tags.c b/lib/tags.c
index 85507e9..cf9e030 100644
--- a/lib/tags.c
+++ b/lib/tags.c
@@ -25,6 +25,7 @@
struct _notmuch_tags {
int sorted;
GList *tags;
+GList *previous_node;
GList *iterator;
};
@@ -55,6 +56,7 @@ _notmuch_tags_create (void *ctx)
tags->sorted = 1;
tags->tags = NULL;
+tags->previous_node = NULL;
tags->iterator = NULL;
return tags;
@@ -94,6 +96,12 @@ notmuch_tags_has_more (notmuch_tags_t *tags)
return tags->iterator != NULL;
}
+notmuch_bool_t
+notmuch_tags_is_first (notmuch_tags_t *tags)
+{
+return tags->previous_node == NULL;
+}
+
const char *
notmuch_tags_get (notmuch_tags_t *tags)
{
@@ -109,10 +117,21 @@ notmuch_tags_advance (notmuch_tags_t *tags)
if (tags->iterator == NULL)
return;
+tags->previous_node = tags->iterator;
tags->iterator = tags->iterator->next;
}
void
+notmuch_tags_regress (notmuch_tags_t *tags)
+{
+if (tags->previous_node == NULL)
+ return;
+
+ tags->iterator = tags->previous_node;
+ tags->previous_node = tags->iterator->prev;
+}
+
+void
notmuch_tags_destroy (notmuch_tags_t *tags)
{
talloc_free (tags);
--
1.6.5.4
[notmuch] [PATCH] Added regress option to threads iterator
Added the functions notmuch_threads_regress and notmuch_threads_is_first to
notmuch library. With them is possible to iterate backwards on threads.
* notmuch_threads_regress do the opposite than notmuch_threads_advance,
getting the threads iterator one position backwards.
* notmuch_threads_is_first return TRUE if the iterator is in the first
thread.
---
lib/notmuch.h |8
lib/query.cc | 28
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 69bd98a..e28ce46 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -429,6 +429,10 @@ notmuch_query_destroy (notmuch_query_t *query);
notmuch_bool_t
notmuch_threads_has_more (notmuch_threads_t *threads);
+/* Is the given notmuch_threads_t object on the first threads */
+notmuch_bool_t
+notmuch_threads_is_first (notmuch_threads_t *threads);
+
/* Get the current thread from 'threads' as a notmuch_thread_t.
*
* Note: The returned thread belongs to 'threads' and has a lifetime
@@ -451,6 +455,10 @@ notmuch_threads_get (notmuch_threads_t *threads);
void
notmuch_threads_advance (notmuch_threads_t *threads);
+/* Regress the 'threads' iterator to the previous result. */
+void
+notmuch_threads_regress (notmuch_threads_t *threads);
+
/* Destroy a notmuch_threads_t object.
*
* It's not strictly necessary to call this function. All memory from
diff --git a/lib/query.cc b/lib/query.cc
index 94a6860..cade17b 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -310,6 +310,12 @@ notmuch_threads_has_more (notmuch_threads_t *threads)
return FALSE;
}
+notmuch_bool_t
+notmuch_threads_is_first (notmuch_threads_t *threads)
+{
+return (g_hash_table_size (threads->threads) <= 1);
+}
+
notmuch_thread_t *
notmuch_threads_get (notmuch_threads_t *threads)
{
@@ -329,6 +335,28 @@ notmuch_threads_advance (notmuch_threads_t *threads)
}
void
+notmuch_threads_regress (notmuch_threads_t *threads)
+{
+notmuch_message_t *message;
+ const char *thread_id;
+
+ thread_id = threads->thread_id;
+
+while (!notmuch_messages_is_first (threads->messages))
+{
+ notmuch_messages_regress (threads->messages);
+ message = notmuch_messages_get (threads->messages);
+ threads->thread_id = notmuch_message_get_thread_id (message);
+
+ if (strcmp (threads->thread_id, thread_id))
+ {
+ g_hash_table_remove (threads->threads, thread_id);
+ return;
+ }
+}
+}
+
+void
notmuch_threads_destroy (notmuch_threads_t *threads)
{
talloc_free (threads);
--
1.6.5.4
[notmuch] [PATCH] Added regress option to tags iterator
On Wed, 9 Dec 2009 14:21:04 -0700, Mark Anderson wrote: > I think that changing has_more is going to be a requirement to come up with a > consistent set of names. What? You don't want to pair it with has_less ? -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/20091209/50e3c3a9/attachment.pgp>
[notmuch] [PATCH] Nuke the remainings of _notmuch_message_add_thread_id.
On Wed, 09 Dec 2009 17:09:01 -0200, Fernando Carrijo wrote: > The function _notmuch_message_add_thread_id has been removed > from the private interface of notmuch. There's no reason for > one to keep a declaration of its prototype in the code base. > Also, lets update a commentary that referenced that function > and escaped from previous scrutiny. > > Signed-off-by: Fernando Carrijo Thanks, as always, for your careful cleanup. This is now pushed. -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/20091209/4ef0ae0a/attachment.pgp>
[notmuch] [PATCH] Added regress option to tags iterator
On Wed, 9 Dec 2009 14:24:46 +0100, Ruben Pollan wrote: > Do you like to call them regress? Should I change that? I don't love the name, (since it's so close to the word "regression" which has a totally different meaning in software context). But I also don't have an immediate suggestion for an improved name yet either. > What about the functions notmuch_*_is_first? Is kind of reversed logic than > notmuch_*_has_more, the last are true when is not reach the limit but the > first ones are true when the limit is reached. But I think it make sense like > that. I'd like a more symmetric API here. Anyone have a favorite set of names for iterating a list in two directions? -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/20091209/2de7312c/attachment.pgp>
[notmuch] [Orgmode] Notmuch: An emacs interface for fast global search and tagging of email
On Wed, 9 Dec 2009 10:01:27 +0100, Manuel Hermenegildo wrote: > (seems like a variable is not defined well in the makefile). Taking > the last "libtalloc.dylib.2" out it seems to compile Maybe I hit that myself as well. Shame on me for now reporting it upstream to the talloc folks if I did. > and so does notmuch, which seems to run fine. Great news. I'm glad you got that working. > Now to trying it within emacs. Here the snag is that notmuch.el uses > apply-partially, which I think is an emacs 23 addtition. *sigh* Shouldn't partial application be a pretty fundamental thing in a functional language? How is it possible that this is new in emacs 23? Anyway, current notmuch is only using apply-partially in one tiny place, (for formatting the help screen). And even that's just to try to generate a nicer-looking help screen than one gets with `describe-mode'. So options here include at least: 1. Rewriting the code to not use apply-partially 2. Punting and just using describe-mode on old emacs. > Thanks for the pointer to the list and for your efforts. Notmuch looks > very interesting. And thank you for your interest. I hope you'll find a way to get it working soon. And please feel free to share whatever you do come up with. -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/20091209/738a3cda/attachment.pgp>
[notmuch] [Orgmode] Notmuch: An emacs interface for fast global search and tagging of email
> Hi Manuel, > > I got notmuch working on OS X, yes. I was on an OS X 10.4 system and > used macports for Xapian and GMime. Then I compiled talloc from source, > (which went fine), and compiled notmuch (which did have some issues with > OS X, but I fixed those---that was the reason why I went through this > exercise). Thanks for your help. I did get it running in the end (I think). I had to get the latest version (which I guess has your changes) and was finally left with only this error in talloc compilation: > gcc -dynamiclib -Wl,-search_paths_first -undefined error -o > libtalloc.dylib.2.0.0 ./talloc.o ./libreplace/replace.o > ./libreplace/snprintf.o ./libreplace/getpass.o strptime.o libtalloc.dylib.2 > > i686-apple-darwin9-gcc-4.0.1: libtalloc.dylib.2: No such file or directory > make: *** [libtalloc.dylib.2.0.0] Error 1 (seems like a variable is not defined well in the makefile). Taking the last "libtalloc.dylib.2" out it seems to compile and so does notmuch, which seems to run fine. Now to trying it within emacs. Here the snag is that notmuch.el uses apply-partially, which I think is an emacs 23 addtition. I am still using 22.3. I can upgrade but then some things are broken in 23 that make some of the other things I use not work. Thanks for the pointer to the list and for your efforts. Notmuch looks very interesting. Manuel -- --- Manuel Hermenegildo | Prof., C.S.Dept., T.U. Madrid (UPM) Director, IMDEA Software and CLIP Group | +34-91-336-7435 (W) -352-4819 (Fax) ---
[notmuch] [PATCH] Added regress option to threads iterator
Added the functions notmuch_threads_regress and notmuch_threads_is_first to
notmuch library. With them is possible to iterate backwards on threads.
* notmuch_threads_regress do the opposite than notmuch_threads_advance,
getting the threads iterator one position backwards.
* notmuch_threads_is_first return TRUE if the iterator is in the first
thread.
---
lib/notmuch.h |8
lib/query.cc | 28
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 69bd98a..e28ce46 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -429,6 +429,10 @@ notmuch_query_destroy (notmuch_query_t *query);
notmuch_bool_t
notmuch_threads_has_more (notmuch_threads_t *threads);
+/* Is the given notmuch_threads_t object on the first threads */
+notmuch_bool_t
+notmuch_threads_is_first (notmuch_threads_t *threads);
+
/* Get the current thread from 'threads' as a notmuch_thread_t.
*
* Note: The returned thread belongs to 'threads' and has a lifetime
@@ -451,6 +455,10 @@ notmuch_threads_get (notmuch_threads_t *threads);
void
notmuch_threads_advance (notmuch_threads_t *threads);
+/* Regress the 'threads' iterator to the previous result. */
+void
+notmuch_threads_regress (notmuch_threads_t *threads);
+
/* Destroy a notmuch_threads_t object.
*
* It's not strictly necessary to call this function. All memory from
diff --git a/lib/query.cc b/lib/query.cc
index 94a6860..cade17b 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -310,6 +310,12 @@ notmuch_threads_has_more (notmuch_threads_t *threads)
return FALSE;
}
+notmuch_bool_t
+notmuch_threads_is_first (notmuch_threads_t *threads)
+{
+return (g_hash_table_size (threads-threads) = 1);
+}
+
notmuch_thread_t *
notmuch_threads_get (notmuch_threads_t *threads)
{
@@ -329,6 +335,28 @@ notmuch_threads_advance (notmuch_threads_t *threads)
}
void
+notmuch_threads_regress (notmuch_threads_t *threads)
+{
+notmuch_message_t *message;
+ const char *thread_id;
+
+ thread_id = threads-thread_id;
+
+while (!notmuch_messages_is_first (threads-messages))
+{
+ notmuch_messages_regress (threads-messages);
+ message = notmuch_messages_get (threads-messages);
+ threads-thread_id = notmuch_message_get_thread_id (message);
+
+ if (strcmp (threads-thread_id, thread_id))
+ {
+ g_hash_table_remove (threads-threads, thread_id);
+ return;
+ }
+}
+}
+
+void
notmuch_threads_destroy (notmuch_threads_t *threads)
{
talloc_free (threads);
--
1.6.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Added regress option to tags iterator
Added the functions notmuch_tags_regress and notmuch_tags_is_first to
notmuch library. With them is possible to iterate backwards on tags.
* notmuch_tags_regress do the opposite than notmuch_tags_advance,
getting the tags iterator one position backwards.
* notmuch_tags_is_first return TRUE if the iterator is in the first
tag.
---
lib/notmuch.h |8
lib/tags.c| 19 +++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index e28ce46..db051c8 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -917,6 +917,10 @@ notmuch_message_destroy (notmuch_message_t *message);
notmuch_bool_t
notmuch_tags_has_more (notmuch_tags_t *tags);
+/* Is the given notmuch_tags_t object on the first tags */
+notmuch_bool_t
+notmuch_tags_is_first (notmuch_tags_t *tags);
+
/* Get the current tag from 'tags' as a string.
*
* Note: The returned string belongs to 'tags' and has a lifetime
@@ -936,6 +940,10 @@ notmuch_tags_get (notmuch_tags_t *tags);
void
notmuch_tags_advance (notmuch_tags_t *tags);
+/* Regress the 'tags' iterator to the previous result. */
+void
+notmuch_tags_regress (notmuch_tags_t *tags);
+
/* Destroy a notmuch_tags_t object.
*
* It's not strictly necessary to call this function. All memory from
diff --git a/lib/tags.c b/lib/tags.c
index 85507e9..cf9e030 100644
--- a/lib/tags.c
+++ b/lib/tags.c
@@ -25,6 +25,7 @@
struct _notmuch_tags {
int sorted;
GList *tags;
+GList *previous_node;
GList *iterator;
};
@@ -55,6 +56,7 @@ _notmuch_tags_create (void *ctx)
tags-sorted = 1;
tags-tags = NULL;
+tags-previous_node = NULL;
tags-iterator = NULL;
return tags;
@@ -94,6 +96,12 @@ notmuch_tags_has_more (notmuch_tags_t *tags)
return tags-iterator != NULL;
}
+notmuch_bool_t
+notmuch_tags_is_first (notmuch_tags_t *tags)
+{
+return tags-previous_node == NULL;
+}
+
const char *
notmuch_tags_get (notmuch_tags_t *tags)
{
@@ -109,10 +117,21 @@ notmuch_tags_advance (notmuch_tags_t *tags)
if (tags-iterator == NULL)
return;
+tags-previous_node = tags-iterator;
tags-iterator = tags-iterator-next;
}
void
+notmuch_tags_regress (notmuch_tags_t *tags)
+{
+if (tags-previous_node == NULL)
+ return;
+
+ tags-iterator = tags-previous_node;
+ tags-previous_node = tags-iterator-prev;
+}
+
+void
notmuch_tags_destroy (notmuch_tags_t *tags)
{
talloc_free (tags);
--
1.6.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Added regress option to tags iterator
With the last 4 patches there is more or less all I wanted implemented. Do you like to call them regress? Should I change that? What about the functions notmuch_*_is_first? Is kind of reversed logic than notmuch_*_has_more, the last are true when is not reach the limit but the first ones are true when the limit is reached. But I think it make sense like that. On 14:10, Wed 09 Dec 09, Ruben Pollan wrote: Added the functions notmuch_tags_regress and notmuch_tags_is_first to notmuch library. With them is possible to iterate backwards on tags. [...] -- Rubén Pollán | jabber:mes...@jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sed realistas, exigid lo imposible. signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Nuke the remainings of _notmuch_message_add_thread_id.
The function _notmuch_message_add_thread_id has been removed from the private interface of notmuch. There's no reason for one to keep a declaration of its prototype in the code base. Also, lets update a commentary that referenced that function and escaped from previous scrutiny. Signed-off-by: Fernando Carrijo fcarr...@yahoo.com.br --- lib/database.cc |9 - lib/notmuch-private.h |4 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 23ddd4a..b6c4d07 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -855,12 +855,11 @@ _notmuch_database_link_message_to_children (notmuch_database_t *notmuch, * * We first look at 'message_file' and its link-relevant headers * (References and In-Reply-To) for message IDs. We also look in the - * database for existing message that reference 'message'.p + * database for existing message that reference 'message'. * - * The end result is to call _notmuch_message_add_thread_id with one - * or more thread IDs to which this message belongs, (including - * generating a new thread ID if necessary if the message doesn't - * connect to any existing threads). + * The end result is to call _notmuch_message_ensure_thread_id which + * generates a new thread ID if the message doesn't connect to any + * existing threads. */ static notmuch_status_t _notmuch_database_link_message (notmuch_database_t *notmuch, diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h index 0c340a7..116f63d 100644 --- a/lib/notmuch-private.h +++ b/lib/notmuch-private.h @@ -194,10 +194,6 @@ _notmuch_message_set_filename (notmuch_message_t *message, const char *filename); void -_notmuch_message_add_thread_id (notmuch_message_t *message, - const char *thread_id); - -void _notmuch_message_ensure_thread_id (notmuch_message_t *message); void -- 1.5.6.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [Orgmode] Notmuch: An emacs interface for fast global search and tagging of email
On Wed, 9 Dec 2009 10:01:27 +0100, Manuel Hermenegildo he...@fi.upm.es wrote: (seems like a variable is not defined well in the makefile). Taking the last libtalloc.dylib.2 out it seems to compile Maybe I hit that myself as well. Shame on me for now reporting it upstream to the talloc folks if I did. and so does notmuch, which seems to run fine. Great news. I'm glad you got that working. Now to trying it within emacs. Here the snag is that notmuch.el uses apply-partially, which I think is an emacs 23 addtition. *sigh* Shouldn't partial application be a pretty fundamental thing in a functional language? How is it possible that this is new in emacs 23? Anyway, current notmuch is only using apply-partially in one tiny place, (for formatting the help screen). And even that's just to try to generate a nicer-looking help screen than one gets with `describe-mode'. So options here include at least: 1. Rewriting the code to not use apply-partially 2. Punting and just using describe-mode on old emacs. Thanks for the pointer to the list and for your efforts. Notmuch looks very interesting. And thank you for your interest. I hope you'll find a way to get it working soon. And please feel free to share whatever you do come up with. -Carl pgp61zjhsQfSq.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Added regress option to tags iterator
On Wed, 9 Dec 2009 14:24:46 +0100, Ruben Pollan mes...@sindominio.net wrote: Do you like to call them regress? Should I change that? I don't love the name, (since it's so close to the word regression which has a totally different meaning in software context). But I also don't have an immediate suggestion for an improved name yet either. What about the functions notmuch_*_is_first? Is kind of reversed logic than notmuch_*_has_more, the last are true when is not reach the limit but the first ones are true when the limit is reached. But I think it make sense like that. I'd like a more symmetric API here. Anyone have a favorite set of names for iterating a list in two directions? -Carl pgp95K6xnjw9c.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Added regress option to tags iterator
Excerpts from Carl Worth's message of Wed Dec 09 13:08:43 -0700 2009: On Wed, 9 Dec 2009 14:24:46 +0100, Ruben Pollan mes...@sindominio.net wrote: Do you like to call them regress? Should I change that? I don't love the name, (since it's so close to the word regression which has a totally different meaning in software context). But I also don't have an immediate suggestion for an improved name yet either. What about the functions notmuch_*_is_first? Is kind of reversed logic than notmuch_*_has_more, the last are true when is not reach the limit but the first ones are true when the limit is reached. But I think it make sense like that. I'd like a more symmetric API here. Anyone have a favorite set of names for iterating a list in two directions? I like vocabulary games: fwd/bck forward/reverse next/prev advance/retreat inc/dec iter_fwd/iter_back earlier/later younger/older I think that changing has_more is going to be a requirement to come up with a consistent set of names. -Carl ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Added regress option to tags iterator
On Wed, 9 Dec 2009 14:21:04 -0700, Mark Anderson markr.ander...@amd.com wrote: I think that changing has_more is going to be a requirement to come up with a consistent set of names. What? You don't want to pair it with has_less ? -Carl pgpPqJcgqhMLA.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Added regress option to tags iterator
On 12:08, Wed 09 Dec 09, Carl Worth wrote: On Wed, 9 Dec 2009 14:24:46 +0100, Ruben Pollan mes...@sindominio.net wrote: Do you like to call them regress? Should I change that? I don't love the name, (since it's so close to the word regression which has a totally different meaning in software context). But I also don't have an immediate suggestion for an improved name yet either. Me neither, but as I don't have any better idea I just use regress. But we can try to come up with something better. What about the functions notmuch_*_is_first? Is kind of reversed logic than notmuch_*_has_more, the last are true when is not reach the limit but the first ones are true when the limit is reached. But I think it make sense like that. I'd like a more symmetric API here. Anyone have a favorite set of names for iterating a list in two directions? Yes, but actually are a bit different somehow. When you advance the last iterator you can reach is a non-valid (outside the list) iterator. When you 'regress' the iterator at the end is a valid iterator, I don't see the need on get outside of the list like with advance. So, maybe because of it have sense the functions notmuch_*_is_first. Anyway I really don't mind, one or other. To change it is trivial. It's harder to find a good pair of names. -- Rubén Pollán | jabber:mes...@jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- La felicidad no es hacer lo que deseas es desear lo que haces. signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Added regress option to tags iterator
On 14:21, Wed 09 Dec 09, Mark Anderson wrote: advance/retreat Jeffrey already suggested retreat. I let you (English speakers) decide, my English level is not enough for it. -- Rubén Pollán | jabber:mes...@jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Ésta es la historia de una sociedad que se hunde y mientras cae se repite: hasta ahora todo va bien, hasta ahora todo va bien ... Pero lo importante no es la caida sino el aterrizaje. el odio signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Quick thoughts on a notmuch daemon
On 14:27, Thu 03 Dec 09, Carl Worth wrote: A simple solution would be a notmuch daemon that can accept commands on stdin, (in basically the exact same form as the current notmuch command-line interface). If the daemon does the job of periodically incorporating new mail, then the only command necessary to solve (1) above would be the tag command. I like the idea. I didn't liked to fork for each command, so I started to play with the library for create a UI. But with a demon like that I guess will be nicer to use it than to call directly to the library. Why use stdin? Why not sockets? With them at could be possible to use several concurrent clients with the same server. (I really love moc for play music, and one of its greatest features is that) -- Rubén Pollán | jabber:mes...@jabber.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- No vamos a reivindicar nada, no vamos a pedir nada. Tomaremos, okuparemos. signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Threading
I was wondering if there's a way in notmuch to group un-associated threads into a single thread. I have a bug tracking system that doesn't give me emails that thread naturally in notmuch. I wouldn't mind writing a filter that could help identify a thread id which should apply to a message, and suggest that to notmuch. Is there a method for this existing in notmuch yet? Mark Anderson ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
