unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Ben Gamari <bgamari@gmail.com>
To: Arian Kuschki <arian.kuschki@googlemail.com>
Cc: notmuch <notmuch@notmuchmail.org>
Subject: Re: vim client
Date: Thu, 25 Feb 2010 22:04:11 -0500	[thread overview]
Message-ID: <1267152802-sup-7392@ben-laptop> (raw)
In-Reply-To: <20100225170330.GA12986@localhost>

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

      reply	other threads:[~2010-02-26  3:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-19 16:49 vim client Arian Kuschki
2010-02-19 20:12 ` Ruben Pollan
2010-02-21  6:56   ` notmuch for mutt (was: vim client) martin f krafft
2010-02-21 11:42     ` Ruben Pollan
2010-02-20 17:34 ` vim client Ben Gamari
2010-02-25 17:03   ` Arian Kuschki
2010-02-26  3:04     ` Ben Gamari [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1267152802-sup-7392@ben-laptop \
    --to=bgamari@gmail.com \
    --cc=arian.kuschki@googlemail.com \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).