DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	b=tVBRdwWEVB+jY2mxIBW8DfekcJMnEnbPBBxdEBE8IovvKtmRBT0tpyMQ4NKW2obaVA
	8qIRvCwefe1v6NZgNP+78llgAHJ5jfs/3aEFcHfpXfkB4M6MWO2khIIrvcQLRuTn9bQz
	4x9GFgKVtemEghkOmZDBTJAoEf9JQlM0JqVrk=
Date: Thu, 25 Feb 2010 18:03:30 +0100
From: Arian Kuschki <arian.kuschki@googlemail.com>
To: Ben Gamari <bgamari@gmail.com>
Message-ID: <20100225170330.GA12986@localhost>
References: <20100219164924.GA17997@localhost>
 <1266684499-sup-8107@ben-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1266684499-sup-8107@ben-laptop>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: notmuch <notmuch@notmuchmail.org>
Subject: Re: [notmuch] vim client
Precedence: list

On Sat 20, 12:34 -0500, Ben Gamari wrote:

> The real problem is all notmuch calls are synchronous. Vim unfortunately
> lacks the excellent asynchronous subprocess interface that emacs has.
> Therefore, I'm afraid the vim client is going to be just as unuable
> until someone has implemented asynchronous subprocess support.

What is the problem that you are trying to solve with asynchronous 
sub process support that you cannot solve with things like 
':!notmuch tag +sometag pattern &' or with using temp files and 
":autoread" for views that need to be updated regularly?
This is a genuine question, I am just not very knowledgeable about these 
technicalities.

Do you think improved sub process support will ever be merged into 
mainline vim seeing that is somewhat against the vim philosophy (or 
isn't it?)?

> and I would
> far prefer to use notmuch from within vim than from another specialized
> application.

I agree. I talked to Bart, the creator of the vim client and he said he 
was planning to resume his work on it in April at the earliest. I would 
really like to see a usable client before that, and I don't think there 
is that much to do to make that happen really. There is lots of existing 
code we can use for things like json parsing and handling MIME stuff in 
the python standard libraries for example. If anybody wants to fork Bart's repo I would 
be happy to submit patches and test , but I lack the qualification to 
maintain a fork myself unfortunately.