notmuch-poll and OfflineIMAP

[Jani Nikula]

Jacek Generowicz  writes:

> Hello,
>
> Would you have any advice on how to construct a notmuch-poll script
> that would work well in concert with OfflineIMAP?  In particlular, how
> can you avoid having to re-issue the IMAP account passwords?
>
> The OfflineIMAP docs state that SIGUSR1 forces an immediate resync of
> all accounts, so something based around
>
> kill -SIGUSR1 `cat ~/.offlineimap/pid`
>
> or
>
> pkill -SIGUSR1 -u `whoami` offlineimap
>
> (with an already-running OfflineIMAP process in autorefresh mode)
> could work, but it's not clear to me how to discover when the resync
> is done, and sleeping for an arbitrary time before calling 'notmuch
> new' seems unsatisfactory.
>
> Any words of wisdom?

Offlineimap supports running hooks after syncing. Check if SIGUSR1 does
that too. Then you could run notmuch new in the post sync hook.

Also, notmuch new supports pre-new and post-new hooks. You could start
or SIGUSR1 offlineimap in the pre-new hook. See man notmuch-hooks for
details.


HTH,
Jani.

Passwordless multi-account SMTP

[Jacek Generowicz]

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-poll and OfflineIMAP

[Jacek Generowicz]

Hello,

Would you have any advice on how to construct a notmuch-poll script
that would work well in concert with OfflineIMAP?  In particlular, how
can you avoid having to re-issue the IMAP account passwords?

The OfflineIMAP docs state that SIGUSR1 forces an immediate resync of
all accounts, so something based around

kill -SIGUSR1 `cat ~/.offlineimap/pid`

or

pkill -SIGUSR1 -u `whoami` offlineimap

(with an already-running OfflineIMAP process in autorefresh mode)
could work, but it's not clear to me how to discover when the resync
is done, and sleeping for an arbitrary time before calling 'notmuch
new' seems unsatisfactory.

Any words of wisdom?

Thanks.

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

Message deletion wisdom

[Jameson Graef Rollins]

On Tue, Apr 03 2012, Jacek Generowicz  wrote:
> Looking through the archives of this list, I see that the topic of
> message deletion is, if not controversial, then at least non-trivial.
>
> + Requests for the provision of message deletion mechanisms have
>   appeared many times, and that various patches addressing the issue
>   have been submitted, and (IIUC) some of these are awaiting review
>   and might possibly make it into an official release in the future.
>
> + Having the 'deleted' tag cause messages to be deleted is,
>   apparently, fraught with peril of losing mail.

Hi, Jacek.  You are right on both of these points.  It has indeed been a
controversial topic.  However, I would say that we have reached a stasis
in terms of our response to this issue.  I'll try to summarize here.

I can say with a very high degree of certainly that notmuch will NEVER
gain the capability to actually delete mail files from disk itself.  It
is too risky for notmuch to be involved in that, and it's too easy to do
it outside of notmuch (e.g. "notmuch search --output=files tag:deleted |
xargs rm").  This has never really been up for discussion.

What *has* generated a lot of discussion is whether or not the emacs
interface should by default support key bindings that add a "deleted"
tag to messages, and how that tag should be handled.  I think we have
finally settled on notmuch NOT supporting such a key binding by default,
since it's easy enough for users to add the binding themselves if they
wish.

What we have added (or more accurately "are adding") though (thanks to
the work of Austin Clements and Mark Walters) is the ability to exclude
messages with a certain tag from search results.  This is like an
effective deletion, since messages can be completely omitted from search
results without having them actually be deleted from disk.  This is
obviously much safer, and a more generally useful functionality.  This
functionality is currently in beta, but will be full-featured in the
next release.

So in summary, if you would like to "delete" messages, you can:

 * add a key binding to emacs (or your favorite ui) to add a "deleted"
   tag to messages that you want to delete:

(define-key notmuch-show-mode-map "d"
  (lambda ()
(interactive)
(notmuch-show-tag-message "+deleted")))

 * add exclusion for messages with the "deleted" tag:

notmuch config set search.exclude_tags deleted

 * and if you really want them purged from disk, delete them manually
   with:

notmuch search --output=files tag:deleted | xargs -l rm

I'll add a page about this to the wiki, since it comes up enough.

hth.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120403/058920b8/attachment.pgp>

[PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag"

[Jameson Graef Rollins]

On Tue, Apr 03 2012, Jani Nikula  wrote:
> Yes, it's more flexible, but what are the real benefits of such
> flexibility? What other commands than tag/restore would truly benefit
> from this? I might add that nobody has asked for such flexibility.

But I do believe it was your patch that introduced the idea of batch
processing of other commands to begin with.  I think you're just turning
my original question to you back on me.  There's no point in adding and
initial flag to the beginning of the line to specify the command to
execute if you have no intention of ever supporting other commands.  Or
vice versa, if you ultimately want to support multiple commands then the
place to do it is in the top level interface, and not in one of the
subcommands.

Ultimately, I think this patch series suffers from being simultaneously
too close to existing functionality (restore), yet tantalizingly close
to a much more generally useful concept of batch command processing.  I
would rather see it go one way or the other rather than add something
fairly redundant in the middle.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120403/6099856e/attachment.pgp>

notmuch-poll and OfflineIMAP

[Adam Wolfe Gordon]

Hi Jacek,

On Tue, Apr 3, 2012 at 09:27, Jacek Generowicz  
wrote:
> Would you have any advice on how to construct a notmuch-poll script
> that would work well in concert with OfflineIMAP? ?In particlular, how
> can you avoid having to re-issue the IMAP account passwords?
>
> The OfflineIMAP docs state that SIGUSR1 forces an immediate resync of
> all accounts, so something based around
>
> ? ?kill -SIGUSR1 `cat ~/.offlineimap/pid`
>
> or
>
> ? ?pkill -SIGUSR1 -u `whoami` offlineimap
>
> (with an already-running OfflineIMAP process in autorefresh mode)
> could work, but it's not clear to me how to discover when the resync
> is done, and sleeping for an arbitrary time before calling 'notmuch
> new' seems unsatisfactory.
>
> Any words of wisdom?

I run offlineimap in autorefresh mode (with IDLE too, actually) and
use a script based on inotify to update notmuch whenever new mail
comes in: https://gist.github.com/1952483 . It sounds like some
variant of this would probably work for you.

As an added bonus, I have my post-new script run emacsclient -n -e
'(notmuch-hello-update t)', so if I flip to my mail desktop I can see
right away if there's new mail.

Handling of symlinked maildirs?

[Mark Anderson]

On Mon, 2 Apr 2012 10:54:48 -0700, Jameson Graef Rollins  wrote:
> On Mon, Apr 02 2012, Andrei POPESCU  wrote:
> > Im sorting my mailing lists with generic maildrop rules like this one:
> >
> > if (/^List-Id:.*/)
> > to Maildir/.debian.$MATCH1/
> >
> > However, I'm subscribed to a *lot* of mailing lists and in order to keep 
> > my folder view sane I use symlinks to conflate some of them, e.g. 
> >
> > .debian.devel-announce -> .debian.devel
> >
> > This works well since mutt simply ignores the symlink(s) so I don't even 
> > need to exclude them in the config, but it seems that notmuch does index 
> > each of the symlinks as a separate folder[1].
> >
> > Does it make sense to have this configurable or even completely exclude 
> > the symlinks?
> 
> Hey, Andrei.  I would say that if you have a compelling reason that
> notmuch should be able to ignore symlinked directories then it maybe
> makes sense to have it configurable.  However, I must say that I have
> completely dropped the whole folder concept myself since I find it
> totally redundant with notmuch's tagging and searching capabilities.

Please don't exclude the indexing of symlinks in notmuch.  I have a
fairly restricted IT environment at work, where I have chosen to symlink
all my maildirs to other disks so that they appear in my home directory
but do not fill my home disk quota every day.  Often my different
maildirs are to make my non-notmuch mail viewing slightly tolerable.

There was a configuration option (new.ignore) added to 0.12 that lets
one specify names of things not to index. That may be enough to do what
you want, although not as automatic as just pitching all symlinks while
indexing.

Thanks,

-Mark

Message deletion wisdom

[Jacek Generowicz]

Hello,

Looking through the archives of this list, I see that the topic of
message deletion is, if not controversial, then at least non-trivial.

+ Requests for the provision of message deletion mechanisms have
  appeared many times, and that various patches addressing the issue
  have been submitted, and (IIUC) some of these are awaiting review
  and might possibly make it into an official release in the future.

+ Having the 'deleted' tag cause messages to be deleted is,
  apparently, fraught with peril of losing mail.


I have two questions:


1) Could you give me a summary of the dangers of allowing notmuch to
   actually delete mail?

2) How do you deal with mail that you would like to disappear from
   your maildirs/IMAP servers? (An Emacs-based slant would be
   particularle welcome.)


Thank you for your input.

Passwordless multi-account SMTP

[James Vasile]

On Tue, 3 Apr 2012 17:29:07 +0200, Jacek Generowicz  wrote:
> 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.


I use a slightly modified msmtpq for queuing and I have some hooks that
run profiles to choose SMTP server and other options based on
sender/receiver/last search.  Passwords are plain text but my fs is
encrypted.  If you want, you could encrypt the password file with gpg
and use gpg-agent to grab the password as needed from the file.

Good luck.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120403/cbebe91b/attachment.pgp>

[PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag"

[Jani Nikula]

On Mon, 02 Apr 2012 14:43:16 -0700, Jameson Graef Rollins  wrote:
> So what if we instead modified the top level binary ("notmuch") to:
> 
> * add an option to specify that commands are to be processed from stdin
>   (--batch)
> 
> * when in batch mode the db is opened once at the beginning and locked
> 
> * commands are processed from stdin in the exact same form they are
>   specified on the command line ("tag +foo -- from:bar", "search
>   tag:foo", etc.).
> 
> * db is closed when EOF is reached.
> 
> That seems like it would be a generally much cleaner interface, and much
> more flexible.

Yes, it's more flexible, but what are the real benefits of such
flexibility? What other commands than tag/restore would truly benefit
from this? I might add that nobody has asked for such flexibility.

As to the cleanliness of the interface, all is well as long as no
characters needing escaping are used. With them, things get hairy. On
the command line, the shell provides the necessary escaping and quoting
mechanisms, and parsing to subcommand argv. I think it would be
confusing to require %NN style hex escaping on the command line where
shell mechanisms can be used, but also it would be a lot of work to
duplicate the shell escaping and quoting mechanisms to the stdin
parsing. For simplicity, I'd use hex escaping for stdin, and leave the
command line to the shell.

Finally, I'm not sure how the config and database open/close could be
cleanly duplicated in top level "notmuch" and the subcommands. Should
there be logic in the subcommands not to open the config/database if
they're already opened in top level? All of notmuch cli should also be
reworked to pass the config and database on to the subcommands. Not all
the commands need to open the database in read/write mode, and some
commands don't need to open the database at all, so it would not make
sense to move config/database open/close to top level completely.

In summary, I don't see enough value in this to put all the work
required into it. I think it's way more trouble than it's worth.


BR,
Jani.

[PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag"

[Jani Nikula]

On Apr 3, 2012 12:20 AM, "Jameson Graef Rollins" 
wrote:
>
> On Mon, Apr 02 2012, Jani Nikula  wrote:
> > Batch tagging brings performance and atomicity by opening and closing
the
> > db only once. The hex encoding handles insane message ids and tags.
> > Otherwise there should be no difference.
>
> I can maybe see performance in terms of opening and closing the db only
> once, but atomicity?  Not sure I see how that is improved.

Err, I meant locking, sorry. Nobody else is able to alter the db while
batch tagging is in progress.

>
> And shouldn't we be able to improve the handling of command line
> arguments so that we get the same encoding handling on the command line
> as we would from stdin?
>
> jamie.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120403/1e0695bf/attachment.html>

[PATCH 6/8] cli: add support for batch tagging operations to "notmuch tag"

[Jani Nikula]

On Apr 2, 2012 11:42 PM, "Jameson Graef Rollins" 
wrote:
>
> On Mon, Apr 02 2012, David Bremner  wrote:
> > Jameson Graef Rollins  writes:
> >> On Sat, Mar 31 2012, Jani Nikula  wrote:
> >>> Add support for batch tagging operations through stdin to "notmuch
> >>> tag". This can be enabled with the new --stdin command line option to
> >>> "notmuch new". The input must consist of lines of the format:
> >>>
> >>> T +|- [...] [--] 
> >>
> >
> > I think that's my fault. I was imagining a possible future line-oriented
> > notmuch server and having various actions/queries possible. It seems a
> > bit blue sky at this point, but it does give extesibility fairly
> > cheaply.
>
> But then why not just make the command explicit, and just have the first
> field be "tag"?
>
> But then I wonder why do we even need any of this at all?  Isn't it this
> just exactly equivalent to:
>
> xargs -l notmuch 
> ??

Batch tagging brings performance and atomicity by opening and closing the
db only once. The hex encoding handles insane message ids and tags.
Otherwise there should be no difference.

Jani.

>
> jamie.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120403/fb4fcd4d/attachment.html>

Re: [PATCH 6/8] cli: add support for batch tagging operations to notmuch tag

[Jani Nikula]

On Mon, 02 Apr 2012 14:43:16 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 So what if we instead modified the top level binary (notmuch) to:
 
 * add an option to specify that commands are to be processed from stdin
   (--batch)
 
 * when in batch mode the db is opened once at the beginning and locked
 
 * commands are processed from stdin in the exact same form they are
   specified on the command line (tag +foo -- from:bar, search
   tag:foo, etc.).
 
 * db is closed when EOF is reached.
 
 That seems like it would be a generally much cleaner interface, and much
 more flexible.

Yes, it's more flexible, but what are the real benefits of such
flexibility? What other commands than tag/restore would truly benefit
from this? I might add that nobody has asked for such flexibility.

As to the cleanliness of the interface, all is well as long as no
characters needing escaping are used. With them, things get hairy. On
the command line, the shell provides the necessary escaping and quoting
mechanisms, and parsing to subcommand argv. I think it would be
confusing to require %NN style hex escaping on the command line where
shell mechanisms can be used, but also it would be a lot of work to
duplicate the shell escaping and quoting mechanisms to the stdin
parsing. For simplicity, I'd use hex escaping for stdin, and leave the
command line to the shell.

Finally, I'm not sure how the config and database open/close could be
cleanly duplicated in top level notmuch and the subcommands. Should
there be logic in the subcommands not to open the config/database if
they're already opened in top level? All of notmuch cli should also be
reworked to pass the config and database on to the subcommands. Not all
the commands need to open the database in read/write mode, and some
commands don't need to open the database at all, so it would not make
sense to move config/database open/close to top level completely.

In summary, I don't see enough value in this to put all the work
required into it. I think it's way more trouble than it's worth.


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

Message deletion wisdom

[Jacek Generowicz]

Hello,

Looking through the archives of this list, I see that the topic of
message deletion is, if not controversial, then at least non-trivial.

+ Requests for the provision of message deletion mechanisms have
  appeared many times, and that various patches addressing the issue
  have been submitted, and (IIUC) some of these are awaiting review
  and might possibly make it into an official release in the future.

+ Having the 'deleted' tag cause messages to be deleted is,
  apparently, fraught with peril of losing mail.


I have two questions:


1) Could you give me a summary of the dangers of allowing notmuch to
   actually delete mail?

2) How do you deal with mail that you would like to disappear from
   your maildirs/IMAP servers? (An Emacs-based slant would be
   particularle welcome.)


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

notmuch-poll and OfflineIMAP

[Jacek Generowicz]

Hello,

Would you have any advice on how to construct a notmuch-poll script
that would work well in concert with OfflineIMAP?  In particlular, how
can you avoid having to re-issue the IMAP account passwords?

The OfflineIMAP docs state that SIGUSR1 forces an immediate resync of
all accounts, so something based around

kill -SIGUSR1 `cat ~/.offlineimap/pid`

or

pkill -SIGUSR1 -u `whoami` offlineimap

(with an already-running OfflineIMAP process in autorefresh mode)
could work, but it's not clear to me how to discover when the resync
is done, and sleeping for an arbitrary time before calling 'notmuch
new' seems unsatisfactory.

Any words of wisdom?

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

Passwordless multi-account SMTP

[Jacek Generowicz]

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

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

Re: Passwordless multi-account SMTP

[James Vasile]

On Tue, 3 Apr 2012 17:29:07 +0200, Jacek Generowicz jacek.generow...@cern.ch 
wrote:
 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.


I use a slightly modified msmtpq for queuing and I have some hooks that
run profiles to choose SMTP server and other options based on
sender/receiver/last search.  Passwords are plain text but my fs is
encrypted.  If you want, you could encrypt the password file with gpg
and use gpg-agent to grab the password as needed from the file.

Good luck.


pgph4o5PyLp8d.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch-poll and OfflineIMAP

[Jani Nikula]

Jacek Generowicz jacek.generow...@cern.ch writes:

 Hello,

 Would you have any advice on how to construct a notmuch-poll script
 that would work well in concert with OfflineIMAP?  In particlular, how
 can you avoid having to re-issue the IMAP account passwords?

 The OfflineIMAP docs state that SIGUSR1 forces an immediate resync of
 all accounts, so something based around

 kill -SIGUSR1 `cat ~/.offlineimap/pid`

 or

 pkill -SIGUSR1 -u `whoami` offlineimap

 (with an already-running OfflineIMAP process in autorefresh mode)
 could work, but it's not clear to me how to discover when the resync
 is done, and sleeping for an arbitrary time before calling 'notmuch
 new' seems unsatisfactory.

 Any words of wisdom?

Offlineimap supports running hooks after syncing. Check if SIGUSR1 does
that too. Then you could run notmuch new in the post sync hook.

Also, notmuch new supports pre-new and post-new hooks. You could start
or SIGUSR1 offlineimap in the pre-new hook. See man notmuch-hooks for
details.


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

Re: Handling of symlinked maildirs?

[Mark Anderson]

On Mon, 2 Apr 2012 10:54:48 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Mon, Apr 02 2012, Andrei POPESCU andreimpope...@gmail.com wrote:
  Im sorting my mailing lists with generic maildrop rules like this one:
 
  if (/^List-Id:.*debian-(.*)\.lists.debian.org/)
  to Maildir/.debian.$MATCH1/
 
  However, I'm subscribed to a *lot* of mailing lists and in order to keep 
  my folder view sane I use symlinks to conflate some of them, e.g. 
 
  .debian.devel-announce - .debian.devel
 
  This works well since mutt simply ignores the symlink(s) so I don't even 
  need to exclude them in the config, but it seems that notmuch does index 
  each of the symlinks as a separate folder[1].
 
  Does it make sense to have this configurable or even completely exclude 
  the symlinks?
 
 Hey, Andrei.  I would say that if you have a compelling reason that
 notmuch should be able to ignore symlinked directories then it maybe
 makes sense to have it configurable.  However, I must say that I have
 completely dropped the whole folder concept myself since I find it
 totally redundant with notmuch's tagging and searching capabilities.

Please don't exclude the indexing of symlinks in notmuch.  I have a
fairly restricted IT environment at work, where I have chosen to symlink
all my maildirs to other disks so that they appear in my home directory
but do not fill my home disk quota every day.  Often my different
maildirs are to make my non-notmuch mail viewing slightly tolerable.

There was a configuration option (new.ignore) added to 0.12 that lets
one specify names of things not to index. That may be enough to do what
you want, although not as automatic as just pitching all symlinks while
indexing.

Thanks,

-Mark

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

Re: notmuch-poll and OfflineIMAP

[Adam Wolfe Gordon]

Hi Jacek,

On Tue, Apr 3, 2012 at 09:27, Jacek Generowicz jacek.generow...@cern.ch wrote:
 Would you have any advice on how to construct a notmuch-poll script
 that would work well in concert with OfflineIMAP?  In particlular, how
 can you avoid having to re-issue the IMAP account passwords?

 The OfflineIMAP docs state that SIGUSR1 forces an immediate resync of
 all accounts, so something based around

    kill -SIGUSR1 `cat ~/.offlineimap/pid`

 or

    pkill -SIGUSR1 -u `whoami` offlineimap

 (with an already-running OfflineIMAP process in autorefresh mode)
 could work, but it's not clear to me how to discover when the resync
 is done, and sleeping for an arbitrary time before calling 'notmuch
 new' seems unsatisfactory.

 Any words of wisdom?

I run offlineimap in autorefresh mode (with IDLE too, actually) and
use a script based on inotify to update notmuch whenever new mail
comes in: https://gist.github.com/1952483 . It sounds like some
variant of this would probably work for you.

As an added bonus, I have my post-new script run emacsclient -n -e
'(notmuch-hello-update t)', so if I flip to my mail desktop I can see
right away if there's new mail.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 6/8] cli: add support for batch tagging operations to notmuch tag

[Jameson Graef Rollins]

On Tue, Apr 03 2012, Jani Nikula j...@nikula.org wrote:
 Yes, it's more flexible, but what are the real benefits of such
 flexibility? What other commands than tag/restore would truly benefit
 from this? I might add that nobody has asked for such flexibility.

But I do believe it was your patch that introduced the idea of batch
processing of other commands to begin with.  I think you're just turning
my original question to you back on me.  There's no point in adding and
initial flag to the beginning of the line to specify the command to
execute if you have no intention of ever supporting other commands.  Or
vice versa, if you ultimately want to support multiple commands then the
place to do it is in the top level interface, and not in one of the
subcommands.

Ultimately, I think this patch series suffers from being simultaneously
too close to existing functionality (restore), yet tantalizingly close
to a much more generally useful concept of batch command processing.  I
would rather see it go one way or the other rather than add something
fairly redundant in the middle.

jamie.


pgpwiucwk4x3v.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Message deletion wisdom

[Jameson Graef Rollins]

On Tue, Apr 03 2012, Jacek Generowicz jacek.generow...@cern.ch wrote:
 Looking through the archives of this list, I see that the topic of
 message deletion is, if not controversial, then at least non-trivial.

 + Requests for the provision of message deletion mechanisms have
   appeared many times, and that various patches addressing the issue
   have been submitted, and (IIUC) some of these are awaiting review
   and might possibly make it into an official release in the future.

 + Having the 'deleted' tag cause messages to be deleted is,
   apparently, fraught with peril of losing mail.

Hi, Jacek.  You are right on both of these points.  It has indeed been a
controversial topic.  However, I would say that we have reached a stasis
in terms of our response to this issue.  I'll try to summarize here.

I can say with a very high degree of certainly that notmuch will NEVER
gain the capability to actually delete mail files from disk itself.  It
is too risky for notmuch to be involved in that, and it's too easy to do
it outside of notmuch (e.g. notmuch search --output=files tag:deleted |
xargs rm).  This has never really been up for discussion.

What *has* generated a lot of discussion is whether or not the emacs
interface should by default support key bindings that add a deleted
tag to messages, and how that tag should be handled.  I think we have
finally settled on notmuch NOT supporting such a key binding by default,
since it's easy enough for users to add the binding themselves if they
wish.

What we have added (or more accurately are adding) though (thanks to
the work of Austin Clements and Mark Walters) is the ability to exclude
messages with a certain tag from search results.  This is like an
effective deletion, since messages can be completely omitted from search
results without having them actually be deleted from disk.  This is
obviously much safer, and a more generally useful functionality.  This
functionality is currently in beta, but will be full-featured in the
next release.

So in summary, if you would like to delete messages, you can:

 * add a key binding to emacs (or your favorite ui) to add a deleted
   tag to messages that you want to delete:

(define-key notmuch-show-mode-map d
  (lambda ()
(interactive)
(notmuch-show-tag-message +deleted)))

 * add exclusion for messages with the deleted tag:

notmuch config set search.exclude_tags deleted

 * and if you really want them purged from disk, delete them manually
   with:

notmuch search --output=files tag:deleted | xargs -l rm

I'll add a page about this to the wiki, since it comes up enough.

hth.

jamie.


pgp0FHgBRTDz9.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 6/8] cli: add support for batch tagging operations to notmuch tag

[David Bremner]

Jameson Graef Rollins jroll...@finestructure.net writes:

 There's no point in adding and initial flag to the beginning of the
 line to specify the command to execute if you have no intention of
 ever supporting other commands. 

My thinking was that it was useful for the disk format to have a bit
more information in it so that we could more easily change the interface
in an upwardly compatible way. If at some point in the future we do have
more general batch command processing, it would be nice not have to
change the file format again, particularly for dump files.

 Ultimately, I think this patch series suffers from being
 simultaneously too close to existing functionality (restore),

Well, as Jani mentioned there is a fair amount of code overlap with an
in-progress improved dump/restore facility.

 yet tantalizingly close to a much more generally useful concept of
 batch command processing.

Well, opinions seem to differ about how close we are to that in terms of
real code, but I think it is worth thinking about as we define file
formats.

d

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