[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

[notmuch] vim client

[Arian Kuschki]

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.

Re: [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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] vim client

[Ben Gamari]

Excerpts from Arian Kuschki's message of Fri Feb 19 11:49:25 -0500 2010:
 Hi all
 thank you for notmuch, it is a great project. I have been watching 
 progress for a while but then I could no longer restrain myself and 
 started using notmuch's vim client even though it is still a bit rough 
 around the edges. Unfortunately there are some quirks that 
 prevent me from switching over completely. 
 questions:
 
 1. will there be a usable  ncurses or mutt version that supports notmuch 
 anytime soon?

Not that I know of. I've thought of starting something before. I really
want to start using notmuch full-time myself, but I agree, the vim
client is far from usable.

 2. is anybody working on the vim client? I have a small patch and might 
 have couple more as time passes. Is this mailing list the right place to 
 discuss this? From what I can gather the discussion seems to be centred 
 mainly on the emacs client.

I don't believe there is anyone working actively on the vim frontend at
the moment. I looked at it not so long ago and the code is pretty good.
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.

I have a tree starting this sitting around somewhere, but it still has a
ways to go and I won't have time to finish until midterms are over at
the earliest. If someone else wants to take a stab at it, the code is
available git://goldnerlab.physics.umass.edu/vim7.git (the async-process
branch). I'd love to know if anyone makes any progress and I'll keep you
all in the loop if I find any time to invest in it.

I have considered starting work on an ncurses frontend, but I think
ultimately that time would be better used in working on the async vim
code. Vim gives us a whole lot of functionality for free that would take
time to get working on a new ncurses client (e.g. windowing) and I would
far prefer to use notmuch from within vim than from another specialized
application.

Cheers,

- Ben
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] vim client

[Ruben Pollan]

On 17:49, Fri 19 Feb 10, Arian Kuschki wrote:
> 1. will there be a usable  ncurses or mutt version that supports notmuch 
> anytime soon?

I started to work on that I while ago. I didn't hack on it for a while, but I
hope I'll return to it soon. Anyway to create a proper good client is a lot of
work, I don't think I'll be able to make something usable in months (if I ever
make it).

If someone is willing to work on that I'll love to collaborate and hack
together.

-- 
Rub?n Poll?n  | jabber:meskio at jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   La felicidad no es hacer lo que deseas
 es desear lo que haces.

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 

[notmuch] vim client

[Arian Kuschki]

Hi all
thank you for notmuch, it is a great project. I have been watching 
progress for a while but then I could no longer restrain myself and 
started using notmuch's vim client even though it is still a bit rough 
around the edges. Unfortunately there are some quirks that 
prevent me from switching over completely. 
questions:

1. will there be a usable  ncurses or mutt version that supports notmuch 
anytime soon?

2. is anybody working on the vim client? I have a small patch and might 
have couple more as time passes. Is this mailing list the right place to 
discuss this? From what I can gather the discussion seems to be centred 
mainly on the emacs client.

Cheers
Arian

[notmuch] vim client

[Arian Kuschki]

Hi all
thank you for notmuch, it is a great project. I have been watching 
progress for a while but then I could no longer restrain myself and 
started using notmuch's vim client even though it is still a bit rough 
around the edges. Unfortunately there are some quirks that 
prevent me from switching over completely. 
questions:

1. will there be a usable  ncurses or mutt version that supports notmuch 
anytime soon?

2. is anybody working on the vim client? I have a small patch and might 
have couple more as time passes. Is this mailing list the right place to 
discuss this? From what I can gather the discussion seems to be centred 
mainly on the emacs client.

Cheers
Arian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] vim client

[Ruben Pollan]

On 17:49, Fri 19 Feb 10, Arian Kuschki wrote:
 1. will there be a usable  ncurses or mutt version that supports notmuch 
 anytime soon?

I started to work on that I while ago. I didn't hack on it for a while, but I
hope I'll return to it soon. Anyway to create a proper good client is a lot of
work, I don't think I'll be able to make something usable in months (if I ever
make it).

If someone is willing to work on that I'll love to collaborate and hack
together.

-- 
Rubén Pollán  | jabber:mes...@jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   La felicidad no es hacer lo que deseas
 es desear lo que haces.



signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch