From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id AD16E431FBC for ; Thu, 25 Feb 2010 19:04:20 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=0.001] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA2cjGxAxvkU for ; Thu, 25 Feb 2010 19:04:19 -0800 (PST) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.144]) by olra.theworths.org (Postfix) with ESMTP id D2EBF431FAE for ; Thu, 25 Feb 2010 19:04:19 -0800 (PST) Received: by qw-out-1920.google.com with SMTP id 4so52070qwk.32 for ; Thu, 25 Feb 2010 19:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:cc:subject:from :to:in-reply-to:references:date:message-id:user-agent :content-transfer-encoding; bh=knhck9WkTAPMYd1D5SEHmO0FDIs9tbj7++6R2/PNFDE=; b=noOA7oYYRuIFk3ITYpzzHAyBd4YEDYgo6lEUqHG09S3mGIV0uaMvgdMeID1baI0mu7 K8IhroNvFWbY7aulK7Ywl4wLP99sF+jvUzoaY2WQGHvCEwe9I8IyJ23EPyYf+oJhuGhf w7JGXWB4tCFZDDMMk80P8Lt/TSWk1UFNcLy3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:cc:subject:from:to:in-reply-to:references:date :message-id:user-agent:content-transfer-encoding; b=JfU/FVNdg653aaq0pBiaQFSLZHZ6Ac+IZTl1mVgmA1n4WJr/jA4a71/OTOImAxeGPy +FbXQvIkt0bbzxj0z0++Lat1jmbBZJ7O4dCTY4chbG5jaojncu0Oj28ujwU2/hHeDLZ3 ZBM8CPfmNvrWzZEY8ApzElsNpNve0J73y28QQ= Received: by 10.224.43.136 with SMTP id w8mr122925qae.209.1267153455412; Thu, 25 Feb 2010 19:04:15 -0800 (PST) Received: from localhost (pool-96-236-125-203.spfdma.east.verizon.net [96.236.125.203]) by mx.google.com with ESMTPS id 22sm1570921qyk.6.2010.02.25.19.04.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Feb 2010 19:04:13 -0800 (PST) Content-Type: text/plain; charset=UTF-8 From: Ben Gamari To: Arian Kuschki In-reply-to: <20100225170330.GA12986@localhost> References: <20100219164924.GA17997@localhost> <1266684499-sup-8107@ben-laptop> <20100225170330.GA12986@localhost> Date: Thu, 25 Feb 2010 22:04:11 -0500 Message-Id: <1267152802-sup-7392@ben-laptop> User-Agent: Sup/git Content-Transfer-Encoding: 8bit Cc: notmuch Subject: Re: vim client X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 03:04:20 -0000 Excerpts from Arian Kuschki's message of Thu Feb 25 12:03:30 -0500 2010: > 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. The client currently processes search results so it can display only the desired fields in the results buffer. This would make the autoread option quite expensive. On the other hand, if you can think of a way to avoid preprocessing results, we could probably make it work. That being said, I think the correct solution is to simply give vim a more powerful subprocess system. I think this represents an important shortcoming of vim's current scripting environment. > > 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?)? > What do you mean by the vim philosophy? It wouldn't incorporate much additional complexity and you gain quite a bit of flexibility when you can decouple the subprocess life-cycle from the script's flow of execution. This was actually discussed[1] not so long ago on the vim list and a few people of unknown import seemed to support the idea of having more powerful subprocess infrastructure. I think it's pretty much just a matter of finding someone with some time to spare. > > 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. I agree that a notmuch frontend implemented in Python would be nice (although that might just be the result of my having effectively zero experience scripting with vim's native language). - Ben [1] http://article.gmane.org/gmane.editors.vim.devel/25108