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