[ANN] New awesome vim plug-in using Ruby bindings
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
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
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
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
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.
Re: [PATCH v2 0/6] Make notmuch_database_{open, create} return status codes
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). ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: test shell parameter substring processing and possibly exec one
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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANN] New awesome vim plug-in using Ruby bindings
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] vim plugin rewrite II
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
___
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
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Do not pass stderr of notmuch reply to JSON parser
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
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
