1 Return-Path: <anton@khirnov.net>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id A7EC6431FAF
\r
6 for <notmuch@notmuchmail.org>; Wed, 2 May 2012 13:23:47 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id QH-oMbyueZDC for <notmuch@notmuchmail.org>;
\r
16 Wed, 2 May 2012 13:23:46 -0700 (PDT)
\r
17 Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz
\r
19 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id C7E14431FAE
\r
22 for <notmuch@notmuchmail.org>; Wed, 2 May 2012 13:23:45 -0700 (PDT)
\r
23 X-Envelope-From: anton@khirnov.net
\r
24 Received: from daenerys.khirnov.net (zohar.kolej.mff.cuni.cz [78.128.198.199])
\r
25 by smtp1.kolej.mff.cuni.cz (8.14.4/8.14.4) with ESMTP id
\r
26 q42KNeZe083184; Wed, 2 May 2012 22:23:41 +0200 (CEST)
\r
27 (envelope-from anton@khirnov.net)
\r
28 Received: from daenerys.khirnov.net (localhost [127.0.0.1])
\r
29 by daenerys.khirnov.net (Postfix) with ESMTP id 40707121840;
\r
30 Wed, 2 May 2012 22:23:40 +0200 (CEST)
\r
31 Content-Type: text/plain; charset="utf-8"
\r
33 Content-Transfer-Encoding: quoted-printable
\r
34 User-Agent: notmuch-vimpy
\r
35 Message-ID: <20120502202340.4214.21470@daenerys.khirnov.net>
\r
36 Date: Wed, 02 May 2012 22:23:40 +0200
\r
37 From: Anton Khirnov <anton@khirnov.net>
\r
38 To: Felipe Contreras <felipe.contreras@gmail.com>
\r
39 References: <20120114075443.27927.39754@daenerys.khirnov.net>
\r
40 <CAMP44s0h=RLNfcs-rLZofMVE88jgQ5KAnfsHNiK9snJi4ctmyw@mail.gmail.com>
\r
41 <CAMP44s26n0GgCf3nKawj52+aTFPFmPaA1K3sWLKSXv8KUcabOg@mail.gmail.com>
\r
42 <CAMP44s0dKJduJs=N-1OqMRZRGyB+GPQXWnbNwBnK0BH7RKxX_g@mail.gmail.com>
\r
44 <CAMP44s0dKJduJs=N-1OqMRZRGyB+GPQXWnbNwBnK0BH7RKxX_g@mail.gmail.com>
\r
45 Subject: Re: [RFC] vim plugin rewrite II
\r
46 Cc: notmuch@notmuchmail.org
\r
47 X-BeenThere: notmuch@notmuchmail.org
\r
48 X-Mailman-Version: 2.1.13
\r
50 List-Id: "Use and development of the notmuch mail system."
\r
51 <notmuch.notmuchmail.org>
\r
52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
53 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
55 List-Post: <mailto:notmuch@notmuchmail.org>
\r
56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
58 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
59 X-List-Received-Date: Wed, 02 May 2012 20:23:47 -0000
\r
63 sorry for the late reply, I see you already reached the same point as
\r
64 me, except with ruby ;) Yay for competition.
\r
66 On Thu, 19 Apr 2012 19:36:56 +0300, Felipe Contreras <felipe.contreras@gmai=
\r
68 > On Wed, Apr 18, 2012 at 5:42 PM, Felipe Contreras
\r
69 > <felipe.contreras@gmail.com> wrote:
\r
70 > > On Wed, Apr 18, 2012 at 5:21 PM, Felipe Contreras
\r
71 > > <felipe.contreras@gmail.com> wrote:
\r
72 > >> On Sat, Jan 14, 2012 at 9:54 AM, =C2=A0<anton@khirnov.net> wrote:
\r
73 > >>> branch vim. Simply copy vim/plugin/{nm_vim.py,notmuch-vimpy.vim} to t=
\r
75 > >>> vim plugins dir and vim/syntax/{nm_vimpy*} to the vim syntax dir and =
\r
77 > >>> :NMVimpy() in vim. You'll need vim with python support and
\r
78 > >>> python-notmuch bindings.
\r
80 > >> I gave this a try, copying those files makes vim crash for me.
\r
82 > >> I probably need to install notmuch's python bindings, but either way
\r
83 > >> it shouldn't crash.
\r
85 > > All right, with the bindings it works, but if it cannot find the
\r
86 > > database, it crashes too.
\r
88 > > And this slows by 5 times the startup time of vim for me:
\r
90 > > vim -c 'quit' =C2=A00.47s user 0.02s system 99% cpu 0.501 total
\r
91 > > vim -c 'quit' =C2=A00.08s user 0.01s system 96% cpu 0.092 total
\r
93 > > It is interesting, but I personally I would not use if it's going to
\r
94 > > slow vim for everything else, there must be a way to solve that. Also,
\r
95 > > would be nice if you rebased your branch on top of the latest release.
\r
98 > I fixed the issue this way:
\r
101 > --- notmuch-vimpy.vim 2012-04-18 22:38:16.193358898 +0300
\r
102 > +++ notmuch-vimpy-mod.vim 2012-04-19 17:07:19.390693437 +0300
\r
103 > @@ -29,11 +29,7 @@
\r
108 > -" init the python layer
\r
109 > -let s:python_path =3D expand('<sfile>:p:h')
\r
110 > -python import sys
\r
111 > -exec "python sys.path +=3D [r'" . s:python_path . "']"
\r
112 > -python import vim, nm_vim
\r
113 > +let s:notmuch_loaded =3D 1
\r
116 > command! NMVimpy call NMVimpy()
\r
119 > @@ -815,7 +811,11 @@
\r
120 > " --- command handler {{{1
\r
123 > function! NMVimpy()
\r
124 > - call <SID>NM_cmd_folders(g:nm_vimpy_folders)
\r
125 > + let s:python_path =3D expand('<sfile>:p:h')
\r
126 > + python import sys
\r
127 > + exec "python sys.path +=3D [r'" . s:python_path . "']"
\r
128 > + python import vim, nm_vim
\r
129 > + call <SID>NM_cmd_folders(g:nm_vimpy_folders)
\r
133 > "Custom foldtext() for show buffers, which indents folds to
\r
134 > @@ -859,5 +859,3 @@
\r
135 > python nm_vim.vim_get_tags()
\r
136 > return prefix . substitute(taglist, "\n", "\n" . prefix, "g")
\r
139 > -let s:notmuch_loaded =3D 1
\r
143 Thanks, looks good.
\r
145 > I was seriously considering to concentrate on this plugin instead of
\r
146 > the current one, but I'm afraid every little error causes a crash,
\r
147 > even when a subprocess fails (e.g. msmtp), so it's not really usable
\r
148 > for me. Not to mention that it's really hard to debug, because every
\r
149 > bug causes a crash, and sometimes I get random crashes with no
\r
150 > information about what caused it at all.
\r
153 > I am starting to work on a version that uses ruby, and it doesn't seem
\r
154 > to have these issues, but lets see. I'm still not sure if we should
\r
155 > depend on ruby/python bindings, maybe there's a way to make them
\r
159 > Anyway, if you find a way to improve the crash issues, let me know, so
\r
160 > far it's the only real issue I see with this plug-in.
\r
162 That is weird, I'm not getting any crashes here. On any exception in the
\r
163 python code it prints the backtrace and continues normally. I don't
\r
164 think I've ever seen it actually crash (not counting my ultimately
\r
165 unsuccessfull attempts at threading). I wonder what could cause this.
\r