Re: "notmuch new" does not remove my file from db (double slash problem ?)
Hi François, hi lists, because this is an issue with notmuch integration, and you're now using neomutt, I suppose it's a good idea to move the discussion over the neomutt-devel list. I placed the reply-to header to follow-up on there and avoid cross posting to several lists. On Fri, Feb 10, 2017 at 09:47:13AM +0100, François wrote: > I had this same problem today and I think mutt whith notmuch patchs > (mutt-kz that I used at the time or neomutt from Debian which I use > now) generate those double slash when using the "copy" function from > mutt. could you exactly tell how we could replicate this, starting with using neomutt? -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: filter for List-Id ?
Hi, On Fri, Sep 30, 2016 at 02:00:50PM +, ng0 wrote: > Ricardo told me: > > Notmuch should be able to filter by list. With mu4e I match for > > “list:bug-guix.gnu.org”. All emails to the bug-* lists contain a header > > for “List-Id”, which you may be able to match on. > ( https://lists.gnu.org/archive/html/help-guix/2016-09/msg00082.html ) to get around that issue, what I do is that I added an afew rule that checks for the presence of `List-Id` and if there is, it's automagically adding the `ml` tag. Then when comes the time for searching, you can just select all mails that has a to/cc of gnu.org and the tag ml (which will exclude your direct correspondence with gnu members ☺). You can also add the content of the List-Id as a tag, but that can be dangerous… You never know what can of crazy 1000 characters thing you'll get in a spam (because some spamlists are using the `List-Id:` header!) HTH, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Xapian lockup when writing to the notmuch database
Hello list, On Wed, Jan 06, 2016 at 03:49:28PM +, Guyzmo wrote: […] > But when I do `notmuch new` it hangs. So I did ran it through gdb and here is > the result: […] > Until then, I’m just checking on this list for ideas and comments, in hope > for a working solution. Finally the working solution went from discussion with Bremner on IRC, as he asked whether the rpc.lockd was indeed running and accessible, I noticed that I meant the Maildir to be shared in NFSv4, and it ended up in NFSv3, without lockd support. After some configuration tweaking, and made sure it mounted in NFSv4, it finally worked out! Thank you Bremner, and thank you Olly for pinging me on IRC! Cheers, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Xapian lockup when writing to the notmuch database
Hello, I have migrated my mail configuration from an old machine to a new one, which is a xen server with several VM instances. I have one VM dedicated to do mail stuff, and I want to manage my Maildir using notmuch in another one. So I set up an NFSv4 share (with sync option set) from the mail server, to have my Maildir accessible from the other VM. Of course, I made sure my user is able to have full privileges over the mounted share, and there’s only one instance of notmuch running over that xapian db at all times. All read only operations work just perfectly fine, I can even run notmuch-kz and have it list my search mailboxes. But when I do `notmuch new` it hangs. So I did ran it through gdb and here is the result: % gdb notmuch (gdb) run new Starting program: /usr/local/bin/notmuch new [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". ^C Program received signal SIGINT, Interrupt. 0xb7fe1428 in __kernel_vsyscall () (gdb) bt #0 0xb7fe1428 in __kernel_vsyscall () #1 0xb7d2a953 in read () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb7adf538 in read (__nbytes=1, __buf=0xbfffedfc, __fd=) at /usr/include/i386-linux-gnu/bits/unistd.h:45 #3 FlintLock::lock (this=0x8079180, exclusive=true, explanation=...) at ../backends/flint_lock.cc:222 #4 0xb7b30a86 in ChertDatabase::get_database_write_lock (this=this@entry=0x80789a0, creating=creating@entry=false) at ../backends/chert/chert_database.cc:505 #5 0xb7b34fd2 in ChertDatabase::ChertDatabase (this=this@entry=0x80789a0, chert_dir=..., action=action@entry=1, block_size=block_size@entry=8192) at ../backends/chert/chert_database.cc:154 #6 0xb7b35554 in ChertWritableDatabase::ChertWritableDatabase (this=0x80789a0, dir=..., action=1, block_size=8192) at ../backends/chert/chert_database.cc:1036 #7 0xb7adcee4 in Xapian::WritableDatabase::WritableDatabase (this=0x80780c8, path=..., action=1) at ../backends/dbfactory.cc:490 #8 0xb7fb8c68 in notmuch_database_open_verbose (path=0x80780c8 "\340\327ŷ", mode=NOTMUCH_DATABASE_MODE_READ_WRITE, database=0xb230, status_string=0xb248) at lib/database.cc:933 #9 0x08054e93 in notmuch_new_command (config=0x80745b8, argc=1, argv=0xb678) at notmuch-new.c:1008 #10 0x0804df87 in main (argc=2, argv=0xb674) at notmuch.c:421 (gdb) then I tried doing another write operation, doing a `notmuch tag` command % gdb notmuch (gdb) run tag +tag id: (gdb) bt #0 0xb7fe1428 in __kernel_vsyscall () #1 0xb7d2a953 in read () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb7adf538 in read (__nbytes=1, __buf=0xbfffefac, __fd=) at /usr/include/i386-linux-gnu/bits/unistd.h:45 #3 FlintLock::lock (this=0x8079360, exclusive=true, explanation=...) at ../backends/flint_lock.cc:222 #4 0xb7b30a86 in ChertDatabase::get_database_write_lock (this=this@entry=0x8078b80, creating=creating@entry=false) at ../backends/chert/chert_database.cc:505 #5 0xb7b34fd2 in ChertDatabase::ChertDatabase (this=this@entry=0x8078b80, chert_dir=..., action=action@entry=1, block_size=block_size@entry=8192) at ../backends/chert/chert_database.cc:154 #6 0xb7b35554 in ChertWritableDatabase::ChertWritableDatabase (this=0x8078b80, dir=..., action=1, block_size=8192) at ../backends/chert/chert_database.cc:1036 #7 0xb7adcee4 in Xapian::WritableDatabase::WritableDatabase (this=0x80780c8, path=..., action=1) at ../backends/dbfactory.cc:490 #8 0xb7fb8c68 in notmuch_database_open_verbose (path=0x80780c8 "\340\327ŷ", mode=NOTMUCH_DATABASE_MODE_READ_WRITE, database=0xb3e4, status_string=0xb39c) at lib/database.cc:933 #9 0xb7fb975c in notmuch_database_open (path=0x8078068 "/home/guyzmo/Maildir", mode=mode@entry=NOTMUCH_DATABASE_MODE_READ_WRITE, database=database@entry=0xb3e4) at lib/database.cc:848 #10 0x0805cbe4 in notmuch_tag_command (config=0x80745b8, argc=3, argv=0xb638) at notmuch-tag.c:262 #11 0x0804df87 in main (argc=4, argv=0xb634) at notmuch.c:421 (gdb) I’m running notmuch on a Debian Jessie (v7), on which I compiled latest notmuch from git, using the repository’s libxapian which is v1.2.12-2. Now, I could use a newer version of libxapian, either V1.2.19 from the debian backports (https://packages.debian.org/jessie/libxapian22), or get the latest compiling it from sources, as it looks like the flintlock.cc compilation unit has been rewritten since v1.2.12 — though it looks like the part where it hangs is looking quite alike, but it’s hard to tell from the changes whether that would have an inpact. So my question is whether this is a known issue, and is actually related to the fact that I’m running it over NFS. I looked for NFS related comments on xapian website and so far I found nothing looking alike my issue. I’ll try testing with other versions of xapian and see it solves it. If the issue is still on with HEAD of xapian’s sources, th
Xapian lockup when writing to the notmuch database
Hello, I have migrated my mail configuration from an old machine to a new one, which is a xen server with several VM instances. I have one VM dedicated to do mail stuff, and I want to manage my Maildir using notmuch in another one. So I set up an NFSv4 share (with sync option set) from the mail server, to have my Maildir accessible from the other VM. Of course, I made sure my user is able to have full privileges over the mounted share, and there’s only one instance of notmuch running over that xapian db at all times. All read only operations work just perfectly fine, I can even run notmuch-kz and have it list my search mailboxes. But when I do `notmuch new` it hangs. So I did ran it through gdb and here is the result: % gdb notmuch (gdb) run new Starting program: /usr/local/bin/notmuch new [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". ^C Program received signal SIGINT, Interrupt. 0xb7fe1428 in __kernel_vsyscall () (gdb) bt #0 0xb7fe1428 in __kernel_vsyscall () #1 0xb7d2a953 in read () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb7adf538 in read (__nbytes=1, __buf=0xbfffedfc, __fd=) at /usr/include/i386-linux-gnu/bits/unistd.h:45 #3 FlintLock::lock (this=0x8079180, exclusive=true, explanation=...) at ../backends/flint_lock.cc:222 #4 0xb7b30a86 in ChertDatabase::get_database_write_lock (this=this@entry=0x80789a0, creating=creating@entry=false) at ../backends/chert/chert_database.cc:505 #5 0xb7b34fd2 in ChertDatabase::ChertDatabase (this=this@entry=0x80789a0, chert_dir=..., action=action@entry=1, block_size=block_size@entry=8192) at ../backends/chert/chert_database.cc:154 #6 0xb7b35554 in ChertWritableDatabase::ChertWritableDatabase (this=0x80789a0, dir=..., action=1, block_size=8192) at ../backends/chert/chert_database.cc:1036 #7 0xb7adcee4 in Xapian::WritableDatabase::WritableDatabase (this=0x80780c8, path=..., action=1) at ../backends/dbfactory.cc:490 #8 0xb7fb8c68 in notmuch_database_open_verbose (path=0x80780c8 "\340\327ŷ", mode=NOTMUCH_DATABASE_MODE_READ_WRITE, database=0xb230, status_string=0xb248) at lib/database.cc:933 #9 0x08054e93 in notmuch_new_command (config=0x80745b8, argc=1, argv=0xb678) at notmuch-new.c:1008 #10 0x0804df87 in main (argc=2, argv=0xb674) at notmuch.c:421 (gdb) then I tried doing another write operation, doing a `notmuch tag` command % gdb notmuch (gdb) run tag +tag id: (gdb) bt #0 0xb7fe1428 in __kernel_vsyscall () #1 0xb7d2a953 in read () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb7adf538 in read (__nbytes=1, __buf=0xbfffefac, __fd=) at /usr/include/i386-linux-gnu/bits/unistd.h:45 #3 FlintLock::lock (this=0x8079360, exclusive=true, explanation=...) at ../backends/flint_lock.cc:222 #4 0xb7b30a86 in ChertDatabase::get_database_write_lock (this=this@entry=0x8078b80, creating=creating@entry=false) at ../backends/chert/chert_database.cc:505 #5 0xb7b34fd2 in ChertDatabase::ChertDatabase (this=this@entry=0x8078b80, chert_dir=..., action=action@entry=1, block_size=block_size@entry=8192) at ../backends/chert/chert_database.cc:154 #6 0xb7b35554 in ChertWritableDatabase::ChertWritableDatabase (this=0x8078b80, dir=..., action=1, block_size=8192) at ../backends/chert/chert_database.cc:1036 #7 0xb7adcee4 in Xapian::WritableDatabase::WritableDatabase (this=0x80780c8, path=..., action=1) at ../backends/dbfactory.cc:490 #8 0xb7fb8c68 in notmuch_database_open_verbose (path=0x80780c8 "\340\327ŷ", mode=NOTMUCH_DATABASE_MODE_READ_WRITE, database=0xb3e4, status_string=0xb39c) at lib/database.cc:933 #9 0xb7fb975c in notmuch_database_open (path=0x8078068 "/home/guyzmo/Maildir", mode=mode@entry=NOTMUCH_DATABASE_MODE_READ_WRITE, database=database@entry=0xb3e4) at lib/database.cc:848 #10 0x0805cbe4 in notmuch_tag_command (config=0x80745b8, argc=3, argv=0xb638) at notmuch-tag.c:262 #11 0x0804df87 in main (argc=4, argv=0xb634) at notmuch.c:421 (gdb) I’m running notmuch on a Debian Wheezy, on which I compiled latest notmuch from git, using the repository’s libxapian which is v1.2.12-2. Now, I could use a newer version of libxapian, either V1.2.16 from the debian wheezy backports, or get the latest compiling it from sources, as it looks like the flintlock.cc compilation unit has been rewritten since v1.2.12 — though it looks like the part where it hangs is looking quite alike, but it’s hard to tell from the changes whether that would have an inpact. So my question is whether this is a known issue, and is actually related to the fact that I’m running it over NFS. I looked for NFS related comments on xapian website and so far I found nothing looking alike my issue. I’ll try testing with other versions of xapian and see it solves it. If the issue is still on with HEAD of xapian’s sources, then I’ll do a bug report. Until then, I’m just checking on t
argument parsing refactoring round3
Hi David, On Wed, Apr 08, 2015 at 04:30:38AM +0900, David Bremner wrote: > I think a dealt with all of Mark's comments, even "notmuch help > --help". > > I ended up creating a new function for the places where we want to > process _only_ the shared options (config, setup, and help) I see you patching and repatching notmuch's CLI to improve it, and I was wondering whether you had considered actually using `docopt` to generate the CLI parser from the output. It's possible to chain docopts to create a CLI UI very much alike the git command, and it's more easily maintainable, as you're actually generating the code from the `--help` page instead of the other way around, making you focus on how you want the user to use the CLI only. Here's the link to the C parser generator: https://github.com/docopt/docopt.c it might not be perfect as is, but it could be worth trying out? I actually never tried the .c version of docopt. I had a more extensive experience with the python version, and since then I totally dropped argparse. https://github.com/docopt/docopt.c I even tend to believe that one could create a full CLI using python+docopt to actually control notmuch using the python notmuch interface⦠Even though I'm pretty sure some would yell at me and want to burn me as an heretic just for suggesting that :-) what do you believe? -- Guyzmo
Re: argument parsing refactoring round3
Hi David, On Wed, Apr 08, 2015 at 04:30:38AM +0900, David Bremner wrote: I think a dealt with all of Mark's comments, even notmuch help --help. I ended up creating a new function for the places where we want to process _only_ the shared options (config, setup, and help) I see you patching and repatching notmuch's CLI to improve it, and I was wondering whether you had considered actually using `docopt` to generate the CLI parser from the output. It's possible to chain docopts to create a CLI UI very much alike the git command, and it's more easily maintainable, as you're actually generating the code from the `--help` page instead of the other way around, making you focus on how you want the user to use the CLI only. Here's the link to the C parser generator: https://github.com/docopt/docopt.c it might not be perfect as is, but it could be worth trying out? I actually never tried the .c version of docopt. I had a more extensive experience with the python version, and since then I totally dropped argparse. https://github.com/docopt/docopt.c I even tend to believe that one could create a full CLI using python+docopt to actually control notmuch using the python notmuch interface… Even though I'm pretty sure some would yell at me and want to burn me as an heretic just for suggesting that :-) what do you believe? -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Proposal: List-Id
On Mon, Mar 16, 2015 at 04:28:44PM +0100, Amadeusz ?o?nowski wrote: > There's afew [0]. One of its core features is tagging mails by List-Id. > [0] https://github.com/teythoon/afew wha, didn't know about it, GG, I might switch away from procmail! And that's a huge deal, as I've been using it for >15years :-) -- Guyzmo
Proposal: List-Id
Hi Harlan,
On Sun, Mar 15, 2015 at 07:02:56PM -0400, Harlan Lieberman-Berg wrote:
> One of my (few) problems right now with notmuch is around mailing lists
> that are copied, either as CC or BCC, on various emails that go around.
> My filtering inside notmuch right now doesn't catch all the messages,
> since the only tag I can match on is "to:foo at bar.org" and not all
> messages have the to rewritten.
I'm not sure to correctly understand your issue. You're talking about
looking up all mails that are of a given mailing list?
Then I'm not sure it needs notmuch to be patched, as this can be added
pretty easily using an incoming mail filter. I'm personally using
procmail, so it'd be one such as:
:0:notmuch.lock
* ^List-[Ii][dD]:.*
{
TAGS="${TAGS} +ml -inbox"
}
To have the inbox tag removed and the ml tag added.
Then I tend to use the right hand side of the `+` on incoming mail, so
that I can choose a unique tag for my mail filtering upon subscription
to the mailing list:
:0:notmuch.lock
* ^TO\/guyzmo\+[a-z0-9]+ at m0g\.net
* MATCH ?? ^guyzmo\+\/[a-z0-9]+
{
TAGS="+${MATCH}"
}
As an example, just look my From header here ;-)
> The standard for identifying mailing lists seems to be List-Id, as per
> RFC 2919. I can understand the desire to keep the number of headers
> included in the header block low, but I wonder if this might be a common
> enough use-case to suggest its inclusion.
> As a counter-argument, I can see the parallel to spam filtering which
> come with their own set of headers that are not special cased by
> notmuch, but there seems to be much more variety in headers there - as
> well as different user configurations.
One issue I can see for indexing `List-Id` is that even though there's
an RFC for that, the value given can be either a `name `, a
`mail` or a `name` field. There's no real rule and the content can
sometimes be quite unreliable when it comes to index search.
I believe that this discussion has happened in the past, and IIRC, the
output that it was not to be integrated.
HTH,
--
Guyzmo
Re: Proposal: List-Id
Hi Harlan,
On Sun, Mar 15, 2015 at 07:02:56PM -0400, Harlan Lieberman-Berg wrote:
One of my (few) problems right now with notmuch is around mailing lists
that are copied, either as CC or BCC, on various emails that go around.
My filtering inside notmuch right now doesn't catch all the messages,
since the only tag I can match on is to:f...@bar.org and not all
messages have the to rewritten.
I'm not sure to correctly understand your issue. You're talking about
looking up all mails that are of a given mailing list?
Then I'm not sure it needs notmuch to be patched, as this can be added
pretty easily using an incoming mail filter. I'm personally using
procmail, so it'd be one such as:
:0:notmuch.lock
* ^List-[Ii][dD]:.*
{
TAGS=${TAGS} +ml -inbox
}
To have the inbox tag removed and the ml tag added.
Then I tend to use the right hand side of the `+` on incoming mail, so
that I can choose a unique tag for my mail filtering upon subscription
to the mailing list:
:0:notmuch.lock
* ^TO\/guyzmo\+[a-z0-9]+@m0g\.net
* MATCH ?? ^guyzmo\+\/[a-z0-9]+
{
TAGS=+${MATCH}
}
As an example, just look my From header here ;-)
The standard for identifying mailing lists seems to be List-Id, as per
RFC 2919. I can understand the desire to keep the number of headers
included in the header block low, but I wonder if this might be a common
enough use-case to suggest its inclusion.
As a counter-argument, I can see the parallel to spam filtering which
come with their own set of headers that are not special cased by
notmuch, but there seems to be much more variety in headers there - as
well as different user configurations.
One issue I can see for indexing `List-Id` is that even though there's
an RFC for that, the value given can be either a `name mail`, a
`mail` or a `name` field. There's no real rule and the content can
sometimes be quite unreliable when it comes to index search.
I believe that this discussion has happened in the past, and IIRC, the
output that it was not to be integrated.
HTH,
--
Guyzmo
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Proposal: List-Id
On Mon, Mar 16, 2015 at 04:28:44PM +0100, Amadeusz Żołnowski wrote: There's afew [0]. One of its core features is tagging mails by List-Id. [0] https://github.com/teythoon/afew wha, didn't know about it, GG, I might switch away from procmail! And that's a huge deal, as I've been using it for 15years :-) -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
ANNOUNCE: notmuch-abook v1.6 [Was: Re: ANNOUNCE: nottoomuch-addresses.sh 2.3]
Hello there, On Wed, Sep 17, 2014 at 10:02:57PM +0300, Tomi Ollila wrote: I'm pleased to announce new version of my caching address completer system for notmuch, version 2.3 (2014-09-17). I have also developed something similar a while ago, which has been greatly improved by the community: https://github.com/guyzmo/notmuch-abook It's written in python, integrates nicely as a vim plugin, for the vim users around. It stores email addresses in a sqlite database, and the configuration lies in the `~/.notmuch-config`. It can be installed using `pip install notmuch_abook` (slap me if I forget to update the pipy package!). For the occasion, I'd like to thank a lot the contributors (github usernames): * foobacca, * jkr, * Tomas Tomecek, * dme Of course, don't hesitate to troll^Wdiscuss about the pros and cons of both solutions, which may help improve both in the end! Cheers and a lots of thank to all notmuch contributors! -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
ANNOUNCE: notmuch-abook v1.6 [Was: Re: ANNOUNCE: nottoomuch-addresses.sh 2.3]
Hello there, On Wed, Sep 17, 2014 at 10:02:57PM +0300, Tomi Ollila wrote: > I'm pleased to announce new version of my caching address completer > system for notmuch, version 2.3 (2014-09-17). I have also developed something similar a while ago, which has been greatly improved by the community: https://github.com/guyzmo/notmuch-abook It's written in python, integrates nicely as a vim plugin, for the vim users around. It stores email addresses in a sqlite database, and the configuration lies in the `~/.notmuch-config`. It can be installed using `pip install notmuch_abook` (slap me if I forget to update the pipy package!). For the occasion, I'd like to thank a lot the contributors (github usernames): * foobacca, * jkr, * Tomas Tomecek, * dme Of course, don't hesitate to troll^Wdiscuss about the pros and cons of both solutions, which may help improve both in the end! Cheers and a lots of thank to all notmuch contributors! -- Guyzmo
Github?
On Thu, May 08, 2014 at 10:30:19PM +0200, Suvayu Ali wrote: > On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote: > > On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine > > wrote: [...] > > Can you guys at least consider splitting contrib/ and bindings/ into their > > own repo? It will make it easier for people to use the go bindings (for > > example) or to include the vim plugin as a submodule (or Vundle bundle). > > What is the problem if contrib and bindings are part of the main repo? > In fact I would argue it is undesirable to split them. If there are > major changes in libnotmuch, or the cli, it is much easier to make the > corresponding changes in bindings to keep everything working. If there > is a separate repo, communicating this dependency, although not > impossible, is difficult. I would also like to point out almost all > FOSS projects I follow, or contribute to practises this. do you know about git submodules? It's actually there to be able to track changes on remote repositories that are closely related, while keeping a sane separation. N.B.: the downside of something like notmuch, it's that it's making it a pleasure again to write and check mails, and thus it's easy to ends up discussing trivialities that can end up in endless trolls. my 2 cts as well, -- Guyzmo
Github?
Hi, On Thu, May 08, 2014 at 09:40:45AM +0100, Eric wrote: > On Thu, 08 May 2014 09:13:56 +0200, Jani Nikula wrote: > > On Thu, 08 May 2014, Wael Nasreddine wrote: [...] > >> Any thoughts on moving to Github? > > http://mid.gmane.org/87wqea7c37.fsf at nikula.org > Exactly! it feels like there's an echo in the room ;-) > >> I took the liberty of making the first move by > >> creating https://github.com/notmuch and splitting the contrib/ and binding/ > >> into their own repository (conserving all their history). > > I am concerned people will mistake that for the official notmuch > > repository. > Me too! I am just a (happy) user here, but I do know that the sort > of confusion that might arise can work against acceptance of a piece > of software. I think that doing this without waiting for feedback, > especially from the people who do most of the work on notmuch, is > somewhat high-handed. well, because of git's fundamental feature to be distributed, I see no reason why notmuch couldn't have a *mirror* on github, as well as on gitorious or bitbucket. As long as the description says explicitly: *mirror of the http://git.notmuchmail.org/git/notmuch repository* and that the README.md starts by giving where the official repo is, and explains how to submit patches. And *always* refuse to merge in pull requests. A good thing would be to have it automatically kept in sync with the original repository, and a nice way to do it would be to create a post-receive hook on the principal repository. As a nice side effect of doing this, we'll stop having users complain about "not being on github"... Even though they should understand that this is github that has a design flaw not being able to track forks coming from outside of github, or getting out of github. my 2 cents, -- Guyzmo
Re: Github?
Hi, On Thu, May 08, 2014 at 09:40:45AM +0100, Eric wrote: On Thu, 08 May 2014 09:13:56 +0200, Jani Nikula j...@nikula.org wrote: On Thu, 08 May 2014, Wael Nasreddine wael.nasredd...@gmail.com wrote: [...] Any thoughts on moving to Github? http://mid.gmane.org/87wqea7c37@nikula.org Exactly! it feels like there's an echo in the room ;-) I took the liberty of making the first move by creating https://github.com/notmuch and splitting the contrib/ and binding/ into their own repository (conserving all their history). I am concerned people will mistake that for the official notmuch repository. Me too! I am just a (happy) user here, but I do know that the sort of confusion that might arise can work against acceptance of a piece of software. I think that doing this without waiting for feedback, especially from the people who do most of the work on notmuch, is somewhat high-handed. well, because of git's fundamental feature to be distributed, I see no reason why notmuch couldn't have a *mirror* on github, as well as on gitorious or bitbucket. As long as the description says explicitly: *mirror of the http://git.notmuchmail.org/git/notmuch repository* and that the README.md starts by giving where the official repo is, and explains how to submit patches. And *always* refuse to merge in pull requests. A good thing would be to have it automatically kept in sync with the original repository, and a nice way to do it would be to create a post-receive hook on the principal repository. As a nice side effect of doing this, we'll stop having users complain about not being on github... Even though they should understand that this is github that has a design flaw not being able to track forks coming from outside of github, or getting out of github. my 2 cents, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Github?
On Thu, May 08, 2014 at 10:30:19PM +0200, Suvayu Ali wrote: On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote: On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine wael.nasredd...@gmail.comwrote: [...] Can you guys at least consider splitting contrib/ and bindings/ into their own repo? It will make it easier for people to use the go bindings (for example) or to include the vim plugin as a submodule (or Vundle bundle). What is the problem if contrib and bindings are part of the main repo? In fact I would argue it is undesirable to split them. If there are major changes in libnotmuch, or the cli, it is much easier to make the corresponding changes in bindings to keep everything working. If there is a separate repo, communicating this dependency, although not impossible, is difficult. I would also like to point out almost all FOSS projects I follow, or contribute to practises this. do you know about git submodules? It's actually there to be able to track changes on remote repositories that are closely related, while keeping a sane separation. N.B.: the downside of something like notmuch, it's that it's making it a pleasure again to write and check mails, and thus it's easy to ends up discussing trivialities that can end up in endless trolls. my 2 cts as well, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Feature suggestion. Indexing encrypted mail?
Hi! On Sat, Apr 05, 2014 at 12:09:32PM -0700, Jameson Graef Rollins wrote: > On Sat, Apr 05 2014, David Bremner wrote: > > john.wyzer at gmx.de writes: > >> Would it be possible to add the configurable option to also decrypt > >> encrypted messages on the fly while indexing to make them searchable, > >> too? > > As far I understand an attacker could reconstruct the message from the > > index, so one question is whether the extra complexity in notmuch is > > worth the minimal extra security over decrypting on delivery and storing > > plaintext on the (presumably encrypted) disk. Of course decrypting on > > delivery may be inconvenient (or impossible). I have CCed the two people > > who have implemented most of the crypto related stuff in notmuch so they > > can comment. > Indexing encrypted email is a bit of a foot-gun, since, as David > mentions, it is apparently possible to reconstruct encrypted messages > From the index. It therefore needs to be approached with care. > > I think decrypting on "delivery" (or mail fetch or whatever) sounds > difficult and unwieldy. In either event, it seems out of the scope of > notmuch. If a user figured out how to have that done, no changes to > notmuch would be needed afaict. [?] I indeed agree with this view, and I think the best process would be to have the MUA decrypt and index an encrypted mail when the user wants it to be indexed. So the user do not get really highly secret messages disclosable by the index, and for the others take that kind of risk. That way you wouldn't need to keep the secret in the gpg-agent for too long, and/or need a password for an automated process. my two cents, -- Guyzmo
Re: Feature suggestion. Indexing encrypted mail?
Hi! On Sat, Apr 05, 2014 at 12:09:32PM -0700, Jameson Graef Rollins wrote: On Sat, Apr 05 2014, David Bremner da...@tethera.net wrote: john.wy...@gmx.de writes: Would it be possible to add the configurable option to also decrypt encrypted messages on the fly while indexing to make them searchable, too? As far I understand an attacker could reconstruct the message from the index, so one question is whether the extra complexity in notmuch is worth the minimal extra security over decrypting on delivery and storing plaintext on the (presumably encrypted) disk. Of course decrypting on delivery may be inconvenient (or impossible). I have CCed the two people who have implemented most of the crypto related stuff in notmuch so they can comment. Indexing encrypted email is a bit of a foot-gun, since, as David mentions, it is apparently possible to reconstruct encrypted messages From the index. It therefore needs to be approached with care. I think decrypting on delivery (or mail fetch or whatever) sounds difficult and unwieldy. In either event, it seems out of the scope of notmuch. If a user figured out how to have that done, no changes to notmuch would be needed afaict. […] I indeed agree with this view, and I think the best process would be to have the MUA decrypt and index an encrypted mail when the user wants it to be indexed. So the user do not get really highly secret messages disclosable by the index, and for the others take that kind of risk. That way you wouldn't need to keep the secret in the gpg-agent for too long, and/or need a password for an automated process. my two cents, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
OSX 10.6 support
Hi, On Mon, Sep 23, 2013 at 08:04:32AM -0700, Justin Pitts wrote: [...] > The options here are > 1. Leave homebrew's version of notmuch at 0.15.2 > 2. Update notmuch there to 0.16, with the caveat that it will not build on > OSX 10.6 > 3. Update notmuch to 0.16, along with necessary changes to make it build on > OSX 10.6 and why not configure the homebrew formula for notmuch to also offer 0.15.2, and install that version on 10.6.* systems, while still installing 0.16 (and HEAD) on 10.8 systems? That'd make a good 4. imho! HTH, -- Guyzmo
Re: OSX 10.6 support
Hi, On Mon, Sep 23, 2013 at 08:04:32AM -0700, Justin Pitts wrote: [...] The options here are 1. Leave homebrew's version of notmuch at 0.15.2 2. Update notmuch there to 0.16, with the caveat that it will not build on OSX 10.6 3. Update notmuch to 0.16, along with necessary changes to make it build on OSX 10.6 and why not configure the homebrew formula for notmuch to also offer 0.15.2, and install that version on 10.6.* systems, while still installing 0.16 (and HEAD) on 10.8 systems? That'd make a good 4. imho! HTH, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Links in email messages
Hi, On Mon, Jul 15, 2013 at 03:34:26PM +1000, Bart Bunting wrote: > Sorry if this is an obvious question... this is not obvious at all, your question lacks a lot of precisions. You're asking the maling list which topic is notmuch that does email indexing, and is not a MTA. > I am having trouble activating links in emails. I guess what I > intuitively expect to happen is that if i hit enter on a link that it > opens up using browse-url-at-point or similar. > All that appears to happen is that the message I'm viewing collapses. > I would also if possible like urls to be active in text messages as > well. - what MTA (aka e-mail client) are you using? - what do you mean by "activating links"? Clicking on them? Or do you try to open them using your mind? Usually for text MTAs (such as mutt or afew), this is not their role to handle url, but the graphical terminal emulator to handle that. If you use gnome-terminal, for example, it has a configuration to help one detect URLs in its buffer. Cheers, -- Guyzmo
the future of notmuch-vim?
Hi On Tue, Apr 02, 2013 at 01:55:13PM -0600, Felipe Contreras wrote: > Sorry for the late reply, I wasn't following the ml. same here > David Bremner wrote: > > - There are now several alternatives for people whose only motivation to > > use the vim frontend was dislike of emacs (alot and notmuch-mutt). > I did try the emacs frontend, and it was not working properly for me at the > time, and I believe I documented my issues. It was not just my dislike of > emacs > that motivated me to write notmuch-vim-ruby. I'd say not liking emacs is not a good reason for using vim as a MUA. Vim is just a text editor, and nothing else. > > There are several alternative vim frontends floating around in (at > > least) ruby and python. I don't if they are better or worse > > functionality wise. > I'd say notmuch-vim-ruby is the best one, but of course I'm biased :) 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. I personnally prefer a thousand times to use mutt-kz, alot as MUA, and vim only for writing mails. And by the way, to make vim better at writing emails, I had a hard time finding how to implement a way to lookup addresses fields' values fastly using the python API. The method I found (based on the python addressbook lookup script) takes about 20s for about 1 mails. Is it the python binding that's flawed? Or the way addresses fields are stored? Maybe something could be done. > > it to contrib. Or, deprecating it and then removing it. > > What do people think? > Personally I think notmuch-vim should be replaced with notmuch-vim-ruby. I did > try the python version, and remember discussing options with the guy > developing > it, but nothing happened out of it, and I think the ruby version is superior. > I'd be open to discuss the options here, but I think notmuch-vim-ruby is the > only real option. 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. HTH, -- Guyzmo
Re: the future of notmuch-vim?
Hi On Tue, Apr 02, 2013 at 01:55:13PM -0600, Felipe Contreras wrote: Sorry for the late reply, I wasn't following the ml. same here David Bremner wrote: - There are now several alternatives for people whose only motivation to use the vim frontend was dislike of emacs (alot and notmuch-mutt). I did try the emacs frontend, and it was not working properly for me at the time, and I believe I documented my issues. It was not just my dislike of emacs that motivated me to write notmuch-vim-ruby. I'd say not liking emacs is not a good reason for using vim as a MUA. Vim is just a text editor, and nothing else. There are several alternative vim frontends floating around in (at least) ruby and python. I don't if they are better or worse functionality wise. I'd say notmuch-vim-ruby is the best one, but of course I'm biased :) 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. I personnally prefer a thousand times to use mutt-kz, alot as MUA, and vim only for writing mails. And by the way, to make vim better at writing emails, I had a hard time finding how to implement a way to lookup addresses fields' values fastly using the python API. The method I found (based on the python addressbook lookup script) takes about 20s for about 1 mails. Is it the python binding that's flawed? Or the way addresses fields are stored? Maybe something could be done. it to contrib. Or, deprecating it and then removing it. What do people think? Personally I think notmuch-vim should be replaced with notmuch-vim-ruby. I did try the python version, and remember discussing options with the guy developing it, but nothing happened out of it, and I think the ruby version is superior. I'd be open to discuss the options here, but I think notmuch-vim-ruby is the only real option. 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. HTH, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Updated mutt wikipage, new addressbook script: notmuch-abook
On Thu, Mar 28, 2013 at 08:34:44PM +0200, Jani Nikula wrote: > On Mon, 25 Mar 2013, Guyzmo <guyzmo+notmuch at m0g.net> wrote: > > I was actually looking for a page that is alike the emacstips one. I > > thought the notmuch-mutt page would be that one. But you may be right, > > and it'd be better to either rename that page or create a new one that > > would be "muttandvimtips" or so? > Yup, http://notmuchmail.org/notmuch-mutt/ was really about notmuch-mutt, > the notmuch integration script that ships with notmuch. I think "mutt > tips" and "vim tips" really should be pages of their own. ok, I updated the wiki, restoring nocmuch-mutt and created mutttips and vimtips pages while cheers, -- Guyzmo
Re: Updated mutt wikipage, new addressbook script: notmuch-abook
On Thu, Mar 28, 2013 at 08:34:44PM +0200, Jani Nikula wrote: On Mon, 25 Mar 2013, Guyzmo guyzmo+notm...@m0g.net wrote: I was actually looking for a page that is alike the emacstips one. I thought the notmuch-mutt page would be that one. But you may be right, and it'd be better to either rename that page or create a new one that would be muttandvimtips or so… Yup, http://notmuchmail.org/notmuch-mutt/ was really about notmuch-mutt, the notmuch integration script that ships with notmuch. I think mutt tips and vim tips really should be pages of their own. ok, I updated the wiki, restoring nocmuch-mutt and created mutttips and vimtips pages while cheers, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Updated mutt wikipage, new addressbook script: notmuch-abook
On Mon, Mar 25, 2013 at 09:26:20AM +0200, Jani Nikula wrote: > On Mar 22, 2013 5:22 PM, "Guyzmo" <guyzmo+notmuch at m0g.net> wrote: > > So I updated the notmuchmail.org wikipage about mutt: > > http://notmuchmail.org/notmuch-mutt/ > I think it would be best to keep notmuch-mutt and mutt-kz related pages > separate. They are two very different things. See > http://notmuchmail.org/frontends/ I was actually looking for a page that is alike the emacstips one. I thought the notmuch-mutt page would be that one. But you may be right, and it'd be better to either rename that page or create a new one that would be "muttandvimtips" or so? cheers, -- Guyzmo
Re: Updated mutt wikipage, new addressbook script: notmuch-abook
On Mon, Mar 25, 2013 at 09:26:20AM +0200, Jani Nikula wrote: On Mar 22, 2013 5:22 PM, Guyzmo guyzmo+notm...@m0g.net wrote: So I updated the notmuchmail.org wikipage about mutt: http://notmuchmail.org/notmuch-mutt/ I think it would be best to keep notmuch-mutt and mutt-kz related pages separate. They are two very different things. See http://notmuchmail.org/frontends/ I was actually looking for a page that is alike the emacstips one. I thought the notmuch-mutt page would be that one. But you may be right, and it'd be better to either rename that page or create a new one that would be muttandvimtips or so… cheers, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Updated mutt wikipage, new addressbook script: notmuch-abook
Hello world, I'm using notmuch and mutt-kz flawlessly for over a year, and I'm really happy with them, so thank you guys for providing such great tools! So I updated the notmuchmail.org wikipage about mutt: http://notmuchmail.org/notmuch-mutt/ I also wanted to enable completion from within vim, so I extended the mutt_addresses.py script, so it creates and updates a cache of addresses in a sqlite3 database. It is available on pypi, so you can use it as a standalone CLI application: https://github.com/guyzmo/notmuch-abook/ About that one, I made the choice to use sqlite3 as backend, because it was an easy way to create fast queries of addresses, but I was wondering if it would not be more intelligent to integrate the addresses indexing in the xapian database directly? And finally, I have tried to compile the vala-notmuch addressbook, but the compilation is failing because of some change in the database_open call, and I don't have much time to understand Vala's API mappings to C. But I've been told it is lightning fast when querying notmuch directly. Has anyone patched that code, and still use it with latest notmuch? I'd give it a try to replace my sqlite3 backend in the script. Cheers, -- Guyzmo
Updated mutt wikipage, new addressbook script: notmuch-abook
Hello world, I'm using notmuch and mutt-kz flawlessly for over a year, and I'm really happy with them, so thank you guys for providing such great tools! So I updated the notmuchmail.org wikipage about mutt: http://notmuchmail.org/notmuch-mutt/ I also wanted to enable completion from within vim, so I extended the mutt_addresses.py script, so it creates and updates a cache of addresses in a sqlite3 database. It is available on pypi, so you can use it as a standalone CLI application: https://github.com/guyzmo/notmuch-abook/ About that one, I made the choice to use sqlite3 as backend, because it was an easy way to create fast queries of addresses, but I was wondering if it would not be more intelligent to integrate the addresses indexing in the xapian database directly? And finally, I have tried to compile the vala-notmuch addressbook, but the compilation is failing because of some change in the database_open call, and I don't have much time to understand Vala's API mappings to C. But I've been told it is lightning fast when querying notmuch directly. Has anyone patched that code, and still use it with latest notmuch? I'd give it a try to replace my sqlite3 backend in the script. Cheers, -- Guyzmo ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Procmail regex group reuse
Hello,
On Wed, Mar 13, 2013 at 12:16:29PM -0700, Istvan Marko wrote:
> Guyzmo <guyzmo+notmuch at m0g.net> writes:
> > Would it be possible to reuse a part of the match regexp in procmail
> > so it can be reused in the action part of the rule.
[...]
> So you get everything between \/ to the end of the whole regexp. In your
> case this will get hairy because you need to match stuff after the part
> you want to extract. The ?? construct might help to further trim it
> down, maybe something like:
>
> * ^TO\/foo\+[a-z]+ at mydomain\.tld
> * MATCH ?? ^foo\+\/[a-z]+
> {
> TAG=$MATCH
> }
interesting, I'll try hacking around that?
> Or if you are willing to switch to maildrop it has pcre and proper
> submatches.
or I may switch to maildrop, I used it at one point with courier for my
imag installation, but always stuck to procmail before switching to sup,
and naturally got back to procmail when I installed notmuch.
> Are you tagging with notmuch-deliver?
Yes, I am, is there best ways to filter incoming mails, as I'm using
notmuch on the same host as my MTA?
Thanks,
--
Guyzmo
Procmail regex group reuse
Hello,
I have looked over that usage pattern over the procmail doc and
mailing lists for some time now, and it seems no one ever asked the
question:
Would it be possible to reuse a part of the match regexp in procmail
so it can be reused in the action part of the rule. Something like the
following:
8<8<8<---8<
:0:notmuch.lock
* .*foo\+\(\w+\)@mydomain\.tld.*
{
TAGS="${TAGS} $1"
}
>8>8>8--->8
where "$1" would be the group match (like `\1` in sed). I used
to do it easily when I was using sup, and I really miss it now that I
have switched to notmuch.
Maybe I shall use another mail matching program like formail, or
shall I write a patch for it, but I'd like first to ask here if someone
had the same issue, and found a solution.
--
Guyzmo
Procmail regex group reuse
Hello,
I have looked over that usage pattern over the procmail doc and
mailing lists for some time now, and it seems no one ever asked the
question:
Would it be possible to reuse a part of the match regexp in procmail
so it can be reused in the action part of the rule. Something like the
following:
888---8
:0:notmuch.lock
* .*foo\+\(\w+\)@mydomain\.tld.*
{
TAGS=${TAGS} $1
}
888---8
where $1 would be the group match (like `\1` in sed). I used
to do it easily when I was using sup, and I really miss it now that I
have switched to notmuch.
Maybe I shall use another mail matching program like formail, or
shall I write a patch for it, but I'd like first to ask here if someone
had the same issue, and found a solution.
--
Guyzmo
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Procmail regex group reuse
Hello,
On Wed, Mar 13, 2013 at 12:16:29PM -0700, Istvan Marko wrote:
Guyzmo guyzmo+notm...@m0g.net writes:
Would it be possible to reuse a part of the match regexp in procmail
so it can be reused in the action part of the rule.
[...]
So you get everything between \/ to the end of the whole regexp. In your
case this will get hairy because you need to match stuff after the part
you want to extract. The ?? construct might help to further trim it
down, maybe something like:
* ^TO\/foo\+[a-z]+@mydomain\.tld
* MATCH ?? ^foo\+\/[a-z]+
{
TAG=$MATCH
}
interesting, I'll try hacking around that…
Or if you are willing to switch to maildrop it has pcre and proper
submatches.
or I may switch to maildrop, I used it at one point with courier for my
imag installation, but always stuck to procmail before switching to sup,
and naturally got back to procmail when I installed notmuch.
Are you tagging with notmuch-deliver?
Yes, I am, is there best ways to filter incoming mails, as I'm using
notmuch on the same host as my MTA?
Thanks,
--
Guyzmo
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
