[notmuch] vim client

[Ben Gamari]

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