[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
On Tue, 9 Aug 2011 19:32:49 +0200, Daniel Schoepe wrote: > This patch adds completion with in the minibuffer for > notmuch-search and notmuch-search-filter. Finally pushed. d
set test prereqs (Emacs, GDB, GPG) v4
On Tue, 1 Nov 2011 22:20:25 +0200, Ali Polatel wrote: > On Tue, Nov 01, 2011 at 08:49:10PM +0100, Pieter Praet wrote: > >Rebased to current master. > > > >Previous version: > > id:"1307016220-17509-1-git-send-email-pieter at praet.org" > > > >Discussion: > > id:"1317660447-27520-1-git-send-email-schnouki at schnouki.net" > > > > Thanks for the nice work! > I want to share one thing which came up to my mind during reading > through them. Since we require bash for tests, we might go for using > bash's builtin 'type -P foo' instead of 'which foo'. Not that it's > important, just wondered "why not?" > > -alip Good suggestion! In fact, we might as well immediately go for full POSIX compliance. How do you feel about using `hash' ? Besides being available in POSIX sh, it has the added benefit of making subsequent lookups faster [*]. Peace -- Pieter [*] This statement only applies to the shell built-in. Other types of hash may distort your perception of time, which is likely to result in significantly slower lookups.
[PATCH 1/4] test: add 'GnuPG' prereq to dependent 'crypto' tests
On Tue, 01 Nov 2011 14:17:51 -0700, Jameson Graef Rollins wrote:
> On Tue, 1 Nov 2011 20:49:11 +0100, Pieter Praet wrote:
> > -test_expect_success 'emacs delivery of signed message' \
> > +test_expect_success GPG 'emacs delivery of signed message' \
>
> Hi, Pieter and Thomas. Thanks for all the work on this, but I have one
> issue. Is there a way we can do this without adding a new argument to
> every test function? For some reason I really don't like that solution.
> It seems too invasive. Can't we have something that works more like
> test_subtest_known_broken, that modifies the test environment, rather
> than add an argument to every call of every testing function?
>
> jamie.
I've been thinking the very same thing.
We could use `test_have_prereq' to get rid of the argument, e.g.:
#+begin_src sh
test_have_prereq EMACS && \
test_begin_subtest "blah"
echo "doing stuff..."
test_expect_equal_file OUTPUT EXPECTED
#+end_src
...but still, everything between `test_begin_subtest' and `test_expect_*'
would be executed, so to err on the safe side, we could wrap the full body
of every test, e.g.:
#+begin_src sh
test_begin_subtest "blah"
test_have_prereq EMACS && {
...
echo "doing stuff..."
...
}
test_expect_equal_file OUTPUT EXPECTED
#+end_src
Or... (I've given this zero thought, so please take it with a bag of
salt) we could run all tests from inside a "controller" which `eval's
their contents line by line, and skips a test entirely whenever $? > 0.
All of this is (still) excessively invasive in some way or another though...
Suggestions?
Peace
--
Pieter
Patch review/application process
On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe wrote: ... > - (Re)try some patch/issue management software: Since patches are easily > forgotten if they just float around in several months old mails, it > might be prudent to use something to keep track of patches or issues > these patches address. I know that the patchwork instance didn't work > out so well, partly because it didn't recognize new versions of sent > patches. An alternative might be an issue-based system, which would be > comfortably usable if it supported discussing issues via mail instead > of having to use some web interface. I think this is supported by > redmine. Since the wiki is ikiwiki, it might be worth using the bug tracking available in ikiwiki: http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/ or just create a dedicated instance of ikiwiki just for tracking bugs (possibly as part of the source repository, so that bugs get carried around with the source in git, and can be closed with the commit that fixes them, etc.) Cheers, Phil -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -- 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/2002/cffdc1f9/attachment.pgp>
thread ordering based on references and/or in-reply-to
On Mon, Oct 31, 2011 at 7:07 PM, Florian Friesdorf wrote: > > Hi, > > I'm looking into taking the References header into account for thread > ordering. So far only In-Reply-To is used. My C/C++ is rusty at best, so > I'd need some help to get this done. > > Carl gave a try on irc already to clear things up for me, reading into > it, I have more questions: > > lib/thread.cc/_resolve_thread_relationships adds messages as replies to > a parent. > > Currently, we seem to treat In-Reply-To as empty or single msgid. If I > understand rfc822 it can be a list of msgids and/or phrases. Do/shall we > support that? > > References is a list of msgids, with the last one being the direct > parent. I don't know how multiple direct parents are handled here. > > DJB recommends "... readers look for identifiers in In-Reply-To and > append them to References if they are not already included in > References." [1] > > In that case if there are two msgids in In-Reply-To and there are > appended to the References list, than only the last one will be a parent > and the one that used to be the last is not a parent anymore. > > And Carl recommends to treat references and in-reply-to as two separated > sources of information, first using in-reply-to and then references in > order "to attach to the deepest referenced parent". > > I fail to understand that. Am I complicating things? > How do we want to treat the combination of References/In-Reply-To? > > Do we have code that returns the last msgid listed in references? > database.cc/parse_references seems not to care about order, just > existence - or is GHashTable ordered. > > [1] http://cr.yp.to/immhf/thread.html > > > florian I know this came up on IRC, but have you looked at jwz's threading algorithm (http://www.jwz.org/doc/threading.html)? Carl mentioned that notmuch already implements it (except for subject matching), but notmuch only implements the subset of it necessary to group messages into threads without structure. Much of the algorithm is devoted to exactly this problem of piecing together the thread structure based on all of the information in both In-Reply-To and References. The algorithm as described combines the issues of grouping and structuring since it's expecting a giant pile of mail as input, but there's no reason these can't be teased apart.
[PATCH] lib/database.cc: use flush Xapian method instead of commit
On Fri, Oct 28, 2011 at 10:56 AM, David Bremner wrote: > From: David Bremner > > Apparently the method was renamed in Xapian 1.1.0 but the old method > name will stay around for a while. It seems better to stick with the > old name to make notmuch compile with older versions of Xapian, at > least for now. LGTM
[RFC PATCH v2 0/3] lib/cli/emacs: limit number of messages in search results
On Tue, 01 Nov 2011 09:30:56 -0300, David Bremner wrote: > Is just because it add a function to the library that you think this > might be problematic? I don't think we are super-dogmatic about the > library never growing. When notmuch started, there were no bindings, so > in retrospect maybe more functionality went into the CLI than might > happen if we started from scratch. If I remember Carl's statement > correctly, one rule is that stuff in the library should not require > configuration. Hi, thanks, that's encouraging. It's mostly that, based on past experience, I'm hesitant about extending a library interface. Once you get users, you have to live with it. So you want to get it right. Having said that, I think in this v2 of the set, the library interface for notmuch_query_count_threads() is sane and complimentary to the existing notmuch_query_count_messages(). (Also quoting IRC: " j4ni: Yes, the interface seems totally reasonable.") Later on, someone might come up with a better implementation, but for now it's already much better than having to iterate and construct the threads. I'll prepare a v3 with some tests and polish. BR, Jani.
python: unpythonic result of Message.get_replies()
On Wed, 05 Oct 2011 03:42:38 +0200, Justus Winter <4winter at informatik.uni-hamburg.de> wrote: Non-text part: multipart/mixed > I noticed that Message.get_replies() returns a Messages object *or* > None. Quoting the documentation: > > > Returns: Messages or None if there are no replies to this message > > Messages is a class implementing the iterator protocol, so a python > programmer would expect to get an iterator that raises a StopIteration > on the first invocation of next() if there aren't any replies. > Yes, that change would make perfect sense, and I would be happy to accept a patch for it :-) Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/2002/426e4cd9/attachment.pgp>
[PATCH 1/2] python: add classes to wrap all notmuch_*_t types
On Mon, 10 Oct 2011 00:12:53 +0200, Justus Winter <4winter at informatik.uni-hamburg.de> wrote: > Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> > --- > bindings/python/notmuch/globals.py | 38 > +++- Hi there, catching up on email, sorry for the delay. I am not opposed to the change, but I fail to see any justification for a whole lot more complexity either. What was wrong with the previous approach? Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/2002/b8c4390c/attachment.pgp>
Re: [PATCH 1/2] python: add classes to wrap all notmuch_*_t types
On Mon, 10 Oct 2011 00:12:53 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- bindings/python/notmuch/globals.py | 38 +++- Hi there, catching up on email, sorry for the delay. I am not opposed to the change, but I fail to see any justification for a whole lot more complexity either. What was wrong with the previous approach? Sebastian pgpvq2ntd7Ztf.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: python: unpythonic result of Message.get_replies()
On Wed, 05 Oct 2011 03:42:38 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Non-text part: multipart/mixed I noticed that Message.get_replies() returns a Messages object *or* None. Quoting the documentation: Returns: Messages or None if there are no replies to this message Messages is a class implementing the iterator protocol, so a python programmer would expect to get an iterator that raises a StopIteration on the first invocation of next() if there aren't any replies. Yes, that change would make perfect sense, and I would be happy to accept a patch for it :-) Sebastian pgpVRtwlViqza.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC PATCH v2 0/3] lib/cli/emacs: limit number of messages in search results
On Tue, 01 Nov 2011 09:30:56 -0300, David Bremner da...@tethera.net wrote: Is just because it add a function to the library that you think this might be problematic? I don't think we are super-dogmatic about the library never growing. When notmuch started, there were no bindings, so in retrospect maybe more functionality went into the CLI than might happen if we started from scratch. If I remember Carl's statement correctly, one rule is that stuff in the library should not require configuration. Hi, thanks, that's encouraging. It's mostly that, based on past experience, I'm hesitant about extending a library interface. Once you get users, you have to live with it. So you want to get it right. Having said that, I think in this v2 of the set, the library interface for notmuch_query_count_threads() is sane and complimentary to the existing notmuch_query_count_messages(). (Also quoting IRC: amdragon j4ni: Yes, the interface seems totally reasonable.) Later on, someone might come up with a better implementation, but for now it's already much better than having to iterate and construct the threads. I'll prepare a v3 with some tests and polish. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/database.cc: use flush Xapian method instead of commit
On Fri, Oct 28, 2011 at 10:56 AM, David Bremner da...@tethera.net wrote: From: David Bremner brem...@debian.org Apparently the method was renamed in Xapian 1.1.0 but the old method name will stay around for a while. It seems better to stick with the old name to make notmuch compile with older versions of Xapian, at least for now. LGTM ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: thread ordering based on references and/or in-reply-to
On Mon, Oct 31, 2011 at 7:07 PM, Florian Friesdorf f...@chaoflow.net wrote: Hi, I'm looking into taking the References header into account for thread ordering. So far only In-Reply-To is used. My C/C++ is rusty at best, so I'd need some help to get this done. Carl gave a try on irc already to clear things up for me, reading into it, I have more questions: lib/thread.cc/_resolve_thread_relationships adds messages as replies to a parent. Currently, we seem to treat In-Reply-To as empty or single msgid. If I understand rfc822 it can be a list of msgids and/or phrases. Do/shall we support that? References is a list of msgids, with the last one being the direct parent. I don't know how multiple direct parents are handled here. DJB recommends ... readers look for identifiers in In-Reply-To and append them to References if they are not already included in References. [1] In that case if there are two msgids in In-Reply-To and there are appended to the References list, than only the last one will be a parent and the one that used to be the last is not a parent anymore. And Carl recommends to treat references and in-reply-to as two separated sources of information, first using in-reply-to and then references in order to attach to the deepest referenced parent. I fail to understand that. Am I complicating things? How do we want to treat the combination of References/In-Reply-To? Do we have code that returns the last msgid listed in references? database.cc/parse_references seems not to care about order, just existence - or is GHashTable ordered. [1] http://cr.yp.to/immhf/thread.html florian I know this came up on IRC, but have you looked at jwz's threading algorithm (http://www.jwz.org/doc/threading.html)? Carl mentioned that notmuch already implements it (except for subject matching), but notmuch only implements the subset of it necessary to group messages into threads without structure. Much of the algorithm is devoted to exactly this problem of piecing together the thread structure based on all of the information in both In-Reply-To and References. The algorithm as described combines the issues of grouping and structuring since it's expecting a giant pile of mail as input, but there's no reason these can't be teased apart. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Patch review/application process
On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe dan...@schoepe.org wrote: ... - (Re)try some patch/issue management software: Since patches are easily forgotten if they just float around in several months old mails, it might be prudent to use something to keep track of patches or issues these patches address. I know that the patchwork instance didn't work out so well, partly because it didn't recognize new versions of sent patches. An alternative might be an issue-based system, which would be comfortably usable if it supported discussing issues via mail instead of having to use some web interface. I think this is supported by redmine. Since the wiki is ikiwiki, it might be worth using the bug tracking available in ikiwiki: http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/ or just create a dedicated instance of ikiwiki just for tracking bugs (possibly as part of the source repository, so that bugs get carried around with the source in git, and can be closed with the commit that fixes them, etc.) Cheers, Phil -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp4uG7weAJ65.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] test: add 'GnuPG' prereq to dependent 'crypto' tests
On Tue, 01 Nov 2011 14:17:51 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Tue, 1 Nov 2011 20:49:11 +0100, Pieter Praet pie...@praet.org wrote:
-test_expect_success 'emacs delivery of signed message' \
+test_expect_success GPG 'emacs delivery of signed message' \
Hi, Pieter and Thomas. Thanks for all the work on this, but I have one
issue. Is there a way we can do this without adding a new argument to
every test function? For some reason I really don't like that solution.
It seems too invasive. Can't we have something that works more like
test_subtest_known_broken, that modifies the test environment, rather
than add an argument to every call of every testing function?
jamie.
I've been thinking the very same thing.
We could use `test_have_prereq' to get rid of the argument, e.g.:
#+begin_src sh
test_have_prereq EMACS \
test_begin_subtest blah
echo doing stuff...
test_expect_equal_file OUTPUT EXPECTED
#+end_src
...but still, everything between `test_begin_subtest' and `test_expect_*'
would be executed, so to err on the safe side, we could wrap the full body
of every test, e.g.:
#+begin_src sh
test_begin_subtest blah
test_have_prereq EMACS {
...
echo doing stuff...
...
}
test_expect_equal_file OUTPUT EXPECTED
#+end_src
Or... (I've given this zero thought, so please take it with a bag of
salt) we could run all tests from inside a controller which `eval's
their contents line by line, and skips a test entirely whenever $? 0.
All of this is (still) excessively invasive in some way or another though...
Suggestions?
Peace
--
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: set test prereqs (Emacs, GDB, GPG) v4
On Tue, 1 Nov 2011 22:20:25 +0200, Ali Polatel pola...@gmail.com wrote: On Tue, Nov 01, 2011 at 08:49:10PM +0100, Pieter Praet wrote: Rebased to current master. Previous version: id:1307016220-17509-1-git-send-email-pie...@praet.org Discussion: id:1317660447-27520-1-git-send-email-schno...@schnouki.net Thanks for the nice work! I want to share one thing which came up to my mind during reading through them. Since we require bash for tests, we might go for using bash's builtin 'type -P foo' instead of 'which foo'. Not that it's important, just wondered why not? -alip Good suggestion! In fact, we might as well immediately go for full POSIX compliance. How do you feel about using `hash' ? Besides being available in POSIX sh, it has the added benefit of making subsequent lookups faster [*]. Peace -- Pieter [*] This statement only applies to the shell built-in. Other types of hash may distort your perception of time, which is likely to result in significantly slower lookups. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
On Tue, 9 Aug 2011 19:32:49 +0200, Daniel Schoepe daniel.scho...@googlemail.com wrote: This patch adds completion with tab in the minibuffer for notmuch-search and notmuch-search-filter. Finally pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
