Python bindings for adoption

2012-01-09 Thread sebast...@sspaeth.de
Hurray, thanks Justus. That is much appreciated.
Spaetz



David Bremner  schrieb:

>On Sun, 08 Jan 2012 16:16:06 -, Justus Winter
><4winter at informatik.uni-hamburg.de> wrote:
>> 
>> I've decided to step up as a new maintainer for the libnotmuch python
>> bindings. I assume that I'll have to mail an ssh public key to
>someone
>> for repository access, right?
>> 
>
>That's right. Carl (in copy) handles repository access.
>
>d



[PATCH] emacs: notmuch-hello: Use our own keymap.

2010-05-13 Thread sebast...@sspaeth.de
> Previously, we were adding our bindings directly to `widget-keymap',
> resulting in them being shared by anything else that used that keymap.

Is this patch preferable over the one I sent some time ago in
id:1272882573-9864-1-git-send-email-Sebastian at SSpaeth.de ?

My patch makes notmuch-hello a major mode and also creates the proper
keymap. THe major mode allows the '?' keybinding to also work.



[notmuch] Request for high-priority improvements to notmuch

2010-02-01 Thread sebast...@sspaeth.de
Let me second those thoughts. I'll even put forward 2 more pet suggestions
:).

1)
> Ability to apply tags based on folder paths in "notmuch new"

This will let me sync tags with notmuchsync much more easily than going
through all mails and detecting their IMAP path from the filename. Support
for searching/tagging mails in certain folders would be really nice. I
would appreciate but do not urgently need a [tags] section in notmuch
proper, as I'll extend notmuchsync to do that for me.

2)
> JSON output for "notmuch search/show" with ability to filter output fields
> "search" --> "search --output=thread_id,date,number,author,subject,tags"
>  "show"  --> "search
> --output=message_id,tags,path,header,body,attachments"

YES PLEASE :-). notmuch seems designed to work in an ecosystem of
surrounding scripts, feeding data in and out. But we are all currently
limited to regexes for that. And heck, I hard a hard time understanding
why all hell broke out until I found that i had added a tag containing
parentheses which made my regex fail. :-). XML, JSON, any structured
output would be nice.

And as for filtering: YES, PLEASE :-). notmuchsync and many other 3rd
party apps would love that. As father of notmuchsync, I can tell you my
little script hickups very badly when slurping in 200k mails (including
text bodies) just to find out the maildir tags of those mails.

> * Proper maildir sync ("search --output=message_id,tags,path" ...)
[snip many sensible proposals]

Sebastian

P.S. as a bonus: My very ugly way of getting a distribution of existing
tags (extra points for beautified versions):

notmuch dump|sed -e 's/^.*(//'|sed -e 's/)$//'|sed 's/ /\n/g'|sort|uniq
-c|sort -r




[notmuch] Git feature branch

2010-01-25 Thread sebast...@sspaeth.de
> I think it would make sense to move the mainline to git.debian.org
> for now, or another place where everyone can easily get an account.
> As alternatives I propose repo.or.cz. I'd prefer to stay away from
> commercial services like Github.

Any of those sounds fine to me, really. No preferences. I have little
experience with git, so I can't comment on the hierarchy of branches.
Cherry-picking all those patches "up" does sound like it needs some
dedicated attention though...

> Sebastian, would it make sense to migrate your work into a 'pu'
> branch?

Not sure. My feature branch is basically just the branch I use and I have
ecclectically been adding patches that seemed useful to me and ignored
others I was not so sure about. I have no clue if Carl would want those
features/patches in master, but if yes he is free to pull it into an
unstable branch or however we want to name it.

> What patch tracking workflow should we adopt? Keep sending patches
> to the mailing list and have a few people who integrate them into
> master or pu (or even maint/next), as appropriate? Use the Debian
> bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> manager on notmuchmail.org? Use patchwork [1]?

Personally, I like how patchwork complements mailing lists for collecting
patches, so a patchwork-supported mailing list would work well for me. I
have less experience with the Debian bug tracker, not sure if a
'downstream' project can simply use it (but you would know that :-)). I
wouldn't mind to have my roundup used, but it should probably be on some
more officially-looking URL, rather than on a random personal webspace,
shouldn't it?

All  I know is that there is a great momentum behind notmuch at the
moment, and it would be great to not lose that.

Sebastian



[notmuch] Thoughts on notmuch and Lua

2010-01-16 Thread sebast...@sspaeth.de
> We've talked about switching from default tags of "inbox" and "unread"
> to simply having new mail tagged with a "new" tag.

Ohh, please make the standard set of tags for new mail configurable in the 
config file. I might want to add different tags for special purposes, like 
"not_virus_scanned_yet" or what not by default. Having to run a script just to 
add those tags to any "new" mails sounds a bit complicated and error-prone to 
me.

spaetz