[alot] announcing v0.10

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.10; You can get a tarball here [0].

This release contains the usual minor usability improvements and is the first
to rely purely on the new cffi python bindings (available under
notmuch/bindings/python-cffi and know to python as notmuch2).
Many thanks to Frank Lenormand for the initial patchset and to Floris
Bruynooghe and Michael J Gruber for subsequent fixes.

As mentioned in the updated docs and in line with the main notmuch project,
we have now moved our IRC channel to the Libera.chat network.

Unfortunately our Travis CI setup broke recently and since it's on the way out 
anyway
I did not bother to fix this and disabled CI for now. If anyone has experience
with setting up pytest and GitHub Actions please step forward now :)


Usage updates since v0.9:
* various fixes with mailcap handling
* info: alot now depends on the new-style cffi bindings (notmuch2, available 
under notmuch/bindings/python-cffi)
* config: new option search_threads_rebuild_limit (to speed up "move last" in 
large search buffers)


As usual, a quick hall of fame of recent contributors:
$ git shortlog -s -n 0.9...
26  Patrick Totzke
15  Frank LENORMAND
 9  ryneeverett
 7  Kevin Velghe
 6  Lucas Hoffmann
 5  Matthew Richardson
 5  pacien
 3  Michael J Gruber
 2  Mārtiņš Mačs
 2  Samuel Trégouët
 1  Andreas Rammhold
 1  Antoine Tenart
 1  Floris Bruynooghe
 1  Gaute Hope
 1  Jordan Justen
 1  Totzke, Patrick
 1  atrent


New bug reports, feature or pull requests via the projects github page [1]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.10
[1]: https://github.com/pazz/alot
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: announce: my fork of alot

[Patrick Totzke]

```
[~] git clone https://git.khirnov.net/alot.git 
Cloning into 'alot'...
fatal: unable to access 'https://git.khirnov.net/alot.git/': server certificate 
verification failed. CAfile: none CRLfile: none
[~] git clone git://git.khirnov.net/alot.git

Cloning into 'alot'...

(times out)
```



Quoting Patrick Totzke (2021-05-16 19:23:58)

> Quoting Anton Khirnov (2021-05-16 18:47:24)
> 
> > Quoting Patrick Totzke (2021-05-16 17:41:49)
> > > Hi everyone,
> > > 
> > > All this sounds very exciting and I'd be very happy to see these features 
> > > in
> > > (mainline) alot!
> > > 
> > > I agree that some of alot's underlying code is ready for refactoring
> > > and urwid in particular has been a big drag on quickly implementing 
> > > things.
> > > Also, I'd be interested in hearing your thoughts on deprecating some 
> > > "unworthy"
> > > features in order to reduce the maintenance effort!
> > 
> > That is largely a matter of perspective and personal preference. E.g.
> > among the things gone in my tree are:
> > - removing messages - I dropped that because I considered that code
> >   potentially dangerous, had no use for it myself, and just didn't want
> >   to tiptoe around it; someone actually using RemoveCommand in their
> >   workflow would have a different opinion
> 
> Yep, same here. I never used that.
> 
> > - switching to split-window layout for thread view made it simpler to
> >   implement quote folding, but also made sense to me since I never want
> >   to see more than one message at once;
> >   again, someone who prefers collapsing messages would see this as loss
> >   of functionality
> > 
> > https://xkcd.com/1172/ is very much in effect
> 
> This could have been easily introduced as a separate type of buffer to keep 
> both variants
> without breaking things.
> 
> 
> > > > > Why did I not submit all this as PRs to upstream alot? The main 
> > > > > reasons
> > > > > were my lack of time and disagreement with the upstream about project
> > > > > status. From what I can tell, alot maintainers consider the project to
> > > > > be mature, so they prioritize stability and small incremental changes.
> > > > > From my perspective, alot is lacking some critical features -- some
> > > > > implemented in my fork already, some planned -- which makes it
> > > > > borderline-unusable for me. As implementing those features required
> > > > > large-scale architectural changes and my free time was quite limited, 
> > > > > I
> > > > > prioritized quickly implementing the things I cared about over
> > > > > progressing in small incremental stable easily-reviewable steps.
> > > > 
> > > > I have a similar impression about the project status. I'm curious: What
> > > > are the architectural changes that you made?
> > > 
> > > 
> > > Yes, the speed at which alot progresses is borderline problematic. This 
> > > is of
> > > course down to the small number of core contributors and the fact that 
> > > for all
> > > of us life goes on an priorities change.
> > > 
> > > One problem is that the project attracts many users interested in pushing 
> > > what
> > > I'd call "hotfixes" to address missing features: Often people would 
> > > present
> > > a (nicely working) proof-of concept that is not well documented, tested, 
> > > and
> > > doesn't adhere to common code conventions, only not to follow up on their
> > > promises to "clean things up", for all too understandable reasons.
> > > Still, I believe that just merging everything will quickly kill the 
> > > project as
> > > a) this leads to code that is very difficult and time-consuming to 
> > > maintain and
> > > b) broken features are very damaging to user's perception of the 
> > > software, much
> > > more so than missing ones.
> > > 
> > > I am not accusing you of anything here, Anton. I just wish to point out
> > > potential long term difficulties and clarify that I tried to err on the 
> > > side of
> > > cautiousness to keep alot afloat in a usable state for most (potential) 
> > > users.
> > 
> > You would be very correct to accuse me of taking various shortcuts. I
> > would not call my changes "hotfixes", as I tried to keep continuous
> > future improvements in

Re: announce: my fork of alot

[Patrick Totzke]

Hi everyone,

Of course I feel obliged to chime in and clarify, so here it goes.


Quoting Michael J Gruber (2021-05-16 12:15:28)

> Anton Khirnov venit, vidit, dixit 2021-05-16 12:19:45:
> > Hi,
> > 
> > Thought I'd share with the people here the fork of alot I've been
> > hacking on for the past ~1.5 years, see if there is any interest in it.
> 
> Thanks for sharing!

First of all many thanks to Anton for his enthusiasm in pushing the alot
project further!

 
> > The code can be found at git://git.khirnov.net/alot.
> 
> Any particular reason why this is not a fork where upstream is (GitHub)?
>  
> > There are many changes in various places, the most user-visible ones in
> > the thread view mode. Specifically
> > - quoted blocks in the email body can now be colored and folded (this
> >   was probably my main motivation for starting all this)
> > - in upstream the thread mode shows a tree of messages, each node in the
> >   tree is a rendered message, that can be collapsed into a single-line
> >   summary;
> >   in my fork the thread mode is split-window - upper window for the tree
> >   with the thread structure, lower window for the currently selected
> >   message; no collapsing of messages
> > - attachments can be rendered inline, possibly colored with pygments
> > - git patches are colored with pygments
> > - all the parts are rendered for multipart/mixed messages, as per the
> >   RFCs
> > - encrypted/signed parts are now wrapped in a frame that indicates which
> >   bits of the message are actually encrypted or signed
> > - various architectural restructurings which were needed for the above
> >   or to allow for future changes (I have a large TODO list left)
> 
> This all sounds like getting closer to mutt's view, which is not a bad
> thing at all!
> 
> > The code is currently alpha quality - I am using it as my main MUA and
> > it works for my workflow, but any features I don't use regularly may be
> > broken. There is a general lack of "UX" polish (appearance and
> > documentation). I didn't bother updating the test suite to keep up with
> > all the architectural changes (plan to get to that once I consider the
> > code more stable).
> 
> I have to question this strategy. alot (upstream) suffers from a lack of
> tests already. There is really no point writing tests after the fact or
> once you discover bugs by chance. Especially if you go for "disruptive"
> changes it's important to get the new architecture correct right from
> the beginning.
> 
> > I removed some features which I considered an
> > impediment to progress and not worth the maintenance effort - YMMV.

All this sounds very exciting and I'd be very happy to see these features in
(mainline) alot!

I agree that some of alot's underlying code is ready for refactoring
and urwid in particular has been a big drag on quickly implementing things.
Also, I'd be interested in hearing your thoughts on deprecating some "unworthy"
features in order to reduce the maintenance effort!


> > Why did I not submit all this as PRs to upstream alot? The main reasons
> > were my lack of time and disagreement with the upstream about project
> > status. From what I can tell, alot maintainers consider the project to
> > be mature, so they prioritize stability and small incremental changes.
> > From my perspective, alot is lacking some critical features -- some
> > implemented in my fork already, some planned -- which makes it
> > borderline-unusable for me. As implementing those features required
> > large-scale architectural changes and my free time was quite limited, I
> > prioritized quickly implementing the things I cared about over
> > progressing in small incremental stable easily-reviewable steps.
> 
> I have a similar impression about the project status. I'm curious: What
> are the architectural changes that you made?


Yes, the speed at which alot progresses is borderline problematic. This is of
course down to the small number of core contributors and the fact that for all
of us life goes on an priorities change.

One problem is that the project attracts many users interested in pushing what
I'd call "hotfixes" to address missing features: Often people would present
a (nicely working) proof-of concept that is not well documented, tested, and
doesn't adhere to common code conventions, only not to follow up on their
promises to "clean things up", for all too understandable reasons.
Still, I believe that just merging everything will quickly kill the project as
a) this leads to code that is very difficult and time-consuming to maintain and
b) broken features are very damaging to user's perception of the software, much
more so than missing ones.

I am not accusing you of anything here, Anton. I just wish to point out
potential long term difficulties and clarify that I tried to err on the side of
cautiousness to keep alot afloat in a usable state for most (potential) users.

> > At this point my tree has over 200 new commits and some ~4k changed
> > 

Re: notmuch2 (python cffi bindings) segfault gdb logs

[Patrick Totzke]

Hello Floris, thanks for having a look at this!


Quoting Floris Bruynooghe (2020-11-24 21:31:00)

> Hi Patrick,
> 
> On Mon 23 Nov 2020 at 10:36 +, Patrick Totzke wrote:
> > I've been complaining about the new (and old) python bindings causing the 
> > python interpreter to segfault occasionally. So far I was not able to 
> > reproduce this reliably nor provide error traces. This has just changed:
> > see below and attached for what I got from gdb.
> 
> Your gdb info doesn't say explicitly (or I missed it), but this is
> showing a SEGFAULT I guess?

Yes, correct. I saw this triggered when untagging some messages from my inbox 
in alot.
I forgot to mention version numbers: 

notmuch: 0.31+7~g981d5a0
Python: 3.8.6
alot: 0.9.1

notmuch and bindings are compiled from git master, on a debian testing system.


> > I hope that whoever is in charge of the bindings can make sense of
> > it. I don't have any experience so far with cffi nor gdb and have a
> > hard time debugging this. The logs below are my attempt to collect as
> > much detail as possible about. Please let me know if I missed
> > something.
> 
> From what I can tell we're calling a function to free something which
> segfaults, so it probably was freed already and we didn't know.  We need
> to find out who freed it before and why we thought it still needed to be
> freed.
 

It may help to know that this only ever happened if i tagged messages while the 
alot screen did not display the whole query result.
I presume that this means there was some left over reference to an existing 
query object, which could have been affected by libtalloc.

Alot is reading thread id's from notmuch2.Database.threads() in a generator:
https://github.com/pazz/alot/blob/master/alot/db/manager.py#L314
Could this be problematic? After all, it may continue reading from it after a 
while.


> > (gdb) info threads
> >   Id   Target Id Frame 
> > * 1Thread 0x77c0e740 (LWP 3614451) "python3" __GI_raise 
> > (sig=sig@entry=6)
> > at ../sysdeps/unix/sysv/linux/raise.c:50
> 
> From this I gather we only have one thread, could you confirm this?
> notmuch2 just isn't thread safe at the moment (I forget whether this was
> intentional or by accident, might have been intentional depending on how
> threadsafe libnotmuch is).


Yes, I'm quite -- but not 100% --- sure as I did not write the port to notmuch2 
for alot's backend.


> > Traceback (most recent call first):
> >> 0x7636f040>
> >   File "/home/pazz/.local/lib/python3.8/site-packages/notmuch2/_thread.py", 
> > line 38, in _destroy
> > capi.lib.notmuch_thread_destroy(self._thread_p)
> >   File "/home/pazz/.local/lib/python3.8/site-packages/notmuch2/_thread.py", 
> > line 34, in __del__
> > self._destroy()
> >   File "/home/pazz/projects/alot/alot/db/manager.py", line 570, in 
> > get_threads
> >   
> 
> I pulled alot master and this does not match at all.  Could you tell me
> which git ref this was using so I can try and see what alot is actually
> doing?  (or some other way of sharing the source in this backtrace)


This happed on alot master: 7915ea60ba866010abc728851626df96d8b80816 for me.
I should say that I've had this issue long before, even before alot used the 
new bindings.

Another stab in the dark: Could this be due to concurrent changes to the 
notmuch index in my mail sync/tagging script?
I am using afew https://github.com/afewmail/afew which is still on the old 
python bindings as far as I am aware.

Thanks again for your efforts Floris!
P
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

notmuch2 (python cffi bindings) segfault gdb logs

[Patrick Totzke]

Hi!

I've been complaining about the new (and old) python bindings causing the 
python interpreter to segfault occasionally. So far I was not able to reproduce 
this reliably nor provide error traces. This has just changed:
see below and attached for what I got from gdb.

I hope that whoever is in charge of the bindings can make sense of it. I don't 
have any experience so far with cffi nor gdb and have a hard time debugging 
this. The logs below are my attempt to collect as much detail as possible 
about. Please let me know if I missed something.

Cheers!
P



--

(gdb) bt

... see attachment bt 

--

Some context?

(gdb) up
#1  0x77c36537 in __GI_abort () at abort.c:79
79  abort.c: No such file or directory.

(gdb) up
#2  0x766b5551 in ?? () from /usr/lib/x86_64-linux-gnu/libtalloc.so.2

(gdb) up
#3  0x766c7a6b in _cffi_f_notmuch_thread_destroy (self=, 
arg0=) at build/temp.linux-x86_64-3.8/notmuch2._capi.c:4826
4826build/temp.linux-x86_64-3.8/notmuch2._capi.c: No such file or directory.

(gdb) up
#4  0x00519b0b in cfunction_vectorcall_O (
func=, args=, nargsf=, 
kwnames=)
at ../Objects/methodobject.c:482
482 ../Objects/methodobject.c: No such file or directory.

(gdb) up
#5  0x0050a557 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, 
args=0x74aa4ec0, 
callable=) at ../Include/cpython/abstract.h:127
127 ../Include/cpython/abstract.h: No such file or directory.

(gdb) up
#6  call_function (kwnames=0x0, oparg=, pp_stack=, 
tstate=0x9241a0) at ../Python/ceval.c:4963
4963../Python/ceval.c: No such file or directory.

(gdb) up
#7  _PyEval_EvalFrameDefault (f=, throwflag=)
at ../Python/ceval.c:3469
3469in ../Python/ceval.c

(gdb) up
#8  0x0051ad20 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x74aa4d40, for file 
/home/pazz/.local/lib/python3.8/site-packages/notmuch2/_thread.py, line 38, in 
_destroy (self=, __module__='notmuch2._database', __doc__='An 
enumeration.', _member_names_=['READ_ONLY', 'READ_WRITE'], 
_member_map_={'READ_ONLY': <...>, 'READ_WRITE': ) at remote 0x75480a30>}, 
_member_type_=, _value2member_map_={0: <...>, 1: 
<...>}, READ_ONLY=<...>, READ_WRITE=<...>, __new__=) at remote 0xd59c20>) at remote 0x76380760>, 
_memptr__db_p_d5c090=<_cffi_backend.CData at remote 0x74afd930>, 
closed=False) at remote 0x74afd5b0>, _parent=, 
_memptr__query_p_d591c0=<_cffi_backend.CData at remote 0x74afdae0>) at 
remote 0x74afd9a0>, _memptr__iter_p_d4a9d0=<_cffi_backend.CData at 
rem...(truncated)) at ../Python/ceval.c:741
741 ../Python/ceval.c: No such file or directory.

(gdb) up
#9  function_code_fastcall (globals=, nargs=1, args=, 
co=) at ../Objects/call.c:283
283 ../Objects/call.c: No such file or directory.

(gdb) up
#10 _PyFunction_Vectorcall (func=, stack=, 
nargsf=, kwnames=) at ../Objects/call.c:410
410 in ../Objects/call.c

(gdb) up
#11 0x00505a6c in _PyObject_Vectorcall (kwnames=0x0, nargsf=, 
args=0x74aa4d18, callable=)
at ../Include/cpython/abstract.h:127
127 ../Include/cpython/abstract.h: No such file or directory.

(gdb) up
#12 call_function (kwnames=0x0, oparg=, pp_stack=, 
tstate=0x9241a0) at ../Python/ceval.c:4963
4963../Python/ceval.c: No such file or directory.

(gdb) up
#13 _PyEval_EvalFrameDefault (f=, throwflag=)
at ../Python/ceval.c:3486
3486in ../Python/ceval.c

(gdb) up
#14 0x0051ad20 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x74aa4ba0, for file 
/home/pazz/.local/lib/python3.8/site-packages/notmuch2/_thread.py, line 34, in 
__del__ (self=, __module__='notmuch2._database', __doc__='An 
enumeration.', _member_names_=['READ_ONLY', 'READ_WRITE'], 
_member_map_={'READ_ONLY': <...>, 'READ_WRITE': ) at remote 0x75480a30>}, 
_member_type_=, _value2member_map_={0: <...>, 1: 
<...>}, READ_ONLY=<...>, READ_WRITE=<...>, __new__=) at remote 0xd59c20>) at remote 0x76380760>, 
_memptr__db_p_d5c090=<_cffi_backend.CData at remote 0x74afd930>, 
closed=False) at remote 0x74afd5b0>, _parent=, 
_memptr__query_p_d591c0=<_cffi_backend.CData at remote 0x74afdae0>) at 
remote 0x74afd9a0>, _memptr__iter_p_d4a9d0=<_cffi_backend.CData at 
remo...(truncated)) at ../Python/ceval.c:741
741 ../Python/ceval.c: No such file or directory.


--
(gdb) frame
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  in ../sysdeps/unix/sysv/linux/raise.c

--


(gdb) info-signals

... see attachment info-signals


--

(gdb) py-bt

... see attachment py-bt

--

(gdb) py-print
Unable to read information on python frame


--

(gdb) py-locals
Unable to read information on python frame


--

(gdb) info threads
  

Re: python/notmuch2 on PyPI

[Patrick Totzke]

Hi everyone,

First off, thanks for your work on notmuch2, Floris!

Just to clarify: alot does not, and will not, depend on packages being on PyPI
and is not intended to be installed through pip. I simply don't want to provide
support for this.

This said, I don't think it is difficult to automate pypi uploads and it cannot
hurt to have an "official" release up there instead of several unmaintained
corpses over the years.

Cheers,
P



Quoting Floris Bruynooghe (2020-06-19 11:35:42)

> Hi Thore, notmuch folks,
> 
> I noticed that Thore published notmuch2 on PyPI.  I think this is
> because alot needs it's users to be able to pull it in as a dependency
> using the normal Python mechanisms?
> 
> It seems this is currently published from a fork at
> https://github.com/weilbith/notmuch2-python-bindings and I wondered if
> it was possible to publish this directly from the main notmuch repo or
> even integrate this into the normal notmuch release process.  What are
> the pros and cons of this?  Is it a bad idea to tie these two publishing
> mechanisms too close together?  To difficult to do bugfix releases?  Is
> it too hard to make pypi publishing frictionless enough for the main
> release process?
> 
> An cool stretch goal would be to publish manylinux wheels with the
> library included.  But let's not get too hung up on that, small steps
> are great.
> 
> Cheers,
> Floris
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[alot] announcing v0.9.1

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.9.1; You can get it via the github repository here 
[0].

There were several cool new features including, finally, a way to display and 
manipulate message MIME structure.
We've included a bunch of bug fixes and patches that make alot more in line 
with the steadily maturing email library from pythons standard lib.

Usage updates since v0.9:
* focus in search mode is preserved when refreshing
* feature: new 'togglemimepart' cmd in thread mode toggles between plain and 
html alternative
* feature: add "togglemimetree" command to thread mode
* envelope mode: "unattach" command is now "detatch"
* feature: respect mailcap entry for text/plain to enrich plain text parts with 
ANSI codes

As usual, a quick hall of fame of recent contributors:
$ git shortlog -s -n 0.9...
12  Patrick Totzke
 8  ryneeverett
 6  Lucas Hoffmann
 5  pacien
 2  Samuel Trégouët
 1  Andreas Rammhold
 1  Antoine Tenart
 1  Frank LENORMAND
 1  Gaute Hope
 1  Jordan Justen
 1  Mārtiņš Mačs

New bug reports, feature or pull requests via the projects github page [0] are 
always welcome.

Cheers,
P


[0]: https://github.com/pazz/alot
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[alot] announcing v0.9

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.9; You can get a tarball here [0].

Again there were mostly under-the-hood fixes and refactoring.
The most significant new feature set is the ability to send HTML emails,
which works quite nicely in combination with pandoc [1] as documented here [2].

Usage updates since v0.8:
* feature: interpret ANSI escape codes (e.g.for colours) when displaying 
messages
* config: configure message-id domains for each account
* feature: new envelope commands txt2html, html2txt, removehtml
* info: updated signature of hooks 'reply_prefix' and 'forward_prefix', now 
include a named parameter for the message being replied/forwarded

As usual, a quick hall of fame of recent contributors:
$ git shortlog -s -n 0.7...
90  Patrick Totzke
13  Lucas Hoffmann
 8  Dylan Baker
 5  Michael J Gruber
 5  pacien
 4  Pol Van Aubel
 2  Will Dietz
 1  Andres MRM
 1  Andrés Martano
 1  Caio Prado
 1  Daniel M. Capella
 1  Felix Yan
 1  Guillaume Seren
 1  Jordan Justen
 1  Matthieu Coudron
 1  Nick Hu
 1  Ruben Pollan
 1  brady
 1  sgelb


New bug reports, feature or pull requests via the projects github page [3]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.9
[1]: https://pandoc.org
[2]: https://github.com/pazz/alot/wiki/HTML-mails
[3]: https://github.com/pazz/alot
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[alot] announcing v0.8

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.8; You can get a tarball here [0].

This version finally pushes some long awaited major refactoring,
most of which is due to Dylan Baker (dcbaker). Thanks!

It is our first python 3 release; version 2.* is not supported any more!
We've also dropped the dependency on twisted completely in favour of python's
built-in coroutines. On top of that comes the usual ton of extra bug fixes,
new tests and some new features (see below).

Usage updates since v0.7:
* Port to python 3. Python 2.x no longer supported
* support for notmuch's named queries. This adds a new 'namedqueries' mode and
  accompanied commands
* config: new option replied_tags
* config: new option passed_tags
* feature: new command "retagprompt" in thread buffers
* extra: update zsh completion

A quick hall of fame of recent contributors:
$ git shortlog -s -n 0.7...
   167  Dylan Baker
83  Patrick Totzke
25  Lucas Hoffmann
11  Ben Finney
 9  Alexander Shpilkin
 9  Michael J Gruber
 4  Johannes Löthberg
 3  Daniel M. Capella
 3  Ruben Pollan
 3  vrs
 1  Andre Bianchi
 1  Matthieu Coudron

New bug reports, feature or pull requests via the projects github page [1]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.8
[1]: https://github.com/pazz/alot
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[alot] announcing v0.7

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.7; You can get a tarball here [0].
The release mostly contains bugfixes and extended tests.

This will be our last python2 release!

Development will move shortly to python3, which will most likely introduce some
new bugs in the transition phase. So those of you interested in the most
stable version should stick to this release.

Usage updates since v0.6:
* info: missing html mailcap entry now reported as mail body text
* feature: Allow regex special characters in tagstrings
* feature: configurable thread mode message indentation
* new thread buffer command "indent" (bound to '[' and ']')
* config: new option thread_indent_replies
* config: new option exclude_tags
* config: new option encrypt_to_self
* config: update behaviour of encrypt_by_default

As usual, a quick hall of fame of recent contributors:
$ git shortlog -s -n 0.6...
52  Dylan Baker
46  Patrick Totzke
24  Julian Mehne
14  Lucas Hoffmann
 6  Martin Schaaf
 4  Ruben Pollan
 3  Thomas Nixon
 1  Christian Geier
 1  Guillaume Seren
 1  Johannes Löthberg
 1  Yuri Subach

New bug reports, feature or pull requests via the projects github page [1]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.7
[1]: https://github.com/pazz/alot


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

Re: DRAFT Introduce CFFI-based Python bindings

[Patrick Totzke]

Quoting David Bremner (2017-11-28 23:59:26)
> Floris Bruynooghe  writes:
> 
> >
> > Lastly there are some downsides to the choices I made:
> > - I ended up going squarely for CPython 3.6+.  Choosing Python
> >   3 allowed better API design, e.g. with keyword-only parameters
> >   etc.  Choosing CPython 3.4+ restricts the madness that can
> >   happen with __del__ and gives some newer (tho now unused)
> >   features in weakref.finalizer.
> > - This is no longer drop-in compatible.
> > - I haven't got to a stage where my initial goal of speed has
> >   been proven yet.
> 
> I guess you'll have to convince the maintainers / users of alot and afew
> that this makes sense before we go much further. I'd point out that
> Debian stable is only at python 3.5, so that makes me a bit wary of this
> (being able to run the test suite on debian stable and similar aged
> distros useful for me, and I suspect other developers).
> 
> I know there are issues with memory management in the current bindings,
> so that may be a strong reason to push to python 3.6; it seems to need
> more investigation at the moment.
> 
> d


I am generally in favour of modernizing the notmuch python bindings,
especially when it comes to memory management and exception handling.

At the moment, the alot interface officially only supports python v2.7
but our dependencies have now mostly been updated and we are working on
port to python 3, see here: https://github.com/pazz/alot/pull/1055

@Floris, you are welcome to join #alot on freenode if you want to
discuss details on that.

You mention that your new API breaks compatibility with the existing
ones. Do you have some demo code that uses the new API for reference?

Cheers,
P


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

[alot] announcing v0.6

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.6; You can get a tarball here [0].

This release includes a few nice usability features and adds many tests.
It also marks our move away from pygpgme (now out-phased in debian) towards 
python-gpg.

Usage updates since v0.5:
* feature: Add command to reload configuration files in running session
* feature: new command "tag" (and friends) in EnvelopeBuffer to add additional 
tags after sending
* feature: Themes can now be loaded from system locations
* bug fix: GPG signatures are acutally verified
* feature: option to use linewise focussing in thread mode
* feature: add support to move to next or previous message matching a notmuch 
query in a thread buffer
* feature: Convert from deprecated pygppme module to upstream gpg wrappers
* feature: Verify signatures/decrypt messages in multipart/mixed payloads

As usual, a quick hall of fame of recent contributors:
$ git shortlog -s -n 0.5...
   110  Dylan Baker
77  Lucas Hoffmann
46  Patrick Totzke
 2  Daniel Kahn Gillmor
 2  Johannes Löthberg
 2  Siva Mahadevan
 1  Ian Denhardt
 1  Ruben Pollan

New bug reports, feature or pull requests via the projects github page [1]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.6
[1]: https://github.com/pazz/alot


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

[alot] announcing v0.5

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.5; You can get a tarball here [0].

This release contains only minor usability improvements but lots of internal
cleanups. We are making good progress on porting alot to python 3, finally
introduced a testing suite and now make use of build-testing on travis.ci and
(partly automated) code reviews for pull requests on github.

A big thanks goes to Lucas Hoffmann (lucc) and Dylan Baker (dcbaker),
who contributed most of this work.

Usage updates since v0.4:
* save command prompt, recipient and sender history across program restarts
* new config option: "handle_mouse" to enable interpretation of mouse events
* prompt for unsent messages before closing
* enable variable interpolation in config file
* Add encryption to CC addresses
* Add bufferlist, tablist and pyshell subcommands to the command line interface
* new hook: "loop_hook", that runs periodically
* new config option: "periodic_hook_frequency" to adjust how often to fire 
"loop_hook"

As usual, a quick hall of fame of recent contributors:
$ git shortlog -s -n 0.4...
86  Lucas Hoffmann
    76  Dylan Baker
54  Patrick Totzke
 4  Ian Denhardt
 2  Jody Foo
 1  Atilla Mas
 1  Christian Geier
 1  Hamish Downer
 1  Pol Van Aubel
 1  Ruben Pollan
 1  Samantha Marshall

New bug reports, feature or pull requests via the projects github page [1]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.5
[1]: https://github.com/pazz/alot
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[alot] announcing v0.4

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.4; You can get a tarball here [0].

I am happy to see a renewed interest in keeping this project alive.
Several people declared an interest in sharing some of the reponsibility
and pushing things forward (see [1] for the discussion).
For now, I will grant the following (github) users write access to the
repository: geier (py3 ports), lucc, dcbaker (testing) and dkg (gnupg).

Future pull requests will be required to pass the automatic QA tests [2],
receive at least one favourable review [3] and should be based against the
master branch.
I've decided to let the version number reflect the change in workflow.
We are now working towards version 0.5.

This version contains pushes mostly fixes and minor
usabilityimprovements (see below).

Usage updates since v0.3.7:
* signal: refresh current buffer on SIGUSR1
* signal: exit interface on SIGINT
* interpret C-g keybinding in prompts
* new config option:encrypt_by_default
* new config option: thread_authors_order_by
* indicate untrusted PGP signatures in thread view
* more flexible account selection for replies

As usual, a quick hall of fame for recent contributors:
$ git shortlog -s -n 0.3.7...|tail -n +2
 21  Lucas Hoffmann
 3  Micah Nordland
 3  Pol Van Aubel
 2  Guillaume Seren
 2  Johannes 'josch' Schauer
 2  Ruben Pollan
 2  Tony Cheneau
 2  bx
 1  Cody
 1  Dimitrios Semitsoglou-Tsiapos
 1  Emmanuel Beffara
 1  Jason Kölker
 1  Tommy Lindgren

New bug reports, feature or pull requests via the projects github page [4]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.4
[1]: https://github.com/pazz/alot/issues/908
[2]: 
https://www.quantifiedcode.com/app/project/c5aaa4739c5b4f6eb75eaaf8c01da679?limit=20=20=correctness=analysis
[3]: https://github.com/blog/2291-introducing-review-requests
[4]: https://github.com/pazz/alot


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

[alot] announcing v0.4

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.4; You can get a tarball here [0].

I am happy to see a renewed interest in keeping this project alive.
Several people declared an interest in sharing some of the reponsibility
and pushing things forward (see [1] for the discussion).
For now, I will grant the following (github) users write access to the
repository: geier (py3 ports), lucc, dcbaker (testing) and dkg (gnupg).

Future pull requests will be required to pass the automatic QA tests [2],
receive at least one favourable review [3] and should be based against the
master branch.
I've decided to let the version number reflect the change in workflow.
We are now working towards version 0.5.

This version contains pushes mostly fixes and minor
usabilityimprovements (see below).

Usage updates since v0.3.7:
* signal: refresh current buffer on SIGUSR1
* signal: exit interface on SIGINT
* interpret C-g keybinding in prompts
* new config option:encrypt_by_default
* new config option: thread_authors_order_by
* indicate untrusted PGP signatures in thread view
* more flexible account selection for replies

As usual, a quick hall of fame for recent contributors:
$ git shortlog -s -n 0.3.7...|tail -n +2
 21 Lucas Hoffmann
 3  Micah Nordland
 3  Pol Van Aubel
 2  Guillaume Seren
 2  Johannes 'josch' Schauer
 2  Ruben Pollan
 2  Tony Cheneau
 2  bx
 1  Cody
 1  Dimitrios Semitsoglou-Tsiapos
 1  Emmanuel Beffara
 1  Jason Kölker
 1  Tommy Lindgren

New bug reports, feature or pull requests via the projects github page [4]
are always welcome.

Cheers,
P

[0]: https://github.com/pazz/alot/tarball/0.4
[1]: https://github.com/pazz/alot/issues/908
[2]: 
https://www.quantifiedcode.com/app/project/c5aaa4739c5b4f6eb75eaaf8c01da679?limit=20=20=correctness=analysis
[3]: https://github.com/blog/2291-introducing-review-requests
[4]: https://github.com/pazz/alot


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

Re: [PATCH] use notmuch_database_open_verbose

[Patrick Totzke]

As far as I understand the bindings, the returned message is not needed
because the return
value of `Database._open` (line 212) contains information about the type of
error that occurred.
This is passed on two lines below if the open-call was unsuccessful.

The docstrings for this method are not ideal (the mentioned "status"
parameter is actually called "mode") but in terms of functionality it seems
ok.

On 12 March 2016 at 16:33, David Bremner  wrote:

> David Bremner  writes:
>
> >> -"""notmuch_database_open"""
> >> -_open = nmlib.notmuch_database_open
> >> +"""notmuch_database_open_verbose"""
> >> +_open = nmlib.notmuch_database_open_verbose
> >>  _open.argtypes = [c_char_p, c_uint, POINTER(NotmuchDatabaseP)]
> >>  _open.restype = c_uint
> >
> > I expect you probably want to add the new binding, rather than replacing
> > the old one. Otherwise updating the bindings will break all bindings
> > using scripts.
>
> Oh silly me. That's not actually exposed to the python API, so that's
> fine. On the other hand, don't you want to update the argument types and
> do something useful (throw an exception?) with the returned message?  As
> it stands you lose information.
>
> d
>
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] use notmuch_database_open_verbose

[Patrick Totzke]

... instead of the deprecated notmuch_database_open
when opening the database in notmuch.database.Database.open.
This prevents the library to print Xapian exceptions to stderr.
---
 bindings/python/notmuch/database.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bindings/python/notmuch/database.py 
b/bindings/python/notmuch/database.py
index f304533..5400338 100644
--- a/bindings/python/notmuch/database.py
+++ b/bindings/python/notmuch/database.py
@@ -86,8 +86,8 @@ class Database(object):
 _get_version.argtypes = [NotmuchDatabaseP]
 _get_version.restype = c_uint
 
-"""notmuch_database_open"""
-_open = nmlib.notmuch_database_open
+"""notmuch_database_open_verbose"""
+_open = nmlib.notmuch_database_open_verbose
 _open.argtypes = [c_char_p, c_uint, POINTER(NotmuchDatabaseP)]
 _open.restype = c_uint
 
@@ -201,7 +201,7 @@ class Database(object):
 
 This function is used by __init__() and usually does not need
 to be called directly. It wraps the underlying
-*notmuch_database_open* function.
+*notmuch_database_open_verbose* function.
 
 :param status: Open the database in read-only or read-write mode
 :type status:  :attr:`MODE`
-- 
2.7.0

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

[alot] announcing v0.3.7

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.7; You can get a tarball here [0].

NOTE: THIS VERSION INTRODUCES A NEW DEPENDENCY: "urwidtrees",
a library of urwid-widgets for tree structures.
It grew out of the alot interface and is now a separate project [1].

Apart from this, the current version contains lots of small fixes and usability
improvements, mainly provided by users (see below).

Usage updates since v0.3.6:
* new config option: msg_summary_hides_threadwide_tags
* new config setting: thread_subject
* new hook: sanitize_attachment_filename
* new hook: exit()
* list replies (new command parameter and config setting: 
auto_replyto_mailinglist)
* new config setting for accounts: encrypt_by_default
* new config setting for accounts: alias_regexp
* new config setting for abooks: shellcommand_external_filtering
* switched to setuptools
* detached urwidtrees library into separate project (and new dependency)

As usual, a quick hall of fame for recent contributors:
$ git shortlog -s -n 0.3.5...|tail -n +2
 7  Lucas Hoffmann
 5  Martin Zimmermann
 3  Guillaume Seren
 3  Tomas Tomecek
 2  Andres MRM
 2  Christian Geier
 1  Anton Khirnov
 1  Anton Parkhomenko
 1  Cinghio Pinghio
 1  Ruben Pollan
 1  bjoernb
 1  josch
 1  vrs


New bug reports, feature or pull requests via the projects github page [2]
are always welcome.

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.7
[1]: https://github.com/pazz/urwidtrees
[2]: https://github.com/pazz/alot
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Looking for the perfect mail client

[Patrick Totzke]

Hi all,

Quoting Simon Chopin (2014-10-21 11:42:39)
> ...
>
> You can't show HTML content without a web browser or a conversion
> to ascii AFAIK (BTW, alot uses w3m, which is a web browser :-) ). So you need
> to choose between the two (or viewing raw HTML, of course)

Just for completenes's sake: alot might use w3m on your box because you told it
to :) It will happily use whichever html2text converter you set up in your
mailcap (see http://alot.readthedocs.org/en/latest/faq.html point 5).
This set up mirrors that of mutt and other console MUAs.

> > - which is fast
> 
> That last point is my main problem with alot. There are some algorithms
> within the widgets that seem unobviously slow to me.

I agree with you. Out of interest: do you have any specific examples/complaints?
There is a recent fix for some recursion issue within the tree widgets
(https://github.com/pazz/urwidtrees/pull/4) that should solve some related
issues at least.

Best wishes,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: signature
URL: 

Re: Looking for the perfect mail client

[Patrick Totzke]

Hi all,

Quoting Simon Chopin (2014-10-21 11:42:39)
 ...

 You can't show HTML content without a web browser or a conversion
 to ascii AFAIK (BTW, alot uses w3m, which is a web browser :-) ). So you need
 to choose between the two (or viewing raw HTML, of course)

Just for completenes's sake: alot might use w3m on your box because you told it
to :) It will happily use whichever html2text converter you set up in your
mailcap (see http://alot.readthedocs.org/en/latest/faq.html point 5).
This set up mirrors that of mutt and other console MUAs.

  - which is fast
 
 That last point is my main problem with alot. There are some algorithms
 within the widgets that seem unobviously slow to me.

I agree with you. Out of interest: do you have any specific examples/complaints?
There is a recent fix for some recursion issue within the tree widgets
(https://github.com/pazz/urwidtrees/pull/4) that should solve some related
issues at least.

Best wishes,
/p


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

[alot] announcing v0.3.6

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.6; You can get a tarball here [0].

This version bump mostly reflects me catching up with the many fixes,
tweaks and some new features I received as pull requests.

Usage updates since v0.3.5:
* implement vim-style "move last" command (bound to G)
* fixes in reply/forwarding
* add option "--tags" to taglist command to display only a subset of the tags
* fix: safely interrumpt a command sequence
* use suffix ".eml" for temporary email files when editing
* interpret "compose mailto:foo at bar" commands
* new "tomorrow" colour theme
* Add some Emacs keybindings for prompts

As usual, a quick hall of fame for recent contributors:
$ git shortlog -s -n 0.3.5...|tail -n +2
 4  Hamish Downer
 4  Yann Rouillard
 4  Your Name
 3  Stanislav Ochotnicky
 2  Cinghio Pinghio
 2  Simon Chopin
 1  Christian Geier
 1  Emmanuel Beffara
 1  Gon?ri Le Bouder
 1  Martin Zimmermann
 1  Siim P?der

As you have surely noticed, alot is no longer actively developed and entered a
sluggish maintenance mode. This is of course due to real life catching up and
also because I don't see any immediate need for improvement. I don't plan to
abandon it as my main email client any time soon and therefore still
occasionally take the time to comment on and merge pull requests.
Let me know if you'd like to get involved in further developing/maintaining 
this project.

Nevertheless: There are still tons of good ideas for improvements floating
around as issues on github and some even have proof-of-concept implementations
(syntax highlighting for instance #272,#612).

Bug reports, feature or pull requests via the projects github page [1]
are of course always welcome.

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.6
[1]: https://github.com/pazz/alot
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: signature
URL: 

[alot] announcing v0.3.6

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.6; You can get a tarball here [0].

This version bump mostly reflects me catching up with the many fixes,
tweaks and some new features I received as pull requests.

Usage updates since v0.3.5:
* implement vim-style move last command (bound to G)
* fixes in reply/forwarding
* add option --tags to taglist command to display only a subset of the tags
* fix: safely interrumpt a command sequence
* use suffix .eml for temporary email files when editing
* interpret compose mailto:foo@bar; commands
* new tomorrow colour theme
* Add some Emacs keybindings for prompts

As usual, a quick hall of fame for recent contributors:
$ git shortlog -s -n 0.3.5...|tail -n +2
 4  Hamish Downer
 4  Yann Rouillard
 4  Your Name
 3  Stanislav Ochotnicky
 2  Cinghio Pinghio
 2  Simon Chopin
 1  Christian Geier
 1  Emmanuel Beffara
 1  Gonéri Le Bouder
 1  Martin Zimmermann
 1  Siim Põder

As you have surely noticed, alot is no longer actively developed and entered a
sluggish maintenance mode. This is of course due to real life catching up and
also because I don't see any immediate need for improvement. I don't plan to
abandon it as my main email client any time soon and therefore still
occasionally take the time to comment on and merge pull requests.
Let me know if you'd like to get involved in further developing/maintaining 
this project.

Nevertheless: There are still tons of good ideas for improvements floating
around as issues on github and some even have proof-of-concept implementations
(syntax highlighting for instance #272,#612).

Bug reports, feature or pull requests via the projects github page [1]
are of course always welcome.

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.6
[1]: https://github.com/pazz/alot


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

alot: can't read sent emails, after encryption

[Patrick Totzke]

Quoting Alain-Pierre Manine (2013-11-18 08:38:33)
> Quoting Jameson Graef Rollins (2013-11-17 20:43:25)
> > On Sun, Nov 17 2013, Patrick Totzke  wrote:
> > > Quoting Jameson Graef Rollins (2013-11-16 21:47:02)
> > >> On Tue, Nov 12 2013, apmanine at idaaas.com wrote:
> > >> > I have recently switched to notmuch. Thank you for it!
> > >> > I'm using "alot" as a frontend (thank you for it, too!). Everything
> > >> > works smoothly, apart from one problem: with alot, I can't figure out 
> > >> > how
> > >> > to read encrypted emails I previously sent: they appear to be encrypted
> > >> > using the addressee's key.
> > >> >
> > >> > Is there some way to store encrypted sent emails with my own public gpg
> > >> > key?
> > >> 
> > >> What you really want is to tell gpg to always encrypt messages to your
> > >> personal key as well, which will always make them viewable by you.  This
> > >> way you don't have to worry about saving unencrypted versions of the
> > >> message to disk, or there being two distinct versions of the message
> > >> (one encrypted to the recipient and a different one encrypted to you).
> > >> 
> > >> See the "encrypt-to" gpg option [0].
> > >> 
> > >> jamie.
> > >> 
> > >> [0] 
> > >> http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html
> > >
> > > Is this how notmuch emacs does it? I mean, is there some option to tell
> > > emacs to always call gpg with --encrypt-to=me ?
> > > I wonder if I need to change alot in any way or if one can simply 
> > > globally configure
> > > gnupg.. alot does not call the gpg binary but uses pygpgme.
> > 
> > You do not need to change alot, just notmuch emacs also doesn't need to
> > do anything special to allow for this.  Just add an
> > 
> > encrypt-to 
> > 
> > line to your ~/.gnupg/gpg.conf, where  is your personal keyid.
> > Then all encrypted data is also encrypted to your personal key, making
> > it always viewable by you as well.  Then you can just open your
> > encrypted sent mail as you would any other encrypted mail.
> > 
> > jamie.
> 
> It's working! Thanks for the explanations.


Excelent, thanks Jamie.
I wasn't aware of this setting and assumed that the stuff in the
gnupg config file only applies to gpg itself and not, as in alot,
for calls through the gpgme library.
Thanks for testing this Alain-Pierre.
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20131118/3016a867/attachment.pgp>

Re: alot: can't read sent emails, after encryption

[Patrick Totzke]

Quoting Alain-Pierre Manine (2013-11-18 08:38:33)
 Quoting Jameson Graef Rollins (2013-11-17 20:43:25)
  On Sun, Nov 17 2013, Patrick Totzke patricktot...@gmail.com wrote:
   Quoting Jameson Graef Rollins (2013-11-16 21:47:02)
   On Tue, Nov 12 2013, apman...@idaaas.com wrote:
I have recently switched to notmuch. Thank you for it!
I'm using alot as a frontend (thank you for it, too!). Everything
works smoothly, apart from one problem: with alot, I can't figure out 
how
to read encrypted emails I previously sent: they appear to be encrypted
using the addressee's key.
   
Is there some way to store encrypted sent emails with my own public gpg
key?
   
   What you really want is to tell gpg to always encrypt messages to your
   personal key as well, which will always make them viewable by you.  This
   way you don't have to worry about saving unencrypted versions of the
   message to disk, or there being two distinct versions of the message
   (one encrypted to the recipient and a different one encrypted to you).
   
   See the encrypt-to gpg option [0].
   
   jamie.
   
   [0] 
   http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html
  
   Is this how notmuch emacs does it? I mean, is there some option to tell
   emacs to always call gpg with --encrypt-to=me ?
   I wonder if I need to change alot in any way or if one can simply 
   globally configure
   gnupg.. alot does not call the gpg binary but uses pygpgme.
  
  You do not need to change alot, just notmuch emacs also doesn't need to
  do anything special to allow for this.  Just add an
  
  encrypt-to keyid
  
  line to your ~/.gnupg/gpg.conf, where keyid is your personal keyid.
  Then all encrypted data is also encrypted to your personal key, making
  it always viewable by you as well.  Then you can just open your
  encrypted sent mail as you would any other encrypted mail.
  
  jamie.
 
 It's working! Thanks for the explanations.


Excelent, thanks Jamie.
I wasn't aware of this setting and assumed that the stuff in the
gnupg config file only applies to gpg itself and not, as in alot,
for calls through the gpgme library.
Thanks for testing this Alain-Pierre.
/p


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

alot: can't read sent emails, after encryption

[Patrick Totzke]

Quoting Jameson Graef Rollins (2013-11-16 21:47:02)
> On Tue, Nov 12 2013, apmanine at idaaas.com wrote:
> > I have recently switched to notmuch. Thank you for it!
> > I'm using "alot" as a frontend (thank you for it, too!). Everything
> > works smoothly, apart from one problem: with alot, I can't figure out how
> > to read encrypted emails I previously sent: they appear to be encrypted
> > using the addressee's key.
> >
> > Is there some way to store encrypted sent emails with my own public gpg
> > key?
> 
> What you really want is to tell gpg to always encrypt messages to your
> personal key as well, which will always make them viewable by you.  This
> way you don't have to worry about saving unencrypted versions of the
> message to disk, or there being two distinct versions of the message
> (one encrypted to the recipient and a different one encrypted to you).
> 
> See the "encrypt-to" gpg option [0].
> 
> jamie.
> 
> [0] 
> http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html

Is this how notmuch emacs does it? I mean, is there some option to tell
emacs to always call gpg with --encrypt-to=me ?
I wonder if I need to change alot in any way or if one can simply globally 
configure
gnupg.. alot does not call the gpg binary but uses pygpgme.
cheers,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: alot: can't read sent emails, after encryption

[Patrick Totzke]

Quoting Jameson Graef Rollins (2013-11-16 21:47:02)
 On Tue, Nov 12 2013, apman...@idaaas.com wrote:
  I have recently switched to notmuch. Thank you for it!
  I'm using alot as a frontend (thank you for it, too!). Everything
  works smoothly, apart from one problem: with alot, I can't figure out how
  to read encrypted emails I previously sent: they appear to be encrypted
  using the addressee's key.
 
  Is there some way to store encrypted sent emails with my own public gpg
  key?
 
 What you really want is to tell gpg to always encrypt messages to your
 personal key as well, which will always make them viewable by you.  This
 way you don't have to worry about saving unencrypted versions of the
 message to disk, or there being two distinct versions of the message
 (one encrypted to the recipient and a different one encrypted to you).
 
 See the encrypt-to gpg option [0].
 
 jamie.
 
 [0] 
 http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html

Is this how notmuch emacs does it? I mean, is there some option to tell
emacs to always call gpg with --encrypt-to=me ?
I wonder if I need to change alot in any way or if one can simply globally 
configure
gnupg.. alot does not call the gpg binary but uses pygpgme.
cheers,
/p


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

How about these: -- CR & NL char in rfc2047-encoded header...

[Patrick Totzke]

Quoting David Bremner (2013-10-27 12:48:24)
> tomi.ollila at iki.fi writes:
> 
> > In thread starting from id:08cb1dcd-c5db-4e33-8b09-7730cb3d59a2 at gmail.com
> > David wondered in id:87y58xv71x.fsf at zancas.localnet what filtering
> > is done by CLI and what by lib.
> >
> > But where should the "problem" presented in the Subject: header should
> > be handled. I did some hacks to emacs client to drop the ^J (newline)
> > characters from Subject: and From: headers but should these be filtered
> > in CLI (or in lib) instead?
> >
> 
> Eventually we decided this was a front-end isssue. The emacs front-end
> fixed this  with commit 0.16-111-ga7964c8


I agree that this should be an issue for the MUA.
FYI: alot also normalizes newlines and tabs in subject lines..
https://github.com/pazz/alot/blob/master/alot/db/utils.py#L369
I cannot reproduce the original issue with the escaped UTF8 header not being 
interpreted.
This works fine for me in alot.

Best,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

[Patrick Totzke]

+1 from me for getting rid of the vim plug in mainline notmuch.
Cheers,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

[Patrick Totzke]

+1 from me for getting rid of the vim plug in mainline notmuch.
Cheers,
/p


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

[alot] announcing v0.3.5

[Patrick Totzke]

Quoting Ruben Pollan (2013-07-19 16:24:40)
> I just found the problem. I was still having the debian package installed and 
> alot was using it's old alot-egg from debian :( Now that I uninstall the 
> package 
> is working fine.
> 
> Sorry.

No worries! another problem that solved itself :)
cheers,
/p

[alot] announcing v0.3.5

[Patrick Totzke]

Quoting Ruben Pollan (2013-07-19 16:01:06)
> Quoting Patrick Totzke (2013-07-19 16:02:34)
> > Hi Rub?n,
> > 
> > thanks for mentioning this. I must have accidentally dropped the 
> > corresponding paragraph
> > in the docs 
> > (http://alot.readthedocs.org/en/testing/usage/index.html#cryptography).
> > I'm almost certain I saw this documented a while back..
> > 
> > Basically, you need a running gpg-agent. Then, decryption of mails should 
> > happen
> > automatically once you open a thread. The same holds for signature 
> > verification
> > (the status of which will be mentioned in a pseudo-header).
> > This holds for mails that comply PGP/MIME only. "ASCII-armored" text in 
> > plaintext parts
> > is not dealt with.
> > 
> > If this does not work, you've found a bug that you should kindly report :)
> 
> Sadly that is not what I see. I'm trying to read an email that mutt reports 
> as 
> PGP/MIME but the content appear blank. 

Is is possible that this mail's body is ctype 'text/html' and you haven't set up
your mailcap for html (as in FAQ #5 or issue #622)?

> I guess I have gpg-agent properly 
> working, because when I send a signed email I get a 'window' asking me for my 
> passphrase and it signs it. But it don't asks for the password when I try to 
> read an encrypted email.

Yes, it seems you have set up gpg-agent correctly then.
> 
> Do I need any special configuration on gpg-agent for it?

Not that I know of.

BTW: why did you not notice this earlier in the 'testing' branch? :P

I cannot think of anything else atm, sorry. Maybe Justus has an Idea?
Could you open an issue about this with some more details about the mail and 
your setup?
thx,
/p

[alot] announcing v0.3.5

[Patrick Totzke]

Hi Rub?n,

thanks for mentioning this. I must have accidentally dropped the corresponding 
paragraph
in the docs 
(http://alot.readthedocs.org/en/testing/usage/index.html#cryptography).
I'm almost certain I saw this documented a while back..

Basically, you need a running gpg-agent. Then, decryption of mails should happen
automatically once you open a thread. The same holds for signature verification
(the status of which will be mentioned in a pseudo-header).
This holds for mails that comply PGP/MIME only. "ASCII-armored" text in 
plaintext parts
is not dealt with.

If this does not work, you've found a bug that you should kindly report :)

HTH,
/p

[alot] announcing v0.3.5

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.5; You can get a tarball here [0].

Most notably, this update comes with a rewrite of Thread buffers,
allowing among other things thread-tree based focus movements.
Alot now has full support for PGP/MIME encryption and signatures,
courtesy of Justus (teythoon). Apart from this, the new release comes with the
usual ton of fixes contributed by various people (see below).

I enabled the project wiki on github, so that people too shy to come forward
with pull requests for alot/extra/ can share their customizations,
in particular python-hooks [2].

Usage updates since v0.3.4:
* full support for PGP/MIME [de|en]cryption and signatures
* add missing "unattach" command in envelope buffer
* honour 'Mail-Followup-To' header and set if for selected mailinglists
* better handling of replies to self-sent messages
* make auto_remove_unread configurable
* rewrite thread buffer
* improved global move commands: first/last line, half-page up/down
* tree-based movement in threads (first/last reply, next/previous 
unfolded/sibling, parent)
* fold/unfold messages based on query string in thread mode
* respect mailcap commands that expect stdin
* Support different libmagic APIs
* new hooks called before/aftr buffer open/close/focus
* new global repeat command


Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.2...|tail -n +2
11  Justus Winter
10  Sebastian Jeltsch
 6  josch
 4  Hamish Downer
 4  Yann Rouillard
 3  Lukas Zapletal
 2  Christopher Schwardt
 1  Benjamin
 1  Caio Prado
 1  Siim P?der
 1  bjoernb
 1  jakeogh

.. and everyone who send feedback!

As always, don't hesitate to file bug reports, feature or pull requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.5
[1]: https://github.com/pazz/alot
[2]: https://github.com/pazz/alot/wiki/Contrib-Hooks
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

[CLI] bug in notmuch setup

[Patrick Totzke]

Hi all,

As mentioned on IRC earlier, current master seems to have an issue with 
`notmuch setup`,
which fails to write ~/.notmuch-config if not already present.

Here are excerpts from the discussion from #notmuch:
--%<---
19:08:29  i have no notmuch config so far. when i run `notmuch` i get 
questioned about my name and so forth. 
then:
19:08:31  Error canonicalizing /home/pazz/.notmuch-config: No such file 
or directory
19:14:01  it could also be a bug. There was some change recently to 
avoid overwriting symlinks with files.
19:15:29  pazz: I think you found a bug. try "touch .notmuch-config" 
and run notmuch-setup again.
19:21:54  bremner: i'm a little confused because i thought i'd done that 
already. anyway: notmuch setup 
fails iff there is no ~/.notmuch-config present.
19:22:38  if there is an empty file notmuch setup runs ok, exit code is 0 
and the file gets overwritten
...
19:43:55  Error canonicalizing /home/too/.notmuch-config: No such file 
or directory
19:46:52  apparently realpath(3) fails in case there is no such file ;/
19:50:50  forgot to mention: i'm on 0.15.2+85~g44fe1f2d
19:52:55  yeah, the offending patch is +79, I think
19:53:25  the reason is obvious .. notmuch_config_save() executes 
filename = realpath
 (config->filename, NULL);
19:53:53  maybe just additionally checking for ENOENT could fix that...
19:57:20  sounds plausible. Have to double check we are not relying on 
some implicit re-allocation by 
   realpath.
19:58:41  true: free (filename) needs not to be done in case realpath() 
fails with ENOENT

-->%---

Best,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

[CLI] bug in notmuch setup

[Patrick Totzke]

Hi all,

As mentioned on IRC earlier, current master seems to have an issue with 
`notmuch setup`,
which fails to write ~/.notmuch-config if not already present.

Here are excerpts from the discussion from #notmuch:
--%---
19:08:29 pazz i have no notmuch config so far. when i run `notmuch` i get 
questioned about my name and so forth. 
then:
19:08:31 pazz Error canonicalizing /home/pazz/.notmuch-config: No such file 
or directory
19:14:01 bremner it could also be a bug. There was some change recently to 
avoid overwriting symlinks with files.
19:15:29 bremner pazz: I think you found a bug. try touch .notmuch-config 
and run notmuch-setup again.
19:21:54 pazz bremner: i'm a little confused because i thought i'd done that 
already. anyway: notmuch setup 
fails iff there is no ~/.notmuch-config present.
19:22:38 pazz if there is an empty file notmuch setup runs ok, exit code is 0 
and the file gets overwritten
...
19:43:55 Domo_ Error canonicalizing /home/too/.notmuch-config: No such file 
or directory
19:46:52 Domo_ apparently realpath(3) fails in case there is no such file ;/
19:50:50 pazz forgot to mention: i'm on 0.15.2+85~g44fe1f2d
19:52:55 bremner yeah, the offending patch is +79, I think
19:53:25 Domo_ the reason is obvious .. notmuch_config_save() executes 
filename = realpath
 (config-filename, NULL);
19:53:53 Domo_ maybe just additionally checking for ENOENT could fix that...
19:57:20 bremner sounds plausible. Have to double check we are not relying on 
some implicit re-allocation by 
   realpath.
19:58:41 Domo_ true: free (filename) needs not to be done in case realpath() 
fails with ENOENT

--%---

Best,
/p


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

Xapers

[Patrick Totzke]

Quoting Jameson Graef Rollins (2013-04-15 18:18:00)
> On Mon, Apr 15 2013, Jameson Graef Rollins  
> wrote:
> > README and a screenshot of the curses ui here:
> >
> > http://finestructure.net/xapers/README
> > http://finestructure.net/xapers/screenshot.png
> 
> I maybe should have been a little clearer that all necessary
> instructions should be in the README, including the source repo:
> 
>   git://finestructure.net/xapers


Brilliant idea!

here's some early feedback:
* is there a way to batch import a bunch of pdfs? or better yet, a bibtex file 
with entries pointing
  to files like the ones produced by say jabref?
  There, entries have some line like this:
  file = {Boz2012.pdf:papers/Boz2012.pdf:PDF}

* got a bunch of traces:
  -
  $xapers import --source=ABK2011.pdf   
  1 ? master 
  Reading bibtex... done.
  Adding bibtex... 

  Traceback (most recent call last):
File "/home/pazz/.local/bin/xapers", line 145, in 
  docid = cli.add(query_string, infile=infile, source=source, tags=tags, 
prompt=prompt)
File "/home/pazz/.local/lib/python2.7/site-packages/xapers/cli/ui.py", line 
228, in add
  doc.add_bibtex(bibtex)
File "/home/pazz/.local/lib/python2.7/site-packages/xapers/documents.py", 
line 373, in add_bibtex
  self.bibentry = xapers.bibtex.Bibentry(bibtex)
File "/home/pazz/.local/lib/python2.7/site-packages/xapers/bibtex.py", line 
25, in __init__
  if os.path.exists(bibtex):
File "/usr/lib/python2.7/genericpath.py", line 18, in exists
  os.stat(path)
  TypeError: must be encoded string without NULL bytes, not str
  

  $ xapers show, then i moved around a bit

  
  Traceback (most recent call last):
File "/home/pazz/.local/bin/xapers", line 228, in 
  xapers.nci.UI(xroot, cmd=args)
File "/home/pazz/.local/lib/python2.7/site-packages/xapers/nci/ui.py", line 
73, in __init__
  self.mainloop.run()
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py",
 line 272, in run
  self.screen.run_wrapper(self._run)
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/raw_display.py",
 line 242, in run_wrapper
  return fn()
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py",
 line 337, in _run
  self.event_loop.run()
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py",
 line 708, in run
  self._loop()
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py",
 line 787, in _loop
  self._watch_files[fd]()
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py",
 line 388, in _update
  self.process_input(keys)
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py",
 line 488, in process_input
  k = self._topmost_widget.keypress(self.screen_size, k)
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/container.py",
 line 1120, in keypress
  return self.body.keypress( (maxcol, remaining), key )
File "/home/pazz/.local/lib/python2.7/site-packages/xapers/nci/search.py", 
line 304, in keypress
  eval(cmd)
File "", line 1, in 
File "/home/pazz/.local/lib/python2.7/site-packages/xapers/nci/search.py", 
line 155, in nextEntry
  self.listbox.set_focus(pos + 1)
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/listbox.py",
 line 567, in set_focus
  self.body.set_focus(position)
File 
"/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/listbox.py",
 line 178, in set_focus
  raise IndexError, "No widget at position %s" % (position,)
  IndexError: No widget at position 1
  


* did you already set something up to report bugs? github issues, a maling list?

Can't wait until someone forks alot to use this. I've been waiting for someone 
(else)
to start a project like this for some time now :)

rock on,
/p

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

Re: Xapers

[Patrick Totzke]

Quoting Jameson Graef Rollins (2013-04-15 18:18:00)
 On Mon, Apr 15 2013, Jameson Graef Rollins jroll...@finestructure.net wrote:
  README and a screenshot of the curses ui here:
 
  http://finestructure.net/xapers/README
  http://finestructure.net/xapers/screenshot.png
 
 I maybe should have been a little clearer that all necessary
 instructions should be in the README, including the source repo:
 
   git://finestructure.net/xapers


Brilliant idea!

here's some early feedback:
* is there a way to batch import a bunch of pdfs? or better yet, a bibtex file 
with entries pointing
  to files like the ones produced by say jabref?
  There, entries have some line like this:
  file = {Boz2012.pdf:papers/Boz2012.pdf:PDF}

* got a bunch of traces:
  -
  $xapers import --source=ABK2011.pdf   
  1 ↵ master 
  Reading bibtex... done.
  Adding bibtex... 
  
  Traceback (most recent call last):
File /home/pazz/.local/bin/xapers, line 145, in module
  docid = cli.add(query_string, infile=infile, source=source, tags=tags, 
prompt=prompt)
File /home/pazz/.local/lib/python2.7/site-packages/xapers/cli/ui.py, line 
228, in add
  doc.add_bibtex(bibtex)
File /home/pazz/.local/lib/python2.7/site-packages/xapers/documents.py, 
line 373, in add_bibtex
  self.bibentry = xapers.bibtex.Bibentry(bibtex)
File /home/pazz/.local/lib/python2.7/site-packages/xapers/bibtex.py, line 
25, in __init__
  if os.path.exists(bibtex):
File /usr/lib/python2.7/genericpath.py, line 18, in exists
  os.stat(path)
  TypeError: must be encoded string without NULL bytes, not str
  
  
  $ xapers show, then i moved around a bit

  
  Traceback (most recent call last):
File /home/pazz/.local/bin/xapers, line 228, in module
  xapers.nci.UI(xroot, cmd=args)
File /home/pazz/.local/lib/python2.7/site-packages/xapers/nci/ui.py, line 
73, in __init__
  self.mainloop.run()
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py,
 line 272, in run
  self.screen.run_wrapper(self._run)
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/raw_display.py,
 line 242, in run_wrapper
  return fn()
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py,
 line 337, in _run
  self.event_loop.run()
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py,
 line 708, in run
  self._loop()
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py,
 line 787, in _loop
  self._watch_files[fd]()
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py,
 line 388, in _update
  self.process_input(keys)
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/main_loop.py,
 line 488, in process_input
  k = self._topmost_widget.keypress(self.screen_size, k)
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/container.py,
 line 1120, in keypress
  return self.body.keypress( (maxcol, remaining), key )
File /home/pazz/.local/lib/python2.7/site-packages/xapers/nci/search.py, 
line 304, in keypress
  eval(cmd)
File string, line 1, in module
File /home/pazz/.local/lib/python2.7/site-packages/xapers/nci/search.py, 
line 155, in nextEntry
  self.listbox.set_focus(pos + 1)
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/listbox.py,
 line 567, in set_focus
  self.body.set_focus(position)
File 
/home/pazz/.local/lib/python2.7/site-packages/urwid-1.2.0_dev-py2.7-linux-x86_64.egg/urwid/listbox.py,
 line 178, in set_focus
  raise IndexError, No widget at position %s % (position,)
  IndexError: No widget at position 1
  


* did you already set something up to report bugs? github issues, a maling list?

Can't wait until someone forks alot to use this. I've been waiting for someone 
(else)
to start a project like this for some time now :)

rock on,
/p



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

the future of notmuch-vim?

[Patrick Totzke]

Quoting Felipe Contreras (2013-04-03 10:09:39)
> ...
> What you prefer is irrelevant; it's relevant only for you, that's why it's
> called a *preference*, the rest of us prefer different things.

Never mind preferences, I think originally, this thread was about dropping
*support* for the *original* vim plugin that lives in notmuch/contrib.
I think we can all agree that this is reasonable.

This should not keep you from hacking on your script, hosting
it whereever you like and support it.
For me, one of the charms of notmuch is exactly this extensibility.

> I've tried mutt-kz and alot, and I was utterly dissapointed by both.
> 
> See how snappy and fast notmuch-vim-ruby is[1], alot is much worst in these
> respects.

I always appreciate constructive feedback on alot..
regards,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

the future of notmuch-vim?

[Patrick Totzke]

Quoting guyzmo (2013-04-03 07:01:58)
> ...
> It may be nice and/or fun to use that kind  of  things  in  vim, but
> really, it's opposite to the philosophy of vim.
> ...
> Whereas you seem to have done a really good  job  integrating  it to
> vim,  I  personally  think  that  anything  that  makes  vim  an  IDE, a
> coffeemaker, or an Operating System is not worth the pain. So my opinion
> is to just drop vim-as-MUA script support.

Fullack! Thanks for spelling out my thoughts in great detail :D
I'm definitely for dropping support for all notmuch-vim scripts officially.
These scripts can live in their own repositories on github or alike
and we can link those in the wiki for completeness sake.
/p

Re: the future of notmuch-vim?

[Patrick Totzke]

Quoting guyzmo (2013-04-03 07:01:58)
 ...
 It may be nice and/or fun to use that kind  of  things  in  vim, but
 really, it's opposite to the philosophy of vim.
 ...
 Whereas you seem to have done a really good  job  integrating  it to
 vim,  I  personally  think  that  anything  that  makes  vim  an  IDE, a
 coffeemaker, or an Operating System is not worth the pain. So my opinion
 is to just drop vim-as-MUA script support.

Fullack! Thanks for spelling out my thoughts in great detail :D
I'm definitely for dropping support for all notmuch-vim scripts officially.
These scripts can live in their own repositories on github or alike
and we can link those in the wiki for completeness sake.
/p
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: the future of notmuch-vim?

[Patrick Totzke]

Quoting Felipe Contreras (2013-04-03 10:09:39)
 ...
 What you prefer is irrelevant; it's relevant only for you, that's why it's
 called a *preference*, the rest of us prefer different things.

Never mind preferences, I think originally, this thread was about dropping
*support* for the *original* vim plugin that lives in notmuch/contrib.
I think we can all agree that this is reasonable.

This should not keep you from hacking on your script, hosting
it whereever you like and support it.
For me, one of the charms of notmuch is exactly this extensibility.

 I've tried mutt-kz and alot, and I was utterly dissapointed by both.
 
 See how snappy and fast notmuch-vim-ruby is[1], alot is much worst in these
 respects.

I always appreciate constructive feedback on alot..
regards,
/p


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

funcmail.py: generate notmuch-tags based on headers

[Patrick Totzke]

Could this be integrated into "afew" as a custom filter?

Re: funcmail.py: generate notmuch-tags based on headers

[Patrick Totzke]

Could this be integrated into afew as a custom filter?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

afew filter rules

[Patrick Totzke]

Hey Reiner,

Quoting Rainer M Krug (2013-02-28 15:29:33)
> Based on the the filter, it seems that list_id is used to tag the emails - 
> correct?

Seems so, yea [0].

> But in
> addition, I have some lists which do not have list_id, but need to be 
> identified by their to
> address - how can I add these filters?

I use some custom filters like this in my setup [1].
Basically, you can add a custom filter to your filer chain by adding
a section with name "Filer.n" for increasing n..
Also check out afew's docs [2].

Cheers,
/p


[0]: 
https://github.com/teythoon/afew/blob/master/afew/filters/ListMailsFilter.py#L31
[1]: https://github.com/pazz/configs/blob/master/.config/afew/config
[2]: https://afew.readthedocs.org/en/latest/manual.html#customizing-filters


> Thanks,
> 
> Rainer
> 
> [1] https://github.com/teythoon/afew
> - -- 
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
> UCT), Dipl. Phys.
> (Germany)
> 
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
> 
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
> 
> Fax (D):+49 - (0)3 21 21 25 22 44
> 
> email:  Rainer at krugs.de
> 
> Skype:  RMkrug
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJRL3fcAAoJENvXNx4PUvmCO6oIALNAp5Z2SE6H2EqePpk0kwBc
> NCIK12IEyGzLya2BzCv87sucxyicCeXqBt5pNkGgsxK7pJxXaDQVaDtYZgguVfnB
> /IE1AgDCfgzUx+iPMS4knB9DaKiKHPIpuH1oL7PK3tbc332+zlWFxeeekJj9DvM9
> 53LZGr9oMQ74obX9vDnFcbHCNq/o2ALcNnnJlDRmTZFpFmSBxk6QxbWqlUZcRyGv
> R9CJEdx3+a1kQhLCwYN7CoX1LQx1y57fm2//qt4m7dn6ZWK1ueRneJRuVr/jobiy
> jKjRAI/fkT/HBk3l0eJ9fkAeOMZT5Ur/FXjipG8kUmwrnBojp6Eykk4NMIg+Mvo=
> =CoyQ
> -END PGP SIGNATURE-
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: afew filter rules

[Patrick Totzke]

Hey Reiner,

Quoting Rainer M Krug (2013-02-28 15:29:33)
 Based on the the filter, it seems that list_id is used to tag the emails - 
 correct?

Seems so, yea [0].

 But in
 addition, I have some lists which do not have list_id, but need to be 
 identified by their to
 address - how can I add these filters?

I use some custom filters like this in my setup [1].
Basically, you can add a custom filter to your filer chain by adding
a section with name Filer.n for increasing n..
Also check out afew's docs [2].

Cheers,
/p


[0]: 
https://github.com/teythoon/afew/blob/master/afew/filters/ListMailsFilter.py#L31
[1]: https://github.com/pazz/configs/blob/master/.config/afew/config
[2]: https://afew.readthedocs.org/en/latest/manual.html#customizing-filters


 Thanks,
 
 Rainer
 
 [1] https://github.com/teythoon/afew
 - -- 
 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
 UCT), Dipl. Phys.
 (Germany)
 
 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa
 
 Tel :   +33 - (0)9 53 10 27 44
 Cell:   +33 - (0)6 85 62 59 98
 Fax :   +33 - (0)9 58 10 27 44
 
 Fax (D):+49 - (0)3 21 21 25 22 44
 
 email:  rai...@krugs.de
 
 Skype:  RMkrug
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iQEcBAEBAgAGBQJRL3fcAAoJENvXNx4PUvmCO6oIALNAp5Z2SE6H2EqePpk0kwBc
 NCIK12IEyGzLya2BzCv87sucxyicCeXqBt5pNkGgsxK7pJxXaDQVaDtYZgguVfnB
 /IE1AgDCfgzUx+iPMS4knB9DaKiKHPIpuH1oL7PK3tbc332+zlWFxeeekJj9DvM9
 53LZGr9oMQ74obX9vDnFcbHCNq/o2ALcNnnJlDRmTZFpFmSBxk6QxbWqlUZcRyGv
 R9CJEdx3+a1kQhLCwYN7CoX1LQx1y57fm2//qt4m7dn6ZWK1ueRneJRuVr/jobiy
 jKjRAI/fkT/HBk3l0eJ9fkAeOMZT5Ur/FXjipG8kUmwrnBojp6Eykk4NMIg+Mvo=
 =CoyQ
 -END PGP SIGNATURE-
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


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

[alot] announcing v0.3.4

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.4; You can get a tarball here [0].
This minor version bump is mostly to flush out all the nice small features
I hacked together or received as pull request lately.

It comes with tons of ui tweaks, fixes and a very nice patch series
that allows to send PGP/MIME encrypted mails.

Not included, but here's a peek into alot's future for the curious:
I've been semi-busy, making alot's tree-widgets available for the wider
urwid audience [2] and am currently rewriting alot's thread buffers to make use 
of
this library [3]. This will make it easy? to finally write a better mimeparser 
[4]
and display a messages MIME-tree as well as properly display nested 
encrypted/signed
mails..

More detailed usage updates since v0.3.3:
* extra: zsh completion file
* thread mode: add "tags" pseudo header to message display
* case insensitive matching in Addressbook completion
* compose: interpret "attach" pseudo header
* compose: set initial message tags
* envelope: completion for 'From'
* reply/forward: more flexible construction of "From" headers (hello plussing!)
* thread mode: added bounce command for direct redirection w/o an envelope 
buffer
* thread mode: more robust "pipeto" command
* add config option "prefer_plaintext"
* prevent multiple 'index locked' notifications
* kill some zombies! (#325)
* search mode: bulk tagging
* less annoying multi-key bindings
* add global "move" command for scriptable cursor movement
* support for encrypted outgoing mails using PGP/MIME

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.2...|tail -n +2

 30  Johannes Kulick
  9  William Erik Baxter
  5  Kazuo Teramoto
  4  Justus Winter
  3  Benjamin
  3  Simon Chopin
  2  Antoine Amarilli
  1  Johann Weging
  1  Michael Turquette
  1  bjoernb

.. and everyone who send feedback!

As always, don't hesitate to file bug reports, feature or pull requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.4
[1]: https://github.com/pazz/alot
[2]: https://github.com/pazz/urwidtrees-V2
[3]: https://github.com/pazz/alot/tree/0.3.3-feature-urwidtrees
[4]: https://github.com/pazz/alot/tree/0.3.3-mimeparser
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

[alot] announcing v0.3.4

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.4; You can get a tarball here [0].
This minor version bump is mostly to flush out all the nice small features
I hacked together or received as pull request lately.

It comes with tons of ui tweaks, fixes and a very nice patch series
that allows to send PGP/MIME encrypted mails.

Not included, but here's a peek into alot's future for the curious:
I've been semi-busy, making alot's tree-widgets available for the wider
urwid audience [2] and am currently rewriting alot's thread buffers to make use 
of
this library [3]. This will make it easy™ to finally write a better mimeparser 
[4]
and display a messages MIME-tree as well as properly display nested 
encrypted/signed
mails..

More detailed usage updates since v0.3.3:
* extra: zsh completion file
* thread mode: add tags pseudo header to message display
* case insensitive matching in Addressbook completion
* compose: interpret attach pseudo header
* compose: set initial message tags
* envelope: completion for 'From'
* reply/forward: more flexible construction of From headers (hello plussing!)
* thread mode: added bounce command for direct redirection w/o an envelope 
buffer
* thread mode: more robust pipeto command
* add config option prefer_plaintext
* prevent multiple 'index locked' notifications
* kill some zombies! (#325)
* search mode: bulk tagging
* less annoying multi-key bindings
* add global move command for scriptable cursor movement
* support for encrypted outgoing mails using PGP/MIME

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.2...|tail -n +2

 30  Johannes Kulick
  9  William Erik Baxter
  5  Kazuo Teramoto
  4  Justus Winter
  3  Benjamin
  3  Simon Chopin
  2  Antoine Amarilli
  1  Johann Weging
  1  Michael Turquette
  1  bjoernb

.. and everyone who send feedback!

As always, don't hesitate to file bug reports, feature or pull requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.4
[1]: https://github.com/pazz/alot
[2]: https://github.com/pazz/urwidtrees-V2
[3]: https://github.com/pazz/alot/tree/0.3.3-feature-urwidtrees
[4]: https://github.com/pazz/alot/tree/0.3.3-mimeparser


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

gmail importer script

[Patrick Totzke]

BTW: I removed the whole maildir contents and restarted the downlowd over 
night. here's the result:

---
Traceback (most recent call last):2|
  | 26% ETA:  1:37:22   3.11  emails/s
  File "./gmail-notmuch.py", line 253, in 
main()
  File "./gmail-notmuch.py", line 89, in main
download_new_messages(imap, database, new_messages, destination)
  File "./gmail-notmuch.py", line 210, in download_new_messages
tag_message(database, dest, labels)
  File "./gmail-notmuch.py", line 168, in tag_message
raise e
notmuch.errors.FileNotEmailError
---

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

Re: gmail importer script

[Patrick Totzke]

BTW: I removed the whole maildir contents and restarted the downlowd over 
night. here's the result:

---
Traceback (most recent call last):2|
  | 26% ETA:  1:37:22   3.11  emails/s
  File ./gmail-notmuch.py, line 253, in module
main()
  File ./gmail-notmuch.py, line 89, in main
download_new_messages(imap, database, new_messages, destination)
  File ./gmail-notmuch.py, line 210, in download_new_messages
tag_message(database, dest, labels)
  File ./gmail-notmuch.py, line 168, in tag_message
raise e
notmuch.errors.FileNotEmailError
---

/p


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

gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-16 20:44:04)
> On Sat, Dec 15, 2012 at 11:41 AM, Patrick Totzke 
> wrote:
> 
> Well, thats not the point.. the script shouldn't die like this.
> I think it's be better if the script caught that exception, deleted the
> file
> and continued..
> 
> 
> Probably, but I suspect it's related to whatever mystery error you ran into
> before with the corruption.
> 
> Does deleting that file and trying again fix it??

I don't know. How would I know which file to remove?
I just removed the newest files in new/cur/tmp
but this doesnt solve the issue.
What would really help here is some more informative error message!

I tried with the `-d` option but did not see any local path in the output.

> 
> Anyway, this is extremely stable for me and a few others at this point. I'm
> going to wait for other users to report errors. Alternatively, send me patches
> if you want things to happen.

Personally, I don't really care if 'things are happening', as I'm kind of OK 
with my current
offlineimap configuration and would seriously consider switching from OI
only if it meant an improvement in speed or stability.

I test this code because I believe that the notmuch ecosystem
would benefit from a working solution and that reviews and bug-reports
are important.

Of course, I don't expect any miracles in terms of speed at this early stage.
But the bug I reported above should be addressed at some point in order not to
scare off potential users.

Have you considered including your code in offlineimap?
I'm asking because OI already solved some of the problems you might face later 
on
if you want to continue working on this.

* multi-threaded downloads
* the ability to read passwords not as plaintext parameter..

best,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121216/62774cac/attachment.pgp>

Re: gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-16 20:44:04)
 On Sat, Dec 15, 2012 at 11:41 AM, Patrick Totzke patricktot...@gmail.com
 wrote:
 
 Well, thats not the point.. the script shouldn't die like this.
 I think it's be better if the script caught that exception, deleted the
 file
 and continued..
 
 
 Probably, but I suspect it's related to whatever mystery error you ran into
 before with the corruption.
 
 Does deleting that file and trying again fix it? 

I don't know. How would I know which file to remove?
I just removed the newest files in new/cur/tmp
but this doesnt solve the issue.
What would really help here is some more informative error message!

I tried with the `-d` option but did not see any local path in the output.

 
 Anyway, this is extremely stable for me and a few others at this point. I'm
 going to wait for other users to report errors. Alternatively, send me patches
 if you want things to happen.

Personally, I don't really care if 'things are happening', as I'm kind of OK 
with my current
offlineimap configuration and would seriously consider switching from OI
only if it meant an improvement in speed or stability.

I test this code because I believe that the notmuch ecosystem
would benefit from a working solution and that reviews and bug-reports
are important.

Of course, I don't expect any miracles in terms of speed at this early stage.
But the bug I reported above should be addressed at some point in order not to
scare off potential users.

Have you considered including your code in offlineimap?
I'm asking because OI already solved some of the problems you might face later 
on
if you want to continue working on this.

* multi-threaded downloads
* the ability to read passwords not as plaintext parameter..

best,
/p


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

gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-15 08:22:46)
> On Thu, Dec 13, 2012 at 5:48 PM, Patrick Totzke 
> wrote:
> 
> 
> notmuch.errors.FileNotEmailError
> 
> 
> Delete the file it dies on and try again.

Well, thats not the point.. the script shouldn't die like this.
I think it's be better if the script caught that exception, deleted the file
and continued..

Thanks,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121215/a8b6075b/attachment.pgp>

Re: gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-15 08:22:46)
 On Thu, Dec 13, 2012 at 5:48 PM, Patrick Totzke patricktot...@gmail.com
 wrote:
 
 
 notmuch.errors.FileNotEmailError
 
 
 Delete the file it dies on and try again.

Well, thats not the point.. the script shouldn't die like this.
I think it's be better if the script caught that exception, deleted the file
and continued..

Thanks,
/p


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

gmail importer script

[Patrick Totzke]

Sorry, I'm misusing this thread as a bugtracker..


Traceback (most recent call last):4|   
| 10% ETA:  1:24:41   3.54  emails/s
  File "./gmail-notmuch.py", line 251, in 
main()
  File "./gmail-notmuch.py", line 89, in main
download_new_messages(imap, database, new_messages, destination)
  File "./gmail-notmuch.py", line 208, in download_new_messages
tag_message(database, dest, labels)
  File "./gmail-notmuch.py", line 168, in tag_message
raise e
notmuch.errors.FileNotEmailError



best,
/p

notmuch python bindings corrupt db index (was: gmail importer script)

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-13 14:32:53)
> On Wed, Dec 12, 2012 at 9:49 PM, Austin Clements  wrote:
> > There should be no way to corrupt the database at this level through
> > the Xapian API, which means nothing libnotmuch can do (much less users
> > of libnotmuch) should be able to corrupt the database.  If you can
> > reproduce the problem, it's probably a serious bug in Xapian, but it
> > could also have been a file system bug or even random file system
> > corruption.
> 
> Well that's... troubling.
> 
> Patrick: could you please backup and try to reproduce? Otherwise I'll
> assume this was a one-off situation.


I tried it again, concurrently triggered some modifications
and killed the process afer a while.
(my modifications were not flushed during the run of your script as
the index was locked)
The index seems to be OK. So I'm afraid I cannot reproduce this reliably.
/p

Re: notmuch python bindings corrupt db index (was: gmail importer script)

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-13 14:32:53)
 On Wed, Dec 12, 2012 at 9:49 PM, Austin Clements amdra...@mit.edu wrote:
  There should be no way to corrupt the database at this level through
  the Xapian API, which means nothing libnotmuch can do (much less users
  of libnotmuch) should be able to corrupt the database.  If you can
  reproduce the problem, it's probably a serious bug in Xapian, but it
  could also have been a file system bug or even random file system
  corruption.
 
 Well that's... troubling.
 
 Patrick: could you please backup and try to reproduce? Otherwise I'll
 assume this was a one-off situation.


I tried it again, concurrently triggered some modifications
and killed the process afer a while.
(my modifications were not flushed during the run of your script as
the index was locked)
The index seems to be OK. So I'm afraid I cannot reproduce this reliably.
/p


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

Re: gmail importer script

[Patrick Totzke]

Sorry, I'm misusing this thread as a bugtracker..


Traceback (most recent call last):4|   
| 10% ETA:  1:24:41   3.54  emails/s
  File ./gmail-notmuch.py, line 251, in module
main()
  File ./gmail-notmuch.py, line 89, in main
download_new_messages(imap, database, new_messages, destination)
  File ./gmail-notmuch.py, line 208, in download_new_messages
tag_message(database, dest, labels)
  File ./gmail-notmuch.py, line 168, in tag_message
raise e
notmuch.errors.FileNotEmailError



best,
/p
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

notmuch python bindings corrupt db index (was: gmail importer script)

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-11 13:47:32)
> On Tue, Dec 11, 2012 at 11:04 AM, Patrick Totzke
>  wrote:
> > I ended up killing the process after i saw that ETA was >3h.
> 
> Gmail's bottleneck. Very unfortunate. Leave it going over night.

OK, i assumed i'd not have to download all messages because i already have them
on disk -- synced via offlineimap. but then i remembered that OI stores uses
its own naming scheme for the files in a maildir. so thats probably why your 
script
did not realize theyre already there. (maybe it should? it could look up the 
MIDs from notmuch)

> > This broke my index!
> >
> > afterwards, a `notmuch new` printed
> >
> > A Xapian exception occurred creating a directory: Expected block
> > 485 to be level 1, not 0.
> >
> > I wasnt able to properly read the index anymore and had to
> > restore an old index dump. not cool!
> 
> 
> Can you provide any more information about this? The script properly
> uses atomic transactions. Any corruption here is the result of a
> notmuch library bug, which should be investigated.

i am kind of reluctant to reproduce this again (on my work-desktop).
All i did was start your script, writing to the index in another terminal in 
between (using alot)
possibly my cronjob fired a "notmuch new; afew.." in between also.
when I killed your script the index war broken.

Can i turn on some global logging for notmuch to debug this?
Maybe libnotmuch had trouble with so many db-writes at a time?

/p


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121211/254fef11/attachment.pgp>

gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-11 09:12:56)
> It seems to work, but i'm still waiting for the first run-through.
> 
> 
> Downloading messages: 457 of 22831|
> 
> This takes ages. I hope it doesn't try to re-download all my messages
> everytime.
> 
> 
> Nope. It's very smart about not doing that.
> ?

hmmk

I ended up killing the process after i saw that ETA was >3h. This broke my 
index!
afterwards, a `notmuch new` printed 

A Xapian exception occurred creating a directory: Expected block
485 to be level 1, not 0.

I wasnt able to properly read the index anymore and had to
restore an old index dump. not cool!

/p

gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-11 07:06:22)
> On Mon, Dec 10, 2012 at 6:46 PM, Jason A. Donenfeld  
> wrote:
> 
> 
> 
> On Mon, Dec 10, 2012 at 10:41 AM, Patrick Totzke  gmail.com>
> wrote:
> 
> It would, but its nicer not to load ressources you're not gonna use.
> Also, progressbar 2.2 seems to be the newest version you see on a
> reasonably new debian/ubuntu install.. 
> 
> 
> I'll consider it.
> 
> 
> --silent or -s now silences stdout.

It seems to work, but i'm still waiting for the first run-through.

Downloading messages: 457 of 22831|

This takes ages. I hope it doesn't try to re-download all my messages everytime.

Another thing:
It seems that throughout its run, your script locks the notmuch database. This 
is particularly
annoying if you want to read/tag mails while waiting for a long sync-process. I 
think you only
really want to lock the index for a short time in the end.
Do you write to the index directly after a msg is downloaded?

/p

Re: gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-11 07:06:22)
 On Mon, Dec 10, 2012 at 6:46 PM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 
 
 
 On Mon, Dec 10, 2012 at 10:41 AM, Patrick Totzke patricktot...@gmail.com
 wrote:
 
 It would, but its nicer not to load ressources you're not gonna use.
 Also, progressbar 2.2 seems to be the newest version you see on a
 reasonably new debian/ubuntu install.. /nitpick
 
 
 I'll consider it.
 
 
 --silent or -s now silences stdout.

It seems to work, but i'm still waiting for the first run-through.

Downloading messages: 457 of 22831|

This takes ages. I hope it doesn't try to re-download all my messages everytime.

Another thing:
It seems that throughout its run, your script locks the notmuch database. This 
is particularly
annoying if you want to read/tag mails while waiting for a long sync-process. I 
think you only
really want to lock the index for a short time in the end.
Do you write to the index directly after a msg is downloaded?

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

Re: gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-11 09:12:56)
 It seems to work, but i'm still waiting for the first run-through.
 
 
 Downloading messages: 457 of 22831|
 
 This takes ages. I hope it doesn't try to re-download all my messages
 everytime.
 
 
 Nope. It's very smart about not doing that.
  

hmmk

I ended up killing the process after i saw that ETA was 3h. This broke my 
index!
afterwards, a `notmuch new` printed 

A Xapian exception occurred creating a directory: Expected block
485 to be level 1, not 0.

I wasnt able to properly read the index anymore and had to
restore an old index dump. not cool!

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

Re: notmuch python bindings corrupt db index (was: gmail importer script)

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-11 13:47:32)
 On Tue, Dec 11, 2012 at 11:04 AM, Patrick Totzke
 patricktot...@gmail.com wrote:
  I ended up killing the process after i saw that ETA was 3h.
 
 Gmail's bottleneck. Very unfortunate. Leave it going over night.

OK, i assumed i'd not have to download all messages because i already have them
on disk -- synced via offlineimap. but then i remembered that OI stores uses
its own naming scheme for the files in a maildir. so thats probably why your 
script
did not realize theyre already there. (maybe it should? it could look up the 
MIDs from notmuch)

  This broke my index!
 
  afterwards, a `notmuch new` printed
 
  A Xapian exception occurred creating a directory: Expected block
  485 to be level 1, not 0.
 
  I wasnt able to properly read the index anymore and had to
  restore an old index dump. not cool!
 
 
 Can you provide any more information about this? The script properly
 uses atomic transactions. Any corruption here is the result of a
 notmuch library bug, which should be investigated.

i am kind of reluctant to reproduce this again (on my work-desktop).
All i did was start your script, writing to the index in another terminal in 
between (using alot)
possibly my cronjob fired a notmuch new; afew.. in between also.
when I killed your script the index war broken.

Can i turn on some global logging for notmuch to debug this?
Maybe libnotmuch had trouble with so many db-writes at a time?

/p




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

gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-09 23:13:12)
> On Sat, Dec 8, 2012 at 6:46 PM, Patrick Totzke  
> wrote:
> 
> ZeroDivisionError: float division by zero
> 
> 
> Fixed it! Sorry about all this... Jeeze?Louise.?

thx

> 
> Another feature request:
> Could you make the progressbar stuff optinal? in the end one will want to
> run this via cronjob
> and this shouldn't print anything to stdout.
> Also, I can pretty much recommend the 'logging' module.
> 
> 
> Sure, but... >/dev/null doesn't cut it? I can add some more refined logging
> capabilities if you want.
It would, but its nicer not to load ressources you're not gonna use. Also, 
progressbar 2.2 seems to be the newest version you see on a reasonably new 
debian/ubuntu install.. 


Next exception.. do you have a bugtracker? (/me <3 github)

Logging in...
Selecting all mail...
Receiving message list: 24455 of 
24455||100% Time: 0:00:12   2.04 
kemails/s
Parsing message list and labels...
Searching for local messages...
Traceback (most recent call last):
  File "./gmail-notmuch.py", line 248, in 
main()
  File "./gmail-notmuch.py", line 75, in main
if len(new_messages) == 0:
TypeError: object of type 'NoneType' has no len()



/p

Re: gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-09 23:13:12)
 On Sat, Dec 8, 2012 at 6:46 PM, Patrick Totzke patricktot...@gmail.com 
 wrote:
 
 ZeroDivisionError: float division by zero
 
 
 Fixed it! Sorry about all this... Jeeze Louise. 

thx

 
 Another feature request:
 Could you make the progressbar stuff optinal? in the end one will want to
 run this via cronjob
 and this shouldn't print anything to stdout.
 Also, I can pretty much recommend the 'logging' module.
 
 
 Sure, but... /dev/null doesn't cut it? I can add some more refined logging
 capabilities if you want.
It would, but its nicer not to load ressources you're not gonna use. Also, 
progressbar 2.2 seems to be the newest version you see on a reasonably new 
debian/ubuntu install.. /nitpick


Next exception.. do you have a bugtracker? (/me 3 github)

Logging in...
Selecting all mail...
Receiving message list: 24455 of 
24455||100% Time: 0:00:12   2.04 
kemails/s
Parsing message list and labels...
Searching for local messages...
Traceback (most recent call last):
  File ./gmail-notmuch.py, line 248, in module
main()
  File ./gmail-notmuch.py, line 75, in main
if len(new_messages) == 0:
TypeError: object of type 'NoneType' has no len()



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

gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-08 17:04:48)
> On Sat, Dec 8, 2012 at 5:20 PM, Patrick Totzke  
> wrote:
> > I have two new errors:
> >
> > -
> > ./gmail-notmuch.py -u patricktotzke at gmail.com -p mypwd ~/mail/gmail/
> >
> > I also tried with maildir param ~/mail/gmail/\[Google\ Mail\].All\ Mail
> > as this is where my all-mail maildir is, and i also tried an absolute path, 
> > all the same result.
> >
> > If I point it to the root of my notmuch directory I get:
> 
> Pointing it at the root directory is what you want. In fact, I'm
> removing the argument from the script and having it just get that from
> the config. So the correct invocation will be:
> 
> ./gmail-notmuch.py -u blabla -p password

Okay..
> 
> >   File "./gmail-notmuch.py", line 147, in create_progressbar
> > return ProgressBar(maxval=total, widgets=[text + ": ", 
> > SimpleProgress(), Bar(), Percentage(), " ", ETA(), " ", 
> > FileTransferSpeed(unit="emails")])
> > TypeError: __init__() got an unexpected keyword argument 'unit'
> 
> You're probably running with an old version of python-statusbar.

I just installed it from ubuntu 12.04's repository. the version was 2.2-2.
Installed from pip now, and it seems ok. you'll want to make more specific 
dependencies at some
point..

> >
> > BTW: I had to change the hardcoded "[Gmail]" to "[Google Mail]" for it to 
> > get that far.
> 
> Really? Are you in the UK? I'll have to do this dynamically using the
> XLIST imap extension.

Yea, but its a *really* old account I first got from google.de.
Reading this dynamically would def. help.


next try..
-

Traceback (most recent call last):
  File "./gmail-notmuch.py", line 246, in 
main()
  File "./gmail-notmuch.py", line 74, in main
new_messages = retag_old_messages(database, messages, destination)
  File "./gmail-notmuch.py", line 176, in retag_old_messages
progressbar.start()
  File "/usr/local/lib/python2.7/dist-packages/progressbar/__init__.py", line 
311, in start
self.update(0)
  File "/usr/local/lib/python2.7/dist-packages/progressbar/__init__.py", line 
283, in update
self.fd.write(self._format_line() + '\r')
  File "/usr/local/lib/python2.7/dist-packages/progressbar/__init__.py", line 
243, in _format_line
widgets = ''.join(self._format_widgets())
  File "/usr/local/lib/python2.7/dist-packages/progressbar/__init__.py", line 
223, in _format_widgets
widget = format_updatable(widget, self)
  File "/usr/local/lib/python2.7/dist-packages/progressbar/widgets.py", line 
38, in format_updatable
if hasattr(updatable, 'update'): return updatable.update(pbar)
  File "/usr/local/lib/python2.7/dist-packages/progressbar/widgets.py", line 
184, in update
return '%3d%%' % pbar.percentage()
  File "/usr/local/lib/python2.7/dist-packages/progressbar/__init__.py", line 
208, in percentage
return self.currval * 100.0 / self.maxval
ZeroDivisionError: float division by zero
--



Another feature request:
Could you make the progressbar stuff optinal? in the end one will want to run 
this via cronjob
and this shouldn't print anything to stdout.
Also, I can pretty much recommend the 'logging' module.

cheers,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20121208/5aef8270/attachment.pgp>

gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-07 13:49:46)
> Not sure what is causing this. My best guess is that your password was
> incorrect and that I'm not checking the login return value.

Yes, you're right, it was an incorrect passwd.

> One thing you also might want to watch out for is
> exceptions due to a locked notmuch index.
> 
> 
> How do I do this?

See e.g. here: https://github.com/pazz/alot/blob/master/alot/db/manager.py#L163
I'm sure "afew" (https://github.com/teythoon/afew) does a similar thing.


I have two new errors:

-
./gmail-notmuch.py -u patricktotzke at gmail.com -p mypwd ~/mail/gmail/
Logging in...
Selecting all mail...
Error opening database at /home/pazz/mail/gmail/.notmuch: No such file or 
directory
Traceback (most recent call last):
  File "./gmail-notmuch.py", line 225, in 
main()
  File "./gmail-notmuch.py", line 56, in main
database = notmuch.Database(destination, False, 
notmuch.Database.MODE.READ_WRITE)
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/database.py", 
line 154, in __init__
self.open(path, mode)
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/database.py", 
line 214, in open
raise NotmuchError(status)
notmuch.errors.FileError
-

I also tried with maildir param ~/mail/gmail/\[Google\ Mail\].All\ Mail
as this is where my all-mail maildir is, and i also tried an absolute path, all 
the same result.

If I point it to the root of my notmuch directory I get:
-
[~/projects/gmail-notmuch] ./gmail-notmuch.py -u patricktotzke at gmail.com -p 
mypwd /home/pazz/mail
Logging in...
Selecting all mail...
Traceback (most recent call last):
  File "./gmail-notmuch.py", line 225, in 
main()
  File "./gmail-notmuch.py", line 58, in main
messages = discover_messages(imap, total)
  File "./gmail-notmuch.py", line 104, in discover_messages
new_readline.progressbar = create_progressbar("Receiving message list", 
total).start()
  File "./gmail-notmuch.py", line 147, in create_progressbar
return ProgressBar(maxval=total, widgets=[text + ": ", SimpleProgress(), 
Bar(), Percentage(), " ", ETA(), " ", FileTransferSpeed(unit="emails")])
TypeError: __init__() got an unexpected keyword argument 'unit'

BTW: I had to change the hardcoded "[Gmail]" to "[Google Mail]" for it to get 
that far.


HTH,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-07 13:49:46)
 Not sure what is causing this. My best guess is that your password was
 incorrect and that I'm not checking the login return value.

Yes, you're right, it was an incorrect passwd.

 One thing you also might want to watch out for is
 exceptions due to a locked notmuch index.
 
 
 How do I do this?

See e.g. here: https://github.com/pazz/alot/blob/master/alot/db/manager.py#L163
I'm sure afew (https://github.com/teythoon/afew) does a similar thing.


I have two new errors:

-
./gmail-notmuch.py -u patricktot...@gmail.com -p mypwd ~/mail/gmail/
Logging in...
Selecting all mail...
Error opening database at /home/pazz/mail/gmail/.notmuch: No such file or 
directory
Traceback (most recent call last):
  File ./gmail-notmuch.py, line 225, in module
main()
  File ./gmail-notmuch.py, line 56, in main
database = notmuch.Database(destination, False, 
notmuch.Database.MODE.READ_WRITE)
  File /home/pazz/.local/lib/python2.7/site-packages/notmuch/database.py, 
line 154, in __init__
self.open(path, mode)
  File /home/pazz/.local/lib/python2.7/site-packages/notmuch/database.py, 
line 214, in open
raise NotmuchError(status)
notmuch.errors.FileError
-

I also tried with maildir param ~/mail/gmail/\[Google\ Mail\].All\ Mail
as this is where my all-mail maildir is, and i also tried an absolute path, all 
the same result.

If I point it to the root of my notmuch directory I get:
-
[~/projects/gmail-notmuch] ./gmail-notmuch.py -u patricktot...@gmail.com -p 
mypwd /home/pazz/mail
Logging in...
Selecting all mail...
Traceback (most recent call last):
  File ./gmail-notmuch.py, line 225, in module
main()
  File ./gmail-notmuch.py, line 58, in main
messages = discover_messages(imap, total)
  File ./gmail-notmuch.py, line 104, in discover_messages
new_readline.progressbar = create_progressbar(Receiving message list, 
total).start()
  File ./gmail-notmuch.py, line 147, in create_progressbar
return ProgressBar(maxval=total, widgets=[text + : , SimpleProgress(), 
Bar(), Percentage(),  , ETA(),  , FileTransferSpeed(unit=emails)])
TypeError: __init__() got an unexpected keyword argument 'unit'

BTW: I had to change the hardcoded [Gmail] to [Google Mail] for it to get 
that far.


HTH,
/p


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

Re: gmail importer script

[Patrick Totzke]

Quoting Jason A. Donenfeld (2012-12-08 17:04:48)
 On Sat, Dec 8, 2012 at 5:20 PM, Patrick Totzke patricktot...@gmail.com 
 wrote:
  I have two new errors:
 
  -
  ./gmail-notmuch.py -u patricktot...@gmail.com -p mypwd ~/mail/gmail/
 
  I also tried with maildir param ~/mail/gmail/\[Google\ Mail\].All\ Mail
  as this is where my all-mail maildir is, and i also tried an absolute path, 
  all the same result.
 
  If I point it to the root of my notmuch directory I get:
 
 Pointing it at the root directory is what you want. In fact, I'm
 removing the argument from the script and having it just get that from
 the config. So the correct invocation will be:
 
 ./gmail-notmuch.py -u blabla -p password

Okay..
 
File ./gmail-notmuch.py, line 147, in create_progressbar
  return ProgressBar(maxval=total, widgets=[text + : , 
  SimpleProgress(), Bar(), Percentage(),  , ETA(),  , 
  FileTransferSpeed(unit=emails)])
  TypeError: __init__() got an unexpected keyword argument 'unit'
 
 You're probably running with an old version of python-statusbar.

I just installed it from ubuntu 12.04's repository. the version was 2.2-2.
Installed from pip now, and it seems ok. you'll want to make more specific 
dependencies at some
point..

 
  BTW: I had to change the hardcoded [Gmail] to [Google Mail] for it to 
  get that far.
 
 Really? Are you in the UK? I'll have to do this dynamically using the
 XLIST imap extension.

Yea, but its a *really* old account I first got from google.de.
Reading this dynamically would def. help.


next try..
-

Traceback (most recent call last):
  File ./gmail-notmuch.py, line 246, in module
main()
  File ./gmail-notmuch.py, line 74, in main
new_messages = retag_old_messages(database, messages, destination)
  File ./gmail-notmuch.py, line 176, in retag_old_messages
progressbar.start()
  File /usr/local/lib/python2.7/dist-packages/progressbar/__init__.py, line 
311, in start
self.update(0)
  File /usr/local/lib/python2.7/dist-packages/progressbar/__init__.py, line 
283, in update
self.fd.write(self._format_line() + '\r')
  File /usr/local/lib/python2.7/dist-packages/progressbar/__init__.py, line 
243, in _format_line
widgets = ''.join(self._format_widgets())
  File /usr/local/lib/python2.7/dist-packages/progressbar/__init__.py, line 
223, in _format_widgets
widget = format_updatable(widget, self)
  File /usr/local/lib/python2.7/dist-packages/progressbar/widgets.py, line 
38, in format_updatable
if hasattr(updatable, 'update'): return updatable.update(pbar)
  File /usr/local/lib/python2.7/dist-packages/progressbar/widgets.py, line 
184, in update
return '%3d%%' % pbar.percentage()
  File /usr/local/lib/python2.7/dist-packages/progressbar/__init__.py, line 
208, in percentage
return self.currval * 100.0 / self.maxval
ZeroDivisionError: float division by zero
--



Another feature request:
Could you make the progressbar stuff optinal? in the end one will want to run 
this via cronjob
and this shouldn't print anything to stdout.
Also, I can pretty much recommend the 'logging' module.

cheers,
/p


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

gmail importer script

[Patrick Totzke]

Is this supposed to happen?

-
Logging in...
Selecting all mail...
Discovering local messages...
Receiving message list...
Traceback (most recent call last):
  File "./gmail-notmuch.py", line 175, in 
main()
  File "./gmail-notmuch.py", line 58, in main
new_messages = discover_new_messages(imap, old_messages)
  File "./gmail-notmuch.py", line 80, in discover_new_messages
typ, data = imap.fetch("1:*", "X-GM-MSGID")
  File "/usr/lib/python2.7/imaplib.py", line 443, in fetch
typ, dat = self._simple_command(name, message_set, message_parts)
  File "/usr/lib/python2.7/imaplib.py", line 1070, in _simple_command
return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python2.7/imaplib.py", line 825, in _command
', '.join(Commands[name])))
imaplib.error: command FETCH illegal in state AUTH, only allowed in states 
SELECTED

--


In [2]: imaplib.__version__
Out[2]: '2.58'

One thing you also might want to watch out for is
exceptions due to a locked notmuch index.
rock on,
/p

Re: gmail importer script

[Patrick Totzke]

Is this supposed to happen?

-
Logging in...
Selecting all mail...
Discovering local messages...
Receiving message list...
Traceback (most recent call last):
  File ./gmail-notmuch.py, line 175, in module
main()
  File ./gmail-notmuch.py, line 58, in main
new_messages = discover_new_messages(imap, old_messages)
  File ./gmail-notmuch.py, line 80, in discover_new_messages
typ, data = imap.fetch(1:*, X-GM-MSGID)
  File /usr/lib/python2.7/imaplib.py, line 443, in fetch
typ, dat = self._simple_command(name, message_set, message_parts)
  File /usr/lib/python2.7/imaplib.py, line 1070, in _simple_command
return self._command_complete(name, self._command(name, *args))
  File /usr/lib/python2.7/imaplib.py, line 825, in _command
', '.join(Commands[name])))
imaplib.error: command FETCH illegal in state AUTH, only allowed in states 
SELECTED

--


In [2]: imaplib.__version__
Out[2]: '2.58'

One thing you also might want to watch out for is
exceptions due to a locked notmuch index.
rock on,
/p
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Notmuch indexing takes too long

[Patrick Totzke]

Hi Ondrej,

Quoting Ondrej Jombik (2012-11-09 02:58:09)
> I am trying to move from mairix to some better solution. mairix has been
> working really well for me, but it had some limitations.
> 
> I decided to give a try to notmuch, but I has been suprised with
> estimated indexing time:
> 
>  Processed 4157 of 822462 files (10h 3m 42s remaining).
> 
> At the beggining when there was 11 hours estimate I simply thought that
> those numbers are wrong. But they are not. This is really going to take
> that long. I could not believe that you all wait that long to index your
> maildirs:)
> 
> Also if I understand correctly the concept, whenever I want to
> regenerate database, I have to move old away and create new one,
> correct? mairix worked that way that you run it and it updated its own
> database. Is it possible with notmuch as well? I simply do not want to
> wait 10+ hours for every database regeneration, thought I am willing to
> wait that long for initial indexing.

Notmuch does incremental idnex updates once the initial index is build.
The initial indexing takes a while, depending on the number of mails you have
but 10 *hours* seems a little off. For me its ~5mins on the hdd and <2 on a ssd.

> My last question is related to notmuch and Alpine. Alpine is
> a IMAP/Maildir e-mail client based on old PINE. I get used to that so
> much that I cannot move away (to Mutt, for example). Is there anyone who
> uses notmuch with Alpine and created some scripts and/or key-bindings?

You might want to have a look at notmuchfs: https://github.com/tsto/notmuchfs
Also, there are a few other MUAs based on notmuch:
Check out http://notmuchmail.org/frontends/

Have fun,
/p

Re: Notmuch indexing takes too long

[Patrick Totzke]

Hi Ondrej,

Quoting Ondrej Jombik (2012-11-09 02:58:09)
 I am trying to move from mairix to some better solution. mairix has been
 working really well for me, but it had some limitations.
 
 I decided to give a try to notmuch, but I has been suprised with
 estimated indexing time:
 
  Processed 4157 of 822462 files (10h 3m 42s remaining).
 
 At the beggining when there was 11 hours estimate I simply thought that
 those numbers are wrong. But they are not. This is really going to take
 that long. I could not believe that you all wait that long to index your
 maildirs:)
 
 Also if I understand correctly the concept, whenever I want to
 regenerate database, I have to move old away and create new one,
 correct? mairix worked that way that you run it and it updated its own
 database. Is it possible with notmuch as well? I simply do not want to
 wait 10+ hours for every database regeneration, thought I am willing to
 wait that long for initial indexing.

Notmuch does incremental idnex updates once the initial index is build.
The initial indexing takes a while, depending on the number of mails you have
but 10 *hours* seems a little off. For me its ~5mins on the hdd and 2 on a ssd.

 My last question is related to notmuch and Alpine. Alpine is
 a IMAP/Maildir e-mail client based on old PINE. I get used to that so
 much that I cannot move away (to Mutt, for example). Is there anyone who
 uses notmuch with Alpine and created some scripts and/or key-bindings?

You might want to have a look at notmuchfs: https://github.com/tsto/notmuchfs
Also, there are a few other MUAs based on notmuch:
Check out http://notmuchmail.org/frontends/

Have fun,
/p
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

nbook: a notmuch based address book written in python

[Patrick Totzke]

Quoting Suvayu Ali (2012-10-08 10:34:29)
> Hi Patrick,
> 
> Sorry for the very late reply; I got distracted with some personal
> matters.
> 
> On Tue, Sep 25, 2012 at 11:44:57AM +0100, Patrick Totzke wrote:
> > Hey Suvayu, welcome to notmuch!
> > 
> > I hope you are aware that there are already a few search based abook tools
> > around for notmuch (listed in the wiki, albeit hidden in the emacs docs):
> > http://notmuchmail.org/emacstips/#index14h2
> > I personally use nottoomuch-addresses.sh, which apparently does some 
> > advanced
> > caching voodoo for speed.
> > 
> 
> I wasn't aware of either of them, thanks for pointing them out.  I'll
> take a look for inspiration and ideas.
> 
> > But to your tool; practice test:
> > I wasn't able to use wildcards or simply prefixes of names. This is 
> > essential
> > if you want to use it for tabcompleting contacts in a MUA.
> 
> Since the idea was inspired by the completion on the Gmail web
> interface, I already do a partial search so wildcards should not be
> necessary.

Not sure what you mean here: If I compose a mail using gmails web interface
and type a prefix of someone's name I will get this contect as a suggestion.
My point was that using your tool, I did not get a contact suggested
for all prefixes.

> > The time lookups take seems to depend on how many matches there are:
> > 
> > ---
> > time nbook Suvayu
> > 1 unique email addresses found for `Suvayu'
> > fatkasuvayu+linux at gmail.com Suvayu Ali
> > 
> > nbook Suvayu  0.04s user 0.01s system 95% cpu 0.050 total
> > ---
> > time nbook Justus
> > ...
> > 
> > nbook Justus  0.21s user 0.07s system 11% cpu 2.484 total
> > ---
> 
> Yes, I noticed this too when I searched for the more common names.  Not
> sure how to get around this though.

I think this is a conceptual problem with your algorithm:
You look up *all* messages and add a name to your result-list
if it matches. This means you go through some condidate
as often as you index contains mails from/to him.
What one really wants is to ask the database to do something like
  "SELECT name,email from RECIPIENTS_OR_SENDER"
where RECIPIENTS_OR_SENDER is some imaginary list that stores
a set of contacts.

Bottom line: One would have to change the layout of the underlying
database (not likely) or do regularly update some cache
and only work on that. This is what some of the mentioned tools do if i'm not 
mistaken.

> > And If I look for my own name, this takes over a minute,
> > eventually dying. This could be an issue with libnotmuch though.
> > Possibly, your algorithm takes very long and then reads from an initially
> > opened Database object again, which was invalidated by concurrent writes of 
> > other processes..
> > 
> > ---
> > [~] time nbook Patrick 
> > 
> > Error opening /home/pazz/mail/gmail/[Google Mail].All 
> > Mail/cur/1330682270_0.12958.megatron,U=8766,FMD5=66ff6a8bc18a8a3ac4b311daa93d358a:2,S:
> >  Too many open files
> > Traceback (most recent call last):
> >   File "/home/pazz/bin/nbook", line 167, in 
> >   File "/home/pazz/bin/nbook", line 71, in __init__
> >   File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", 
> > line 233, in get_header
> > notmuch.errors.NullPointerError
> > Error in sys.excepthook:
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, 
> > in apport_excepthook
> > ImportError: No module named fileutils
> > 
> > Original exception was:
> > Traceback (most recent call last):
> >   File "/home/pazz/bin/nbook", line 167, in 
> >   File "/home/pazz/bin/nbook", line 71, in __init__
> >   File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", 
> > line 233, in get_header
> > notmuch.errors.NullPointerError
> > nbook Patrick  3.20s user 5.47s system 12% cpu 1:11.65 total
> > 
> > 
> 
> Yes someone else pointed this out too.  Again I'm not sure how to
> proceed here.  I had a quick look at this last week and it seemed to me
> the limitation comes from within the python bindings for notmuch.  Do
> you have any ideas?

As mentioned before, I think you invalidate the Database object concurrently
while your long-running algorithm goes through all messages.
Xapian doesn't handle concurrent access to the index like a normal? database 
would.
This means 

Re: nbook: a notmuch based address book written in python

[Patrick Totzke]

Quoting Suvayu Ali (2012-10-08 10:34:29)
 Hi Patrick,
 
 Sorry for the very late reply; I got distracted with some personal
 matters.
 
 On Tue, Sep 25, 2012 at 11:44:57AM +0100, Patrick Totzke wrote:
  Hey Suvayu, welcome to notmuch!
  
  I hope you are aware that there are already a few search based abook tools
  around for notmuch (listed in the wiki, albeit hidden in the emacs docs):
  http://notmuchmail.org/emacstips/#index14h2
  I personally use nottoomuch-addresses.sh, which apparently does some 
  advanced
  caching voodoo for speed.
  
 
 I wasn't aware of either of them, thanks for pointing them out.  I'll
 take a look for inspiration and ideas.
 
  But to your tool; practice test:
  I wasn't able to use wildcards or simply prefixes of names. This is 
  essential
  if you want to use it for tabcompleting contacts in a MUA.
 
 Since the idea was inspired by the completion on the Gmail web
 interface, I already do a partial search so wildcards should not be
 necessary.

Not sure what you mean here: If I compose a mail using gmails web interface
and type a prefix of someone's name I will get this contect as a suggestion.
My point was that using your tool, I did not get a contact suggested
for all prefixes.

  The time lookups take seems to depend on how many matches there are:
  
  ---
  time nbook Suvayu
  1 unique email addresses found for `Suvayu'
  fatkasuvayu+li...@gmail.com Suvayu Ali
  
  nbook Suvayu  0.04s user 0.01s system 95% cpu 0.050 total
  ---
  time nbook Justus
  ...
  
  nbook Justus  0.21s user 0.07s system 11% cpu 2.484 total
  ---
 
 Yes, I noticed this too when I searched for the more common names.  Not
 sure how to get around this though.

I think this is a conceptual problem with your algorithm:
You look up *all* messages and add a name to your result-list
if it matches. This means you go through some condidate
as often as you index contains mails from/to him.
What one really wants is to ask the database to do something like
  SELECT name,email from RECIPIENTS_OR_SENDER
where RECIPIENTS_OR_SENDER is some imaginary list that stores
a set of contacts.

Bottom line: One would have to change the layout of the underlying
database (not likely) or do regularly update some cache
and only work on that. This is what some of the mentioned tools do if i'm not 
mistaken.

  And If I look for my own name, this takes over a minute,
  eventually dying. This could be an issue with libnotmuch though.
  Possibly, your algorithm takes very long and then reads from an initially
  opened Database object again, which was invalidated by concurrent writes of 
  other processes..
  
  ---
  [~] time nbook Patrick 
  
  Error opening /home/pazz/mail/gmail/[Google Mail].All 
  Mail/cur/1330682270_0.12958.megatron,U=8766,FMD5=66ff6a8bc18a8a3ac4b311daa93d358a:2,S:
   Too many open files
  Traceback (most recent call last):
File /home/pazz/bin/nbook, line 167, in module
File /home/pazz/bin/nbook, line 71, in __init__
File /home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py, 
  line 233, in get_header
  notmuch.errors.NullPointerError
  Error in sys.excepthook:
  Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/apport_python_hook.py, line 66, 
  in apport_excepthook
  ImportError: No module named fileutils
  
  Original exception was:
  Traceback (most recent call last):
File /home/pazz/bin/nbook, line 167, in module
File /home/pazz/bin/nbook, line 71, in __init__
File /home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py, 
  line 233, in get_header
  notmuch.errors.NullPointerError
  nbook Patrick  3.20s user 5.47s system 12% cpu 1:11.65 total
  
  
 
 Yes someone else pointed this out too.  Again I'm not sure how to
 proceed here.  I had a quick look at this last week and it seemed to me
 the limitation comes from within the python bindings for notmuch.  Do
 you have any ideas?

As mentioned before, I think you invalidate the Database object concurrently
while your long-running algorithm goes through all messages.
Xapian doesn't handle concurrent access to the index like a normal™ database 
would.
This means you are notified by this error that some changes were detected.
Maybe the error message should be more telling here though. Teythoon?

  Anyway, have fun hacking notmuch! If you are looking for a related project 
  to bring in your python skills
  I could think of one or two :D
 
 That would be wonderful.  To give you my background, I'm a graduate
 student in physics and I have to do a lot of C/C++ and python
 programming for my research.  Contributing to FOSS projects seems like a
 wonderful way to learn to collaborate and clean programming (we
 physicists tend to be sloppy programmers :-p).

https://github.com/teythoon/afew
https://github.com/pazz/alot

nbook: a notmuch based address book written in python

[Patrick Totzke]

Hey Suvayu, welcome to notmuch!

I hope you are aware that there are already a few search based abook tools
around for notmuch (listed in the wiki, albeit hidden in the emacs docs):
http://notmuchmail.org/emacstips/#index14h2
I personally use nottoomuch-addresses.sh, which apparently does some advanced
caching voodoo for speed.

But to your tool; practice test:
I wasn't able to use wildcards or simply prefixes of names. This is essential
if you want to use it for tabcompleting contacts in a MUA.
The time lookups take seems to depend on how many matches there are:

---
time nbook Suvayu
1 unique email addresses found for `Suvayu'
fatkasuvayu+linux at gmail.com Suvayu Ali

nbook Suvayu  0.04s user 0.01s system 95% cpu 0.050 total
---
time nbook Justus
...

nbook Justus  0.21s user 0.07s system 11% cpu 2.484 total
---
And If I look for my own name, this takes over a minute,
eventually dying. This could be an issue with libnotmuch though.
Possibly, your algorithm takes very long and then reads from an initially
opened Database object again, which was invalidated by concurrent writes of 
other processes..

---
[~] time nbook Patrick 

Error opening /home/pazz/mail/gmail/[Google Mail].All 
Mail/cur/1330682270_0.12958.megatron,U=8766,FMD5=66ff6a8bc18a8a3ac4b311daa93d358a:2,S:
 Too many open files
Traceback (most recent call last):
  File "/home/pazz/bin/nbook", line 167, in 
  File "/home/pazz/bin/nbook", line 71, in __init__
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", line 
233, in get_header
notmuch.errors.NullPointerError
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in 
apport_excepthook
ImportError: No module named fileutils

Original exception was:
Traceback (most recent call last):
  File "/home/pazz/bin/nbook", line 167, in 
  File "/home/pazz/bin/nbook", line 71, in __init__
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", line 
233, in get_header
notmuch.errors.NullPointerError
nbook Patrick  3.20s user 5.47s system 12% cpu 1:11.65 total


Anyway, have fun hacking notmuch! If you are looking for a related project to 
bring in your python skills
I could think of one or two :D
Best,
/p

Re: nbook: a notmuch based address book written in python

[Patrick Totzke]

Hey Suvayu, welcome to notmuch!

I hope you are aware that there are already a few search based abook tools
around for notmuch (listed in the wiki, albeit hidden in the emacs docs):
http://notmuchmail.org/emacstips/#index14h2
I personally use nottoomuch-addresses.sh, which apparently does some advanced
caching voodoo for speed.

But to your tool; practice test:
I wasn't able to use wildcards or simply prefixes of names. This is essential
if you want to use it for tabcompleting contacts in a MUA.
The time lookups take seems to depend on how many matches there are:

---
time nbook Suvayu
1 unique email addresses found for `Suvayu'
fatkasuvayu+li...@gmail.com Suvayu Ali

nbook Suvayu  0.04s user 0.01s system 95% cpu 0.050 total
---
time nbook Justus
...

nbook Justus  0.21s user 0.07s system 11% cpu 2.484 total
---
And If I look for my own name, this takes over a minute,
eventually dying. This could be an issue with libnotmuch though.
Possibly, your algorithm takes very long and then reads from an initially
opened Database object again, which was invalidated by concurrent writes of 
other processes..

---
[~] time nbook Patrick 

Error opening /home/pazz/mail/gmail/[Google Mail].All 
Mail/cur/1330682270_0.12958.megatron,U=8766,FMD5=66ff6a8bc18a8a3ac4b311daa93d358a:2,S:
 Too many open files
Traceback (most recent call last):
  File /home/pazz/bin/nbook, line 167, in module
  File /home/pazz/bin/nbook, line 71, in __init__
  File /home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py, line 
233, in get_header
notmuch.errors.NullPointerError
Error in sys.excepthook:
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/apport_python_hook.py, line 66, in 
apport_excepthook
ImportError: No module named fileutils

Original exception was:
Traceback (most recent call last):
  File /home/pazz/bin/nbook, line 167, in module
  File /home/pazz/bin/nbook, line 71, in __init__
  File /home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py, line 
233, in get_header
notmuch.errors.NullPointerError
nbook Patrick  3.20s user 5.47s system 12% cpu 1:11.65 total


Anyway, have fun hacking notmuch! If you are looking for a related project to 
bring in your python skills
I could think of one or two :D
Best,
/p
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[alot] announcing v0.3.3

[Patrick Totzke]

Quoting Sepp Tannhuber (2012-09-11 17:59:12)
> Hi Patrick,
> 
> thank you for answering and for this really good mail client!
pleasure :)

> > One reason I have not bothered to implement this so far is that in the long 
> > run,
> > I want to have urwid Tree widgets as top level widgets in thread buffers.
> > This would also allow "move to next sibling/parent" and so on.
> I did not know that it would be so complicated. But nice to hear that 
> development
> is going on.
Yea, trees in urwid are a bit messed up atm. alot's thread buffer uses its own
archaic widget layout, which is eventually to be replaced.

> > So you can of course use this method to set an "Attach" header, but as of 
> > now
> > alot will not interpret and remove this when reading the edited text.
> Exactly!

I think this will not so hard to do. Could you open up a feature request issue
on github for this?

> > When you see the "to>" prompt, type in some prefix of a (realname part of a)
> > contact from abook and hit .
> This was my assumption. But it is not working here. Obviously I make a 
> mistake. Here is my
> config:
> -- BEGIN ~/.config/alot/config --
> theme = solarized_dark
> editor_cmd = 'vim +/^$ "+normal j" "+:set textwidth=80" "+:set ft=mail"'
> 
> [accounts]
> 
> ? ? [[work]]
> ? ? ? ? realname = Joseph Tannhuber
> ? ? ? ? address = jtannhuber at work.de
> ? ? ? ? signature = ~/.signature
> ? ? ? ? sendmail_command = msmtp --account=work -t
> ? ? ? ? sent_box = maildir:///home/sepp/Maildir/Sent
> ? ? ? ? draft_box = maildir:///home/sepp/Maildir/Drafts
> ? ? ? ? [[[abook]]]
> ? ? ? ? ? ? type = abook
> -- END --
> Is there anything missing?

No, that's what I use as well.
Note that this variant assumes your contact file is ~/.abook/addressbook. I'm 
not aware of format
issues for different abook versions so far. Also note that this will complete 
case-sensitive
strings of the format "Firstname Lastname ".

To debug this you can replay this introspect session and see how far you get.
Start alots python shell (pyshell command), then:

>>> from alot.settings import settings
>>> settings.get_addressbooks()
[, 
]
>>> settings.get_addressbooks()[0]

>>> A=settings.get_addressbooks()[0]
>>> A.get_contacts()
[... CONTACT TUPLES HERE...]

Hope this helps. Otherwise don't hesitate to open a bug report on github.

> By the way: Is it possible to set the X11 urgency hint flag when new mail 
> arrives? In principle
> one can use the visual bell in the terminal. Then alot must only invoke a 
> shell command:
> ? echo -e "\b"

Well, alot does not pull your mails itself, so has no means of knowing when new 
mail arrives.
I personally use a mail indicator widget I wrote for my window manager that 
periodically
checks the notmuch index for new mail: 
http://awesome.naquadah.org/wiki/Notmuch_mail_integration

Alot can of course fire shell commands. What it is lacking at the moment is the 
ability to periodically
fire custom (alot-)commands. This feature would not be hard to implement, but 
so far I did not bother
to do so as I considered mail-fetching not part of alots responsibility.
But you're not the first one to want this, so I guess it'd be worth it.

Cheers,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: [alot] announcing v0.3.3

[Patrick Totzke]

Quoting Sepp Tannhuber (2012-09-11 17:59:12)
 Hi Patrick,
 
 thank you for answering and for this really good mail client!
pleasure :)

  One reason I have not bothered to implement this so far is that in the long 
  run,
  I want to have urwid Tree widgets as top level widgets in thread buffers.
  This would also allow move to next sibling/parent and so on.
 I did not know that it would be so complicated. But nice to hear that 
 development
 is going on.
Yea, trees in urwid are a bit messed up atm. alot's thread buffer uses its own
archaic widget layout, which is eventually to be replaced.

  So you can of course use this method to set an Attach header, but as of 
  now
  alot will not interpret and remove this when reading the edited text.
 Exactly!

I think this will not so hard to do. Could you open up a feature request issue
on github for this?

  When you see the to prompt, type in some prefix of a (realname part of a)
  contact from abook and hit tab.
 This was my assumption. But it is not working here. Obviously I make a 
 mistake. Here is my
 config:
 -- BEGIN ~/.config/alot/config --
 theme = solarized_dark
 editor_cmd = 'vim +/^$ +normal j +:set textwidth=80 +:set ft=mail'
 
 [accounts]
 
     [[work]]
         realname = Joseph Tannhuber
         address = jtannhu...@work.de
         signature = ~/.signature
         sendmail_command = msmtp --account=work -t
         sent_box = maildir:///home/sepp/Maildir/Sent
         draft_box = maildir:///home/sepp/Maildir/Drafts
         [[[abook]]]
             type = abook
 -- END --
 Is there anything missing?

No, that's what I use as well.
Note that this variant assumes your contact file is ~/.abook/addressbook. I'm 
not aware of format
issues for different abook versions so far. Also note that this will complete 
case-sensitive
strings of the format Firstname Lastname address.

To debug this you can replay this introspect session and see how far you get.
Start alots python shell (pyshell command), then:

 from alot.settings import settings
 settings.get_addressbooks()
[alot.addressbooks.MatchSdtoutAddressbook object at 0x2890a10, 
alot.addressbooks.AbookAddressBook object at 0x2776650]
 settings.get_addressbooks()[0]
alot.addressbooks.MatchSdtoutAddressbook object at 0x2890a10
 A=settings.get_addressbooks()[0]
 A.get_contacts()
[... CONTACT TUPLES HERE...]

Hope this helps. Otherwise don't hesitate to open a bug report on github.

 By the way: Is it possible to set the X11 urgency hint flag when new mail 
 arrives? In principle
 one can use the visual bell in the terminal. Then alot must only invoke a 
 shell command:
   echo -e \b

Well, alot does not pull your mails itself, so has no means of knowing when new 
mail arrives.
I personally use a mail indicator widget I wrote for my window manager that 
periodically
checks the notmuch index for new mail: 
http://awesome.naquadah.org/wiki/Notmuch_mail_integration

Alot can of course fire shell commands. What it is lacking at the moment is the 
ability to periodically
fire custom (alot-)commands. This feature would not be hard to implement, but 
so far I did not bother
to do so as I considered mail-fetching not part of alots responsibility.
But you're not the first one to want this, so I guess it'd be worth it.

Cheers,
/p


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

[alot] announcing v0.3.3

[Patrick Totzke]

Hi Sepp, welcome to alot :)

Quoting Sepp Tannhuber (2012-09-10 19:55:00)
> 1. As vi user I alway type gg/G to jump to the top/bottom. Is there a command 
> that I can
> ? ?configure this way? I have not found a jump to top/bottom command in the 
> manual.
Short Answer:
This is not yet possible with the current design, no.
It is something i'd also like to see though and i have already a few ideas ho 
to do this.

Long version/dev info:
First of all, i only recently added the ability to interpret "gg" (or other 
multi-key strokes)
at all.. so thats done.
Now both for thread and search mode we use a toplevel `urwid.ListBox` widget 
iirc,
and those do not directly support "focus topmost line". But they do allow to
move the focus to some index and so implementing such a `MoveCommand` should 
not be hard.
One reason I have not bothered to implement this so far is that in the long run,
I want to have urwid Tree widgets as top level widgets in thread buffers.
This would also allow "move to next sibling/parent" and so on.

> 2. Mutt has a nice feature, the Attach: pseudo header. It can be used to 
> attach files from
> ? ?within the editor. I use this small vi macro to attach files:
> ? ? ?" mutt: insert attachment with ranger
> 
> ? ? ?fun! RangerMuttAttach()
> ? ? ?if filereadable('/tmp/chosendir')
> ? ? ?silent !ranger --choosefiles=/tmp/chosenfiles --choosedir=/tmp/chosendir 
> "$(cat /tmp/chosendir)"
> ? ? ?else
> ? ? ?silent !ranger --choosefiles=/tmp/chosenfiles --choosedir=/tmp/chosendir
> ? ? ?endif
> ? ? ?if filereadable('/tmp/chosenfiles')
> ? ? ?call append(3, map(readfile('/tmp/chosenfiles'), '"Attach: 
> ".escape(v:val," \\")'))
> ? ? ?call system('rm /tmp/chosenfiles')
> ? ? ?endif
> ? ? ?redraw!
> ? ? ?endfun
> ? ? ?map  :call RangerMuttAttach()
> ? ? ?imap  :call RangerMuttAttach()a
> ? ?I would like to use the same with alot. Is it possible?

Nice idea!
So you can of course use this method to set an "Attach" header, but as of now
alot will not interpret and remove this when reading the edited text.
I guess one would also want that in the other direction if one really uses this 
feature:
When re-editing the message body, the editable headers part of the text should 
include
an Attach header line that lists the current attachments..

> 3. I have followed the instructions to use abook for contact completion. I 
> have used abook with mutt as well.
> ? ?So I have put these two?lines in my config:
> ? ? ?[[[abook]]]
> ? ? ? ?type = abook
> ? ?But I did not find a way how to use it. Can anybody tell me?

It will be used for tabcompletion when you compose a mesage.
When you see the "to>" prompt, type in some prefix of a (realname part of a)
contact from abook and hit .

Cheers,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: [alot] announcing v0.3.3

[Patrick Totzke]

Hi Sepp, welcome to alot :)

Quoting Sepp Tannhuber (2012-09-10 19:55:00)
 1. As vi user I alway type gg/G to jump to the top/bottom. Is there a command 
 that I can
    configure this way? I have not found a jump to top/bottom command in the 
 manual.
Short Answer:
This is not yet possible with the current design, no.
It is something i'd also like to see though and i have already a few ideas ho 
to do this.

Long version/dev info:
First of all, i only recently added the ability to interpret gg (or other 
multi-key strokes)
at all.. so thats done.
Now both for thread and search mode we use a toplevel `urwid.ListBox` widget 
iirc,
and those do not directly support focus topmost line. But they do allow to
move the focus to some index and so implementing such a `MoveCommand` should 
not be hard.
One reason I have not bothered to implement this so far is that in the long run,
I want to have urwid Tree widgets as top level widgets in thread buffers.
This would also allow move to next sibling/parent and so on.

 2. Mutt has a nice feature, the Attach: pseudo header. It can be used to 
 attach files from
    within the editor. I use this small vi macro to attach files:
       mutt: insert attachment with ranger
 
      fun! RangerMuttAttach()
      if filereadable('/tmp/chosendir')
      silent !ranger --choosefiles=/tmp/chosenfiles --choosedir=/tmp/chosendir 
 $(cat /tmp/chosendir)
      else
      silent !ranger --choosefiles=/tmp/chosenfiles --choosedir=/tmp/chosendir
      endif
      if filereadable('/tmp/chosenfiles')
      call append(3, map(readfile('/tmp/chosenfiles'), 'Attach: 
 .escape(v:val, \\)'))
      call system('rm /tmp/chosenfiles')
      endif
      redraw!
      endfun
      map C-a :call RangerMuttAttach()CR
      imap C-a ESC:call RangerMuttAttach()CRa
    I would like to use the same with alot. Is it possible?

Nice idea!
So you can of course use this method to set an Attach header, but as of now
alot will not interpret and remove this when reading the edited text.
I guess one would also want that in the other direction if one really uses this 
feature:
When re-editing the message body, the editable headers part of the text should 
include
an Attach header line that lists the current attachments..

 3. I have followed the instructions to use abook for contact completion. I 
 have used abook with mutt as well.
    So I have put these two lines in my config:
      [[[abook]]]
        type = abook
    But I did not find a way how to use it. Can anybody tell me?

It will be used for tabcompletion when you compose a mesage.
When you see the to prompt, type in some prefix of a (realname part of a)
contact from abook and hit tab.

Cheers,
/p


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

[alot] announcing v0.3.3

[Patrick Totzke]

Good news everyone!

I have just tagged alot v0.3.3; You can get a tarball here [0].
This version comes with lots of bugfixes and minor ui tweaks, most notably the
ability to interpret command sequences and sequences of keypresses.

It is now possible to overwrite default bindings which obsoletes the assumption
that all bindings are given in the users config. Therefore, we don't write a
config stub on startup if no user config file exists.

Detailed usage updates since v0.3.2:
* interpret (semicolon separated) sequences of commands
* new input handling: allow for binding sequences of keypresses
* add ability to overwrite default bindings
* remove tempfiles (email drafts) as late as possible for better error recovery
* confirmation prompt when closing unsent envelopes
* prevent accidental double sendout of envelopes
* fix focus placement after tagcommand on last entry in search buffer
* new command 'buffer' that can directly jump to buffer with given number
* extra: sup theme
* fix tagstring sorting in taglist buffer
* update docs
* lots of internal cleanups
* search buffer theming fixes (alignment of threadline parts)
* fix help box theming
* comma-separate virtual "Tags" header added before printing mails
* fix pipeto command for interactive (foreground) shell commands
* handle possible errors occurring while saving mails
* indicate (yet uninterpreted) input queue in the status bar
* handle python exceptions that occur during 'call' command

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.2...|tail -n +2
 5  Kazuo Teramoto
 3  Simon Chopin

.. and everyone who send feedback!

As always, don't hesitate to file bug reports, feature or pull requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.3
[1]: https://github.com/pazz/alot
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

[alot] announcing v0.3.3

[Patrick Totzke]

Good news everyone!

I have just tagged alot v0.3.3; You can get a tarball here [0].
This version comes with lots of bugfixes and minor ui tweaks, most notably the
ability to interpret command sequences and sequences of keypresses.

It is now possible to overwrite default bindings which obsoletes the assumption
that all bindings are given in the users config. Therefore, we don't write a
config stub on startup if no user config file exists.

Detailed usage updates since v0.3.2:
* interpret (semicolon separated) sequences of commands
* new input handling: allow for binding sequences of keypresses
* add ability to overwrite default bindings
* remove tempfiles (email drafts) as late as possible for better error recovery
* confirmation prompt when closing unsent envelopes
* prevent accidental double sendout of envelopes
* fix focus placement after tagcommand on last entry in search buffer
* new command 'buffer' that can directly jump to buffer with given number
* extra: sup theme
* fix tagstring sorting in taglist buffer
* update docs
* lots of internal cleanups
* search buffer theming fixes (alignment of threadline parts)
* fix help box theming
* comma-separate virtual Tags header added before printing mails
* fix pipeto command for interactive (foreground) shell commands
* handle possible errors occurring while saving mails
* indicate (yet uninterpreted) input queue in the status bar
* handle python exceptions that occur during 'call' command

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.2...|tail -n +2
 5  Kazuo Teramoto
 3  Simon Chopin

.. and everyone who send feedback!

As always, don't hesitate to file bug reports, feature or pull requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.3
[1]: https://github.com/pazz/alot


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

[announce] Bower 0.4

[Patrick Totzke]

Quoting David Froger (2012-08-12 16:53:43)
> > > 3. Would it be possible to have the feature 'kill a thread' like Sup 
> > > have? (see
> > > http://sup.rubyforge.org/README.txt).
> > 
> > I haven't needed such a feature so I don't have a clear idea how it
> > should work.  There are some patches/ideas about muting threads using
> > notmuch generally around here.  I guess the simplest thing to do is hide
> > a thread if it has a certain tag, e.g. "muted" as suggested by notmuch
> > TODO file, unless you search for it explicitly.
> I  like this  solution,  I will  use it (adding 'and not tag:mutted' at the 
> end of my search).
> When  I'm not  interessed with  a long discussion on a mailling list,  I like 
> to  be able to 'kill'
> the thread so it does not reappear with every new mail.

I'm not sure if this actually solves your problem, because
notmuch's search is message, not thread based:
If you search for threads that match "is:inbox and not is:muted", you will see 
threads
that contain messages which are tagged with "inbox" and not with "muted".
This means if you just tag one (or all) msg in a thread "muted" and there is a 
new response,
this thread will contain such a matching message again and show up in your 
result list.

To make this work, you need to set up your tagging script (that you run after 
'notmuch new')
so that it updates those new messages accordingly. If a msg belongs to a thread 
that has 
muted messages, also tag the new one muted.
I can pretty much recommend Justus' tagging script afew: 
https://github.com/teythoon/afew
One of the filters that it supports out of the box is exactly the "kill 
threads" function
you want.

HTH,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: [announce] Bower 0.4

[Patrick Totzke]

Quoting David Froger (2012-08-12 16:53:43)
   3. Would it be possible to have the feature 'kill a thread' like Sup 
   have? (see
   http://sup.rubyforge.org/README.txt).
  
  I haven't needed such a feature so I don't have a clear idea how it
  should work.  There are some patches/ideas about muting threads using
  notmuch generally around here.  I guess the simplest thing to do is hide
  a thread if it has a certain tag, e.g. muted as suggested by notmuch
  TODO file, unless you search for it explicitly.
 I  like this  solution,  I will  use it (adding 'and not tag:mutted' at the 
 end of my search).
 When  I'm not  interessed with  a long discussion on a mailling list,  I like 
 to  be able to 'kill'
 the thread so it does not reappear with every new mail.

I'm not sure if this actually solves your problem, because
notmuch's search is message, not thread based:
If you search for threads that match is:inbox and not is:muted, you will see 
threads
that contain messages which are tagged with inbox and not with muted.
This means if you just tag one (or all) msg in a thread muted and there is a 
new response,
this thread will contain such a matching message again and show up in your 
result list.

To make this work, you need to set up your tagging script (that you run after 
'notmuch new')
so that it updates those new messages accordingly. If a msg belongs to a thread 
that has 
muted messages, also tag the new one muted.
I can pretty much recommend Justus' tagging script afew: 
https://github.com/teythoon/afew
One of the filters that it supports out of the box is exactly the kill 
threads function
you want.

HTH,
/p


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

[alot] announcing v0.3.2

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.2; You can get a tarball here [0].
This version comes with redesigned theming features and supports
highlighting/retheming of thread lines in search mode based on
notmuch queries or thread tags.

I had to change the syntax of theme-files and custom tags-sections
of the config for this, so you'll have to revise your config.
The good news is that there are converter scripts included
to help you out with this:

* extra/tagsections_convert.py for your ~/.config/alot/config and 
* extra/theme_convert.py to update your custom theme files.

This release also features a colour picker (slightly modified version from [2])
that might turn out helpful when writing themes.
Check out extra/themes for some themes I made, and consider posting yours
for inclusion there..

Detailed usage updates since v0.3.1:
* fix bad GPG signatures for mails with attachments
* new theme-files + tags section syntax
* re-introduce "highlighting" of thread lines in search mode
* new global command "call" to directly call and bind python commands
* add new buffers to direct neighbourhood of current one
* fix sanitize --spawn for X11-less use
* add new hook 'touch_external_cmdlist'
* make statusline configurable
* fix update result count after tag operations in search mode
* add config options and hooks for reply/forward subject generation
* add config options and hook for quoting messages in replies/forwards
* allow True/False/None values for boolean command parameters
* new config option "attachment_prefix"
* various small fixes for libmagic, header encoding and decoding

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.1...|tail -n +2
10  Thomas Wei?schuh
 3  Michael Stapelberg
 1  bjoernb

.. and everyone who send feedback!

As always, don't hesitate to file bug reports, feature or pull requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.2
[1]: https://github.com/pazz/alot
[2]: https://github.com/wardi/urwid/blob/master/examples/palette_test.py
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

[alot] announcing v0.3.2

[Patrick Totzke]

Hi everyone!

I have just tagged alot v0.3.2; You can get a tarball here [0].
This version comes with redesigned theming features and supports
highlighting/retheming of thread lines in search mode based on
notmuch queries or thread tags.

I had to change the syntax of theme-files and custom tags-sections
of the config for this, so you'll have to revise your config.
The good news is that there are converter scripts included
to help you out with this:

* extra/tagsections_convert.py for your ~/.config/alot/config and 
* extra/theme_convert.py to update your custom theme files.

This release also features a colour picker (slightly modified version from [2])
that might turn out helpful when writing themes.
Check out extra/themes for some themes I made, and consider posting yours
for inclusion there..

Detailed usage updates since v0.3.1:
* fix bad GPG signatures for mails with attachments
* new theme-files + tags section syntax
* re-introduce highlighting of thread lines in search mode
* new global command call to directly call and bind python commands
* add new buffers to direct neighbourhood of current one
* fix sanitize --spawn for X11-less use
* add new hook 'touch_external_cmdlist'
* make statusline configurable
* fix update result count after tag operations in search mode
* add config options and hooks for reply/forward subject generation
* add config options and hook for quoting messages in replies/forwards
* allow True/False/None values for boolean command parameters
* new config option attachment_prefix
* various small fixes for libmagic, header encoding and decoding

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.1...|tail -n +2
10  Thomas Weißschuh
 3  Michael Stapelberg
 1  bjoernb

.. and everyone who send feedback!

As always, don't hesitate to file bug reports, feature or pull requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.2
[1]: https://github.com/pazz/alot
[2]: https://github.com/wardi/urwid/blob/master/examples/palette_test.py


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

Sending from multiple accounts

[Patrick Totzke]

try alot: multiple accounts [0] for free 
/p

[0] http://alot.readthedocs.org/en/latest/configuration/index.html#accounts

Quoting Michal Sojka (2012-05-23 11:29:27)
> Hi Doug,
> 
> Doug Penner  writes:
> > I am in the process of trying to migrate from alpine (which handles 
> > separate accounts *very* distinctly) to notmuch (which combines them). I 
> > have no problem with incoming e-mails being combined (actually looking 
> > forward to it) but am having a little trouble configuring outgoing e-mails 
> > to work correctly.
> >
> > I am currently using the vim interface (never like emacs, sorry) and have 
> > noticed that when replying, notmuch correctly uses the appropriate e-mail 
> > address (as defined in the To: or Cc: fields of the original), but does 
> > not have the ability to change the sender's "name".
> >
> > Ex: My "name" for my gmail account is "Doug Penner" (as you probably 
> > noticed with this on), but I also manage some other accounts where I do 
> > not go by this name. I manage a local organization's e-mail and need my 
> > sending name to be non-personal (ex: "This organization's Webmaster"). I 
> > can manually change the name before sending, but this gets very 
> > repetitive and annoying.
> >
> >
> > Is there any way to add names to the "alternate e-mails" setting in the 
> > .notmuch-config file? 
> 
> I don't think so. I use some elisp hooks within emacs interface for
> similar functionality but this wouldn't help in your case.
> 
> > I've tried switching to the standard "My Name"  and it then
> > completely fails to even detect that e-mail address as mine.
> 
> This should not be too hard to implement. There are gmime functions for
> email address manipulations which can be used to parse email addresses
> from .notmuch-config and to separate names from addresses.
> 
> Regards,
> -Michal
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

Re: Sending from multiple accounts

[Patrick Totzke]

try alot: multiple accounts [0] for free /spam
/p

[0] http://alot.readthedocs.org/en/latest/configuration/index.html#accounts

Quoting Michal Sojka (2012-05-23 11:29:27)
 Hi Doug,
 
 Doug Penner darwinsurvi...@gmail.com writes:
  I am in the process of trying to migrate from alpine (which handles 
  separate accounts *very* distinctly) to notmuch (which combines them). I 
  have no problem with incoming e-mails being combined (actually looking 
  forward to it) but am having a little trouble configuring outgoing e-mails 
  to work correctly.
 
  I am currently using the vim interface (never like emacs, sorry) and have 
  noticed that when replying, notmuch correctly uses the appropriate e-mail 
  address (as defined in the To: or Cc: fields of the original), but does 
  not have the ability to change the sender's name.
 
  Ex: My name for my gmail account is Doug Penner (as you probably 
  noticed with this on), but I also manage some other accounts where I do 
  not go by this name. I manage a local organization's e-mail and need my 
  sending name to be non-personal (ex: This organization's Webmaster). I 
  can manually change the name before sending, but this gets very 
  repetitive and annoying.
 
 
  Is there any way to add names to the alternate e-mails setting in the 
  .notmuch-config file? 
 
 I don't think so. I use some elisp hooks within emacs interface for
 similar functionality but this wouldn't help in your case.
 
  I've tried switching to the standard My Name e-mail and it then
  completely fails to even detect that e-mail address as mine.
 
 This should not be too hard to implement. There are gmime functions for
 email address manipulations which can be used to parse email addresses
 from .notmuch-config and to separate names from addresses.
 
 Regards,
 -Michal
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


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

[alot] announcing v0.3.1

[Patrick Totzke]

Quoting Jameson Graef Rollins (2012-05-17 16:42:53)
> On Thu, May 17 2012, Patrick Totzke  wrote:
> > With David Bremners help I have started hacking together some metadata to 
> > build
> > a debian package. This can be found in branch 'debian' but I presume there 
> > are still
> > some things to be done on that (manpage generation..).
> 
> Hi, Patrick.  I put together some Debian packaging a while back that I
> never did anything with:
> 
> git://finestructure.net/alot [debian]
> 
> It's a bit old, but it's mostly complete.  Hopefully you'll find it
> helpful.

Hey Jamie,

Ah yes, I forgot about this. Thanks for reminding me!
IIRC, I could not get this to "run through" on my machine but thats surely due
to my limited knowledge about debian packaging.
I'll have a look at this again and compare it with my stuff.
Cheers,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120517/91bd18a9/attachment.pgp>

[alot] announcing v0.3.1

[Patrick Totzke]

Hi everyone!

I have just released alot v0.3.1; You can get a tarball here [0].
This is mainly a bugfix release, the most notable addition feature-wise is
the ability to sign outgoing messages via PGP/MIME. Cheers to Michael for this 
one!

Detailed usage updates since v0.3:
* use separate database for each write-queue entry when flushing
* fix behaviour of editor spawning
* fix opening of attachments in thread buffer
* fix pre_edit_translate hook
* fix opening of attachments without filename Content-Disposition parm
* clean up and complete theming (bindings help/envelope/mainframe body)
* fix datetime decoding issues
* fix abort commands on pre-hook exceptions
* fix correct default sendmail command to 'sendmail -t'
* use '> ' instead of '>' to quote in replies/fwds
* fix path completer wrt spaces in paths
* fix UI when no buffers are open
* fix issue with buffer type changing between flushes
* support multiple addresses per abook contact when using 'abook' completer
* smarter timestamp pretty printer
* new hook 'timestamp_format'
* merge multiple cc/to headers into one when displaying
* respect NOTMUCH_CONFIG env var
* smarter parsing of edited header values
* allow for singleton lists without trailing comma in config
* fix reverse-date sorted content in threadline if displayed
* emacs-style C-a and C-E in prompts
* added ability to sign outgoing mails via PGP/MIME

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.. |tail -n +2
24  Michael Stapelberg
 5  Jakob
..everyone who send feedback and of course to all notmuch contributors.

With David Bremners help I have started hacking together some metadata to build
a debian package. This can be found in branch 'debian' but I presume there are 
still
some things to be done on that (manpage generation..).

As always, don't hesitate to send feedback, bug reports, feature or pull 
requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.1
[1]: https://github.com/pazz/alot
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: 

[alot] announcing v0.3.1

[Patrick Totzke]

Hi everyone!

I have just released alot v0.3.1; You can get a tarball here [0].
This is mainly a bugfix release, the most notable addition feature-wise is
the ability to sign outgoing messages via PGP/MIME. Cheers to Michael for this 
one!

Detailed usage updates since v0.3:
* use separate database for each write-queue entry when flushing
* fix behaviour of editor spawning
* fix opening of attachments in thread buffer
* fix pre_edit_translate hook
* fix opening of attachments without filename Content-Disposition parm
* clean up and complete theming (bindings help/envelope/mainframe body)
* fix datetime decoding issues
* fix abort commands on pre-hook exceptions
* fix correct default sendmail command to 'sendmail -t'
* use ' ' instead of '' to quote in replies/fwds
* fix path completer wrt spaces in paths
* fix UI when no buffers are open
* fix issue with buffer type changing between flushes
* support multiple addresses per abook contact when using 'abook' completer
* smarter timestamp pretty printer
* new hook 'timestamp_format'
* merge multiple cc/to headers into one when displaying
* respect NOTMUCH_CONFIG env var
* smarter parsing of edited header values
* allow for singleton lists without trailing comma in config
* fix reverse-date sorted content in threadline if displayed
* emacs-style C-a and C-E in prompts
* added ability to sign outgoing mails via PGP/MIME

Thanks goes to those who contributed:
$ git shortlog -s -n 0.3.. |tail -n +2
24  Michael Stapelberg
 5  Jakob
..everyone who send feedback and of course to all notmuch contributors.

With David Bremners help I have started hacking together some metadata to build
a debian package. This can be found in branch 'debian' but I presume there are 
still
some things to be done on that (manpage generation..).

As always, don't hesitate to send feedback, bug reports, feature or pull 
requests via the
projects github page [1].

Cheers,
/p

[0]: https://github.com/pazz/alot/tarball/0.3.1
[1]: https://github.com/pazz/alot


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

Re: [alot] announcing v0.3.1

[Patrick Totzke]

Quoting Jameson Graef Rollins (2012-05-17 16:42:53)
 On Thu, May 17 2012, Patrick Totzke patricktot...@googlemail.com wrote:
  With David Bremners help I have started hacking together some metadata to 
  build
  a debian package. This can be found in branch 'debian' but I presume there 
  are still
  some things to be done on that (manpage generation..).
 
 Hi, Patrick.  I put together some Debian packaging a while back that I
 never did anything with:
 
 git://finestructure.net/alot [debian]
 
 It's a bit old, but it's mostly complete.  Hopefully you'll find it
 helpful.

Hey Jamie,

Ah yes, I forgot about this. Thanks for reminding me!
IIRC, I could not get this to run through on my machine but thats surely due
to my limited knowledge about debian packaging.
I'll have a look at this again and compare it with my stuff.
Cheers,
/p


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

Passwordless multi-account SMTP

[Patrick Totzke]

Hi Jacek,

I am using msmtp for this: I keep my passwords in an encrypted
file and use a shellscript to decrypt and grep for passwords
in combination with msmtp's `passwordeval` option.
Have a look at

https://github.com/pazz/configs/blob/master/.msmtprc
https://github.com/pazz/scripts/blob/master/getpwd

I have a similar setup for offlineimap (configs also on github).
All this works quite nicely together with my ssh-agent (gnome-keyring-daemon)
which unlocks my gnupg keys upon login.
HTH,
/p


Quoting Jacek Generowicz (2012-04-03 16:29:07)
>Hello,
>
>I'm trying to use notmuch from Emacs. I have a number of SMTP accounts
>through which I would need to send mail. Suggested solutions I have
>found fall into 3 categories:
>
>+ Gnus posting styles. (I'd rather stay clear of gnus, at present.)
>
>+ Writing plaintext passwords in the MSMTP config files. (I'm rather
>  relutctant to leave plaintext passwords lying around.)
>
>+ Emacs' own SMTP library. (I don't understand how to get it to deal
>  with many accounts in a non-gnus based way. It also seems to be
>  undergoing an interface change in the transition from Emacs 23 to
>  24, and it was already confusing enough without that complication.)
>
>To further complicate matters, I'm looking for a solution which queues
>any messages which are sent while the machine is offline. (It seems
>that MSMTP and Emacs SMTP library do offer some help in those
>respects.)
>
>Hints gratefully received.
>
>Thank you.
>___
>notmuch mailing list
>notmuch at notmuchmail.org
>http://notmuchmail.org/mailman/listinfo/notmuch

Re: Passwordless multi-account SMTP

[Patrick Totzke]

Hi Jacek,

I am using msmtp for this: I keep my passwords in an encrypted
file and use a shellscript to decrypt and grep for passwords
in combination with msmtp's `passwordeval` option.
Have a look at

https://github.com/pazz/configs/blob/master/.msmtprc
https://github.com/pazz/scripts/blob/master/getpwd

I have a similar setup for offlineimap (configs also on github).
All this works quite nicely together with my ssh-agent (gnome-keyring-daemon)
which unlocks my gnupg keys upon login.
HTH,
/p


Quoting Jacek Generowicz (2012-04-03 16:29:07)
Hello,

I'm trying to use notmuch from Emacs. I have a number of SMTP accounts
through which I would need to send mail. Suggested solutions I have
found fall into 3 categories:

+ Gnus posting styles. (I'd rather stay clear of gnus, at present.)

+ Writing plaintext passwords in the MSMTP config files. (I'm rather
  relutctant to leave plaintext passwords lying around.)

+ Emacs' own SMTP library. (I don't understand how to get it to deal
  with many accounts in a non-gnus based way. It also seems to be
  undergoing an interface change in the transition from Emacs 23 to
  24, and it was already confusing enough without that complication.)

To further complicate matters, I'm looking for a solution which queues
any messages which are sent while the machine is offline. (It seems
that MSMTP and Emacs SMTP library do offer some help in those
respects.)

Hints gratefully received.

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

Questions from a user new to notmuch

[Patrick Totzke]

Quoting Austin Clements (2012-03-22 22:39:07)
>> 2. I received a message that was addressed to a distribution group and
>>tried to reply.  Because the TO: address is not my address, notmuch
>>fails to guess the proper FROM: address to set.  Is there a way to
>>handle this use case?  This is with the emacs notmuch client.
>
>Not in general, since notmuch doesn't know where the mail was
>addressed to.  I believe some people have solved problems like this
>using Emacs hooks, but I don't know the details.

Does the notmuch CLI not use the 'Delivered-To' header for this?
/p

Re: Questions from a user new to notmuch

[Patrick Totzke]

Quoting Austin Clements (2012-03-22 22:39:07)
 2. I received a message that was addressed to a distribution group and
tried to reply.  Because the TO: address is not my address, notmuch
fails to guess the proper FROM: address to set.  Is there a way to
handle this use case?  This is with the emacs notmuch client.

Not in general, since notmuch doesn't know where the mail was
addressed to.  I believe some people have solved problems like this
using Emacs hooks, but I don't know the details.

Does the notmuch CLI not use the 'Delivered-To' header for this?
/p
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[RFC][alot] design decisions

[Patrick Totzke]

Hi all,

with alot 0.3 released, I started thinking seriously about proper? MIME-display 
and gnupg
integration for alot. I have to make a few design decisions here and could 
really use
some informed opinions from more experienced UI developers. My question in 
particular is: 

 How do I best integrate calls to external mime-handlers into my MVC event 
driven code?

I mostly know how to implement the individual parts but I struggle coming up 
with a
consistent way of organizing it all without compromising my current layout.


Background
--

Model. Alot uses an abstraction layer over notmuch's thread, message and 
database objects
to make them less fragile and generally behave more OOP-y: You can e.g. 
directly call
message.add_tags(['foo','bar']) and so on. This is made possible by a 
"DatabaseManager"
that maintains centralized and queued access to the notmuch index and deals 
with notmuch
exceptions like a locked index [0].

View/Controler. We use an event-driven interface (urwid.TwistedEventLoop, [1]) 
that
handles user input and maintains a tree of widgets that knows how to render 
itself.
Twisted offers a neat concept of "Deferreds" to organize call- and errbacks 
that we
already make use of [2].  Alot has a "MessageWidget" that displays a single 
message.

We can easily access and parse email messages into MIME-trees (msg.get_email() 
returns a
email.message object; pythons email module allows extensive and RFC compliant 
dealing with
this [3]).

We already offer full compatibility with the mailcap protocol to constuct shell 
commands
of external MIME handlers.

We know how to call external commands asynchronously; 
`alot.helper.call_cmd_async` does this
and returns a Deferred to which we can connect callback functions.


Objective
-
We want to turn a email.message into nicely rendered text and display it as a 
widget.
Calls to renderers should be done asynchronously, so that displaying large 
threads
does not block the interface unnecessarily.
The text representation should be stored in a way that can be incrementally 
updated
for use with message parts decrypted at a later point.


Bad Solutions
-

1. Current solution: walk the MIME-tree depth-first, use blocking calls to 
handlers
and create a fixed "body" string that is displayed in the widget.
A silly and hackish solution that we want to get rid of for obvious reasons.

2. Use a "PartWidget" that is able to display a node in the MIME-tree:
Its constructor creates the representation in a RFC compliant way, that is,
it decodes 'text/plain' parts, stacks other widgets of the same kind on top of 
each other
for multipart parts or calls external renderer to get a text representation.

Cons:
 * widgets should not be clever and contain/construct any kind of additional 
info
 * its hard to update these widgets when a part gets decrypted; 
 * decrypted parts are not available outside the displaying widget, widgets get
   replaced completely when one rebuilds the buffer (refresh cmd)
Pros:
 * we can use Deferreds relatively painlessly in the ui (as opposed to the 
db-wrapper)

3. Accumulate rendered text in a tree structure *inside* message-objects and 
let that
massage update the widget that displays it. One could let the widget register
some update-callback with the widget that rebuilds the widgets content.
These callbacks are called after the external handler has finished and the 
message-
internal text-representation has been updated.

Pros: 
 * rendered text/decrypted message parts end up in the message and are 
available to process
   and redisplay at will
Cons:
 * the calls to MIME-handlers are dealt with as Deferreds which depend on the 
twisted event
   loop and indirectly on urwid. This is exactly the kind of tight coupling I'm 
trying to avoid:
   Messages should be independent of the interface.
 * Messages with multiple externally rendered parts will rebuild their widgets 
more than once
 * references to old widgets (replaced e.g. after a buffer rebuild) will be 
kept, which keeps
   them from being garbage-collected

I'm surely missing an easy and elegant solution here.
Any pointers or comments are much appreciated.
Thanks,
/p


[0]: http://alot.readthedocs.org/en/latest/api/database.html
[1]: http://excess.org/urwid/
[2]: http://twistedmatrix.com/documents/current/core/howto/defer.html
[3]: http://docs.python.org/library/email

[RFC] Split notmuch_database_close into two functions

[Patrick Totzke]

Hi all,

I can confirm that this fixes a rather nasty core dump in a branch of alot
that closes and re-opens the database more frequently.
/p

[RFC][alot] design decisions

[Patrick Totzke]

Hi all,

with alot 0.3 released, I started thinking seriously about proper™ MIME-display 
and gnupg
integration for alot. I have to make a few design decisions here and could 
really use
some informed opinions from more experienced UI developers. My question in 
particular is: 

 How do I best integrate calls to external mime-handlers into my MVC event 
driven code?

I mostly know how to implement the individual parts but I struggle coming up 
with a
consistent way of organizing it all without compromising my current layout.


Background
--

Model. Alot uses an abstraction layer over notmuch's thread, message and 
database objects
to make them less fragile and generally behave more OOP-y: You can e.g. 
directly call
message.add_tags(['foo','bar']) and so on. This is made possible by a 
DatabaseManager
that maintains centralized and queued access to the notmuch index and deals 
with notmuch
exceptions like a locked index [0].

View/Controler. We use an event-driven interface (urwid.TwistedEventLoop, [1]) 
that
handles user input and maintains a tree of widgets that knows how to render 
itself.
Twisted offers a neat concept of Deferreds to organize call- and errbacks 
that we
already make use of [2].  Alot has a MessageWidget that displays a single 
message.

We can easily access and parse email messages into MIME-trees (msg.get_email() 
returns a
email.message object; pythons email module allows extensive and RFC compliant 
dealing with
this [3]).

We already offer full compatibility with the mailcap protocol to constuct shell 
commands
of external MIME handlers.

We know how to call external commands asynchronously; 
`alot.helper.call_cmd_async` does this
and returns a Deferred to which we can connect callback functions.


Objective
-
We want to turn a email.message into nicely rendered text and display it as a 
widget.
Calls to renderers should be done asynchronously, so that displaying large 
threads
does not block the interface unnecessarily.
The text representation should be stored in a way that can be incrementally 
updated
for use with message parts decrypted at a later point.


Bad Solutions
-

1. Current solution: walk the MIME-tree depth-first, use blocking calls to 
handlers
and create a fixed body string that is displayed in the widget.
A silly and hackish solution that we want to get rid of for obvious reasons.

2. Use a PartWidget that is able to display a node in the MIME-tree:
Its constructor creates the representation in a RFC compliant way, that is,
it decodes 'text/plain' parts, stacks other widgets of the same kind on top of 
each other
for multipart parts or calls external renderer to get a text representation.

Cons:
 * widgets should not be clever and contain/construct any kind of additional 
info
 * its hard to update these widgets when a part gets decrypted; 
 * decrypted parts are not available outside the displaying widget, widgets get
   replaced completely when one rebuilds the buffer (refresh cmd)
Pros:
 * we can use Deferreds relatively painlessly in the ui (as opposed to the 
db-wrapper)

3. Accumulate rendered text in a tree structure *inside* message-objects and 
let that
massage update the widget that displays it. One could let the widget register
some update-callback with the widget that rebuilds the widgets content.
These callbacks are called after the external handler has finished and the 
message-
internal text-representation has been updated.

Pros: 
 * rendered text/decrypted message parts end up in the message and are 
available to process
   and redisplay at will
Cons:
 * the calls to MIME-handlers are dealt with as Deferreds which depend on the 
twisted event
   loop and indirectly on urwid. This is exactly the kind of tight coupling I'm 
trying to avoid:
   Messages should be independent of the interface.
 * Messages with multiple externally rendered parts will rebuild their widgets 
more than once
 * references to old widgets (replaced e.g. after a buffer rebuild) will be 
kept, which keeps
   them from being garbage-collected

I'm surely missing an easy and elegant solution here.
Any pointers or comments are much appreciated.
Thanks,
/p


[0]: http://alot.readthedocs.org/en/latest/api/database.html
[1]: http://excess.org/urwid/
[2]: http://twistedmatrix.com/documents/current/core/howto/defer.html
[3]: http://docs.python.org/library/email
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch