vim client

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

Re: vim client

[Ruben Pollan]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

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@jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   La felicidad no es hacer lo que deseas
         es desear lo que haces.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: 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 for mutt (was: vim client)

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

also sprach Ruben Pollan <meskio@sindominio.net> [2010.02.19.2112 +0100]:
> > 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).

How would mutt support notmuch? Could you elaborate on the way you
plan to integrate them?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"it is easier to be a lover than a husband for the simple reason
 that it is more difficult to be witty every day
 than to say pretty things from time to time."
                                                   -- honoré de balzac
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: notmuch for mutt (was: vim client)

[Ruben Pollan]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On 07:56, Sun 21 Feb 10, martin f krafft wrote:
> also sprach Ruben Pollan <meskio@sindominio.net> [2010.02.19.2112 +0100]:
> > > 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).
> 
> How would mutt support notmuch? Could you elaborate on the way you
> plan to integrate them?

Ups. I see I explained it wrong. I started to create a ncurses client. I
didn't think about mutt.

I'm not sure if notmuch can be well integrated on mutt. They have kind of
different approach. Maybe the best way to integrate it is the notmuch-fuse that
someone propose a while ago in this list.


-- 
Rubén Pollán  | jabber:meskio@jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: 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: 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