[ANN] New awesome vim plug-in using Ruby bindings

2012-05-02 Thread Anton Khirnov

On Mon, 23 Apr 2012 04:12:32 +0300, Felipe Contreras  wrote:
> Hi,
> 
> I've never been particularly happy with the code of the vim plug-in,
> but it sort of did the job, after some fixes, and has been working
> great so far for most of my needs even though it's clearly very rough
> on the edges.
> 
> However, I'm recently in need of been able to read HTML mails, and
> just trying to add that code was a nightmare, so I decided to look for
> alternatives, including Anton's Python vim plug-in (which is nice, but
> doesn't have support for that), and even learning emacs, to use what
> most people here use (but it turns out the HTML messages don't work
> correctly there either). I also tried the various mutt+notmuch
> options, and none fit the bill.
> 
> So, since I'm a big fan of Ruby, I decided to try my luck writing a
> plug-in from scratch. It took me one weekend, but I'm pretty happy
> with the result. This plug-in has already essentially all the
> functionality of the current one, but it's much, *much* simpler (only
> 600) lines of code.
> 
> And in addition has many more features:
> 
>  * Gradual searches; you don't have to wait for the whole search to finish,
>sort of like the 'less' command

How did you do that? When I tried to do this in my version, I got hit by
vim not being threadsafe.

-- 
Anton Khirnov


[RFC] vim plugin rewrite II

2012-05-02 Thread Anton Khirnov

Hi,
sorry for the late reply, I see you already reached the same point as
me, except with ruby ;) Yay for competition.

On Thu, 19 Apr 2012 19:36:56 +0300, Felipe Contreras  wrote:
> On Wed, Apr 18, 2012 at 5:42 PM, Felipe Contreras
>  wrote:
> > On Wed, Apr 18, 2012 at 5:21 PM, Felipe Contreras
> >  wrote:
> >> On Sat, Jan 14, 2012 at 9:54 AM, ? wrote:
> >>> branch vim. Simply copy vim/plugin/{nm_vim.py,notmuch-vimpy.vim} to the
> >>> vim plugins dir and vim/syntax/{nm_vimpy*} to the vim syntax dir and run
> >>> :NMVimpy() in vim. You'll need vim with python support and
> >>> python-notmuch bindings.
> >>
> >> I gave this a try, copying those files makes vim crash for me.
> >>
> >> I probably need to install notmuch's python bindings, but either way
> >> it shouldn't crash.
> >
> > All right, with the bindings it works, but if it cannot find the
> > database, it crashes too.
> >
> > And this slows by 5 times the startup time of vim for me:
> >
> > vim -c 'quit' ?0.47s user 0.02s system 99% cpu 0.501 total
> > vim -c 'quit' ?0.08s user 0.01s system 96% cpu 0.092 total
> >
> > It is interesting, but I personally I would not use if it's going to
> > slow vim for everything else, there must be a way to solve that. Also,
> > would be nice if you rebased your branch on top of the latest release.
> 
> I fixed the issue this way:
> 
> --- notmuch-vimpy.vim 2012-04-18 22:38:16.193358898 +0300
> +++ notmuch-vimpy-mod.vim 2012-04-19 17:07:19.390693437 +0300
> @@ -29,11 +29,7 @@
>  finish
>  endif
> 
> -" init the python layer
> -let s:python_path = expand(':p:h')
> -python import sys
> -exec "python sys.path += [r'" . s:python_path . "']"
> -python import vim, nm_vim
> +let s:notmuch_loaded = 1
> 
>  command! NMVimpy call NMVimpy()
> 
> @@ -815,7 +811,11 @@
>  " --- command handler {{{1
> 
>  function! NMVimpy()
> -call NM_cmd_folders(g:nm_vimpy_folders)
> + let s:python_path = expand(':p:h')
> + python import sys
> + exec "python sys.path += [r'" . s:python_path . "']"
> + python import vim, nm_vim
> + call NM_cmd_folders(g:nm_vimpy_folders)
>  endfunction
> 
>  "Custom foldtext() for show buffers, which indents folds to
> @@ -859,5 +859,3 @@
>  python nm_vim.vim_get_tags()
>  return prefix . substitute(taglist, "\n", "\n" . prefix, "g")
>  endfunction
> -
> -let s:notmuch_loaded = 1
> 

Thanks, looks good.

> I was seriously considering to concentrate on this plugin instead of
> the current one, but I'm afraid every little error causes a crash,
> even when a subprocess fails (e.g. msmtp), so it's not really usable
> for me. Not to mention that it's really hard to debug, because every
> bug causes a crash, and sometimes I get random crashes with no
> information about what caused it at all.
> 
> I am starting to work on a version that uses ruby, and it doesn't seem
> to have these issues, but lets see. I'm still not sure if we should
> depend on ruby/python bindings, maybe there's a way to make them
> optional.
> 
> Anyway, if you find a way to improve the crash issues, let me know, so
> far it's the only real issue I see with this plug-in.

That is weird, I'm not getting any crashes here. On any exception in the
python code it prints the backtrace and continues normally. I don't
think I've ever seen it actually crash (not counting my ultimately
unsuccessfull attempts at threading). I wonder what could cause this.

-- 
Anton Khirnov


[PATCH v2 0/6] Make notmuch_database_{open, create} return status codes

2012-05-02 Thread Tomi Ollila
On Mon, Apr 30 2012, Austin Clements  wrote:

> Relative to v1, this makes notmuch_database_open and
> notmuch_database_create gracefully handle a NULL out-argument and adds
> documentation of the possible error return values from these two
> functions.  Patches 3 and on have not changed.

LGTM. 

One question though:

In bindings/python/notmuch/database.py class Database functions
create() and open() have the following last lines:

+if status != STATUS.SUCCESS:
+raise NotmuchError(status)
+self._db = db
+return status

What is the point returning 'status' in the only case the
value is STATUS.SUCCESS -- is some caller interested on this ?

Tomi


[PATCH v2 0/6] Make notmuch_database_{open, create} return status codes

2012-05-02 Thread Austin Clements
Quoth Tomi Ollila on May 02 at 10:08 pm:
> On Mon, Apr 30 2012, Austin Clements  wrote:
> 
> > Relative to v1, this makes notmuch_database_open and
> > notmuch_database_create gracefully handle a NULL out-argument and adds
> > documentation of the possible error return values from these two
> > functions.  Patches 3 and on have not changed.
> 
> LGTM. 
> 
> One question though:
> 
> In bindings/python/notmuch/database.py class Database functions
> create() and open() have the following last lines:
> 
> +if status != STATUS.SUCCESS:
> +raise NotmuchError(status)
> +self._db = db
> +return status
> 
> What is the point returning 'status' in the only case the
> value is STATUS.SUCCESS -- is some caller interested on this ?

This was for consistency with other methods (e.g., begin_atomic also
only ever returns STATUS.SUCCESS).


[PATCH] configure: test shell parameter substring processing and possibly exec one

2012-05-02 Thread David Bremner


I'm still a bit leery of over-complicating the configure script to
support legacy /bin/sh; however, I guess I'm at least convinced that the
only trivial solution is just to document the requirement for posix
/bin/sh.  It will be odd to back this out and document the restriction
later, so please chime in now if you have strong feelings either way.

Tomi Ollila  writes:

> To tackle this situation the beginning of configure attemts to do a silent
> parameter substitution in a subshell; in case this fails the subshell exits
> with nonzero value which is easy to detect.

s/attemts/attempts/

> The || constructs are used twice. The first one is used as Bourne shell
> chokes on 'if ! ... ' construct (and if ...; then :; else do_things; fi
> looks stupid). The second one(liner) takes care of the possible future
> addition of 'set -eu' in the beginning of this script.

OK, although I might have gone for the empty if myself.

> +# If not, attempt to locate and launch one which probably can.

> +( option=option=value; : ${option#*=} ) 2>/dev/null || {

option=option=value seems a little _too_ clever to me. Any reason not to
use e.g. 

option="A,B" 

> +if test x"${_NOTMUCH_CONFIGURE-}" = x ; then
> + _NOTMUCH_CONFIGURE=1; export _NOTMUCH_CONFIGURE

This could probably use a comment.

> + for x in /bin/ksh /bin/bash /usr/bin/bash

I guess add /usr/local/bin/bash?  I'm slightly worried this list will
just keep growing.


[PATCH] emacs: Do not pass stderr of notmuch reply to JSON parser

2012-05-02 Thread Adam Wolfe Gordon
On Tue, May 1, 2012 at 3:10 PM, Michal Sojka  wrote:
> Sometimes, notmuch reply outputs something to stderr, for example:
> "Failed to verify signed part: Cannot verify multipart/signed part:
> unsupported signature protocol". When this happens, replying in emacs
> fails, because emacs cannot parse the error message as JSON.
>
> This patch causes emacs to ignore stderr when reading reply from
> notmuch.

LGTM, as I said in the other thread. Thanks for the fix.

-- Adam


Re: [PATCH] emacs: Do not pass stderr of notmuch reply to JSON parser

2012-05-02 Thread Adam Wolfe Gordon
On Tue, May 1, 2012 at 3:10 PM, Michal Sojka sojk...@fel.cvut.cz wrote:
 Sometimes, notmuch reply outputs something to stderr, for example:
 Failed to verify signed part: Cannot verify multipart/signed part:
 unsupported signature protocol. When this happens, replying in emacs
 fails, because emacs cannot parse the error message as JSON.

 This patch causes emacs to ignore stderr when reading reply from
 notmuch.

LGTM, as I said in the other thread. Thanks for the fix.

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


Re: [PATCH v2 0/6] Make notmuch_database_{open, create} return status codes

2012-05-02 Thread Tomi Ollila
On Mon, Apr 30 2012, Austin Clements amdra...@mit.edu wrote:

 Relative to v1, this makes notmuch_database_open and
 notmuch_database_create gracefully handle a NULL out-argument and adds
 documentation of the possible error return values from these two
 functions.  Patches 3 and on have not changed.

LGTM. 

One question though:

In bindings/python/notmuch/database.py class Database functions
create() and open() have the following last lines:

+if status != STATUS.SUCCESS:
+raise NotmuchError(status)
+self._db = db
+return status

What is the point returning 'status' in the only case the
value is STATUS.SUCCESS -- is some caller interested on this ?

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


Re: [RFC] vim plugin rewrite II

2012-05-02 Thread Anton Khirnov

Hi,
sorry for the late reply, I see you already reached the same point as
me, except with ruby ;) Yay for competition.

On Thu, 19 Apr 2012 19:36:56 +0300, Felipe Contreras 
felipe.contre...@gmail.com wrote:
 On Wed, Apr 18, 2012 at 5:42 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
  On Wed, Apr 18, 2012 at 5:21 PM, Felipe Contreras
  felipe.contre...@gmail.com wrote:
  On Sat, Jan 14, 2012 at 9:54 AM,  an...@khirnov.net wrote:
  branch vim. Simply copy vim/plugin/{nm_vim.py,notmuch-vimpy.vim} to the
  vim plugins dir and vim/syntax/{nm_vimpy*} to the vim syntax dir and run
  :NMVimpy() in vim. You'll need vim with python support and
  python-notmuch bindings.
 
  I gave this a try, copying those files makes vim crash for me.
 
  I probably need to install notmuch's python bindings, but either way
  it shouldn't crash.
 
  All right, with the bindings it works, but if it cannot find the
  database, it crashes too.
 
  And this slows by 5 times the startup time of vim for me:
 
  vim -c 'quit'  0.47s user 0.02s system 99% cpu 0.501 total
  vim -c 'quit'  0.08s user 0.01s system 96% cpu 0.092 total
 
  It is interesting, but I personally I would not use if it's going to
  slow vim for everything else, there must be a way to solve that. Also,
  would be nice if you rebased your branch on top of the latest release.
 
 I fixed the issue this way:
 
 --- notmuch-vimpy.vim 2012-04-18 22:38:16.193358898 +0300
 +++ notmuch-vimpy-mod.vim 2012-04-19 17:07:19.390693437 +0300
 @@ -29,11 +29,7 @@
  finish
  endif
 
 - init the python layer
 -let s:python_path = expand('sfile:p:h')
 -python import sys
 -exec python sys.path += [r' . s:python_path . ']
 -python import vim, nm_vim
 +let s:notmuch_loaded = 1
 
  command! NMVimpy call NMVimpy()
 
 @@ -815,7 +811,11 @@
   --- command handler {{{1
 
  function! NMVimpy()
 -call SIDNM_cmd_folders(g:nm_vimpy_folders)
 + let s:python_path = expand('sfile:p:h')
 + python import sys
 + exec python sys.path += [r' . s:python_path . ']
 + python import vim, nm_vim
 + call SIDNM_cmd_folders(g:nm_vimpy_folders)
  endfunction
 
  Custom foldtext() for show buffers, which indents folds to
 @@ -859,5 +859,3 @@
  python nm_vim.vim_get_tags()
  return prefix . substitute(taglist, \n, \n . prefix, g)
  endfunction
 -
 -let s:notmuch_loaded = 1
 

Thanks, looks good.

 I was seriously considering to concentrate on this plugin instead of
 the current one, but I'm afraid every little error causes a crash,
 even when a subprocess fails (e.g. msmtp), so it's not really usable
 for me. Not to mention that it's really hard to debug, because every
 bug causes a crash, and sometimes I get random crashes with no
 information about what caused it at all.
 
 I am starting to work on a version that uses ruby, and it doesn't seem
 to have these issues, but lets see. I'm still not sure if we should
 depend on ruby/python bindings, maybe there's a way to make them
 optional.
 
 Anyway, if you find a way to improve the crash issues, let me know, so
 far it's the only real issue I see with this plug-in.

That is weird, I'm not getting any crashes here. On any exception in the
python code it prints the backtrace and continues normally. I don't
think I've ever seen it actually crash (not counting my ultimately
unsuccessfull attempts at threading). I wonder what could cause this.

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


Re: [ANN] New awesome vim plug-in using Ruby bindings

2012-05-02 Thread Anton Khirnov

On Mon, 23 Apr 2012 04:12:32 +0300, Felipe Contreras 
felipe.contre...@gmail.com wrote:
 Hi,
 
 I've never been particularly happy with the code of the vim plug-in,
 but it sort of did the job, after some fixes, and has been working
 great so far for most of my needs even though it's clearly very rough
 on the edges.
 
 However, I'm recently in need of been able to read HTML mails, and
 just trying to add that code was a nightmare, so I decided to look for
 alternatives, including Anton's Python vim plug-in (which is nice, but
 doesn't have support for that), and even learning emacs, to use what
 most people here use (but it turns out the HTML messages don't work
 correctly there either). I also tried the various mutt+notmuch
 options, and none fit the bill.
 
 So, since I'm a big fan of Ruby, I decided to try my luck writing a
 plug-in from scratch. It took me one weekend, but I'm pretty happy
 with the result. This plug-in has already essentially all the
 functionality of the current one, but it's much, *much* simpler (only
 600) lines of code.
 
 And in addition has many more features:
 
  * Gradual searches; you don't have to wait for the whole search to finish,
sort of like the 'less' command

How did you do that? When I tried to do this in my version, I got hit by
vim not being threadsafe.

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


Re: [PATCH] configure: test shell parameter substring processing and possibly exec one

2012-05-02 Thread David Bremner


I'm still a bit leery of over-complicating the configure script to
support legacy /bin/sh; however, I guess I'm at least convinced that the
only trivial solution is just to document the requirement for posix
/bin/sh.  It will be odd to back this out and document the restriction
later, so please chime in now if you have strong feelings either way.

Tomi Ollila tomi.oll...@iki.fi writes:

 To tackle this situation the beginning of configure attemts to do a silent
 parameter substitution in a subshell; in case this fails the subshell exits
 with nonzero value which is easy to detect.

s/attemts/attempts/

 The || constructs are used twice. The first one is used as Bourne shell
 chokes on 'if ! ... ' construct (and if ...; then :; else do_things; fi
 looks stupid). The second one(liner) takes care of the possible future
 addition of 'set -eu' in the beginning of this script.

OK, although I might have gone for the empty if myself.

 +# If not, attempt to locate and launch one which probably can.

 +( option=option=value; : ${option#*=} ) 2/dev/null || {

option=option=value seems a little _too_ clever to me. Any reason not to
use e.g. 

option=A,B 

 +if test x${_NOTMUCH_CONFIGURE-} = x ; then
 + _NOTMUCH_CONFIGURE=1; export _NOTMUCH_CONFIGURE

This could probably use a comment.

 + for x in /bin/ksh /bin/bash /usr/bin/bash

I guess add /usr/local/bin/bash?  I'm slightly worried this list will
just keep growing.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v2 0/6] Make notmuch_database_{open, create} return status codes

2012-05-02 Thread Austin Clements
Quoth Tomi Ollila on May 02 at 10:08 pm:
 On Mon, Apr 30 2012, Austin Clements amdra...@mit.edu wrote:
 
  Relative to v1, this makes notmuch_database_open and
  notmuch_database_create gracefully handle a NULL out-argument and adds
  documentation of the possible error return values from these two
  functions.  Patches 3 and on have not changed.
 
 LGTM. 
 
 One question though:
 
 In bindings/python/notmuch/database.py class Database functions
 create() and open() have the following last lines:
 
 +if status != STATUS.SUCCESS:
 +raise NotmuchError(status)
 +self._db = db
 +return status
 
 What is the point returning 'status' in the only case the
 value is STATUS.SUCCESS -- is some caller interested on this ?

This was for consistency with other methods (e.g., begin_atomic also
only ever returns STATUS.SUCCESS).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch