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_f
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 t
muchmail.org/pipermail/notmuch/attachments/20091209/f9234189/attachment.pgp>
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: Fe
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:
<ht
> 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 we
lable
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091209/2de7312c/attachment.pgp>
ication/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091209/4ef0ae0a/attachment.pgp>
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 me
as 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>
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>
ble
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091209/53ee0903/attachment-0001.pgp>
l.org/pipermail/notmuch/attachments/20091209/c77e2427/attachment.pgp>
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
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_f
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 t
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
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: Fe
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.
> an
> 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 we
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 im
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
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 meani
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
pgpPqJcgqhMLA.pgp
Description: PGP signature
___
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). Bu
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 s
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 comman
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
The termlist is already sorted, so this is the patch trying to minimize
the modification of database as suggested in the comment and Carl's
TODO file.
My poor profiling shows not much, but some improvement.
*Before*
% time notmuch tag +test id:hfntnu+g...@egroups.com
MOD_PLISTS: 368
notmuch
29 matches
Mail list logo
