Re: Some thoughts about notmuch sync with other agents

also sprach Paul R <paul.r.ml@...> [2010.01.28.0316 +1300]:
> As you see, I advocate a NotMuch <-> IMAP synchronisation ASAP :)

Given the limitations of IMAP (non-transactional, non-standard
keywords implementation, …), I think chances of this are rapidly
diminishing, but I'd love to be proven wrong.

> First of all, processing mail with MUA involves some simple logic that
> is shared by most MUA. This is about receiving *new* mails, *reading*
> mail, *replying* to mail and so on... IMHO, this really belongs to the
> mail processing logic and not to the user logic. Hence my first
> request :
> 
>   1: Don't use user tags space to store MUA flags.
> 
>      That means no more "seen", "unread", "replied" as tags. These are
>      MUA processing *flags*, that must belong to an established set.
>      Tags, on the other hand, are user-land information. So no more
>      [seen, replied, grandma, important] tag sets :)

I disagree.

The MUA actually doesn't (shouldn't) care at all about any of these
flags, at least not for core functionality. Sure, a MUA should
probably hide messages tagged 'deleted', and it would be nice if it
could be configured to highlight messages tagged 'important', but
none of the others — "seen", "unread", "replied", … — have any role
in the core functionality. They are purely user-specific.

They are leftovers from days when some MUA designer decided that

Re: Some thoughts about notmuch sync with other agents

REPOSTING, as the previous reply went to Gmane

> One may
> or may not like IMAP for good reasons, the fact is that it is here and
> has allowed users to read mails from various places and terminals,
> keeping important information synced. So I think that notmuch will have
> to live with that, and provide what is required to integrate smoothly
> into this environment.

agreed

> First of all, processing mail with MUA involves some simple logic that
> is shared by most MUA. This is about receiving *new* mails, *reading*
> mail, *replying* to mail and so on... IMHO, this really belongs to the
> mail processing logic and not to the user logic. Hence my first
> request :
>   1: Don't use user tags space to store MUA flags.

I don't really see what you gain by this proposal. I don't necessarily
think it's bad either, but there is no advantage IMHO.

What you propose is basically that those tags are not directly seen by
the user and not modifiable by the user. What's the advantage over
having a small set of "reserved tag keywords"? Your notmuch-capable
editor could still chose to not display "unread" and "deleted" tags but
simply hide deleted mails and show unread mails in bold or so. I simply
don't think it's important how tags are stored and the current scheme is
dead simple which makes it pretty nice.

>      That means no more "seen", "unread", "replied" as tags. These are

Request for high-priority improvements to notmuch

Hello Carl et. al.

I know you're trying to work through a boat load of backlog patches, but
after using notmuch for a couple weeks now, I would like to highlight
what I think are the two most important things that need to be be
implemented in the notmuch CLI and why.

Ability to apply tags based on folder paths in "notmuch new"
------------------------------------------------------------
Notmuch needs to be able to be configured to tag messages differently if
they appear in different folders (mentioned previously in
id:87tyu9dfhs.fsf@...).  For instance, for
"inbox"/"sent"/"drafts"/"archive" maildir subdirectories of your primary
mail directory "/home/user/mail", a notmuch config could look like this:

   [database]
   path=/home/user/mail

   [tags]
   inbox = +inbox,+unread
   sent = +sent
   drafts = +draft
   archive = -inbox

In other words, a user could specify that new messages to the maildir
"/home/user/mail/sent" would be tagged *only* with the "sent" tag.

This is very important for being able to handle different kinds of new
messages differently, which is very important for being able to have
notmuch handle things that it is currently unable to handle.  If this is

Re: Request for high-priority improvements to notmuch

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.

Re: Request for high-priority improvements to notmuch

Excerpts from sebastian's message of Mon Feb 01 14:29:44 -0600 2010:
> 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.
> 

There's been a JSON patch waiting for a month now.

patchwork test instance (was: Git feature branch)

I investigated some patch/issue trackers over the weekend. Here's my
summary/reply.

The executive summary is that
http://patchwork.madduck.net/project/notmuch/list/ now exists.
I have not really used it for anything real, so if some of you feel
inclined to give it a shot, sign up and triage away! Feedback
welcome.

also sprach James Rowe <jnrowe@...> [2010.01.28.2005 +1300]:
>   Roundup has command line and email interfaces.  The email interface is
> quite similar to debian's.  I've never used a launchpad hosted project
> so I can't compare it.

Roundup is an issue tracker, while Patchwork is a patch tracker.
They are fundamentally distinct, but there are overlaps. What led me
to go the Patchwork-path is that projects like the kernel and Git
don't use issue trackers but work entirely patch-based.

I don't know if that is the right way to do things, but having an
issue tracker that fills up with bugs and wishlist items lacking
patches is no better in the long run than not having an issue
tracker.

Arguably, being patch-centric means that a project has a higher
barrier of entry, but it also means that if someone wants something,
they know that they'll have to somehow end up with a patch. The way
this happens on Git is that you either write it yourself and bring
it up to discussion (which is what patchwork facilitates), or
constructively theorise the functionality until someone else

Emacs paned UI

Hello everyone!

I've been using notmuch and following its development for a little while
now, and I've come to like it very much. One thing that has been lacking
is an easy-to-use Emacs interface, and I believe Keith and Carl had a
little discussion a while back about how we should go about making a
paned UI.

So, I dusted off my Elisp manual and hacked up notmuch.el to support a
3-paned UI. This involved the creation of a minor mode (I call it
notmuch-browse-mode) that manages window state, along with several
modifications of existing functions to "do the right thing" when we're
in browse-mode (such as close the "show" window, switch to the "folder"
window, etc.).

The UI is thus far usable, but not bug-free. For example,
advancing-and-archiving using SPC sometimes "advances" to the same
message (but I am always able to advance with "a"). Also, the search
window does not update after archiving, but I believe this is an
existing bug.

The code is in the "emacs-ui" branch of the following repo:

git://github.com/tadfisher/notmuch-tad.git

Suggestions, criticism, and a code review are both needed and desired.

--

-- 
Tad Fisher

Re: Request for high-priority improvements to notmuch

also sprach sebastian@...
<sebastian@...> [2010.02.02.0929 +1300]:
> 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.

Shoot me, but I'd say mbox output would be nice too.

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"time flies like an arrow. fruit flies like a banana."
                                                       -- groucho marx

spamtraps: madduck.bogus@...

also sprach sebastian@...
<sebastian@...> [2010.02.02.0929 +1300]:
> 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.

Shoot me, but I'd say mbox output would be nice too.

Re: Request for high-priority improvements to notmuch

also sprach Scott Robinson <scott@...> [2010.02.02.1043 +1300]:
> > 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.
> > 
> 
> There's been a JSON patch waiting for a month now.

The last month has been busy for everyone, mainly due to LCA. We
should now all work together to help Carl go through the patch
queue. Maybe http://patchwork.madduck.net can help.

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

beauty, brains, availability, personality; pick any two.

spamtraps: madduck.bogus@...

also sprach Scott Robinson <scott@...> [2010.02.02.1043 +1300]:
> > YES PLEASE . notmuch seems designed to work in an ecosystem of

Re: patchwork test instance (was: Git feature branch)

On Tue, 2 Feb 2010 11:31:12 +1300, martin f krafft <madduck@...> wrote:
> Arguably, being patch-centric means that a project has a higher
> barrier of entry, but it also means that if someone wants something,
> they know that they'll have to somehow end up with a patch. The way
> this happens on Git is that you either write it yourself and bring
> it up to discussion (which is what patchwork facilitates), or
> constructively theorise the functionality until someone else
> submits a patch.

And don't forget, if you really want something on the longterm todo
list, you can always send in a patch for the TODO file. ;)

--

-- 
- Marten