[notmuch] [PATCH] Better folder name search strategy.

2010-01-29 Thread Servilio Afre Puentes
This allows the use non-word characters (e.g.: "/") as the folder name
in the notmuch-folders variable.
---
 notmuch.el |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 97914f2..bdb0200 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1467,7 +1467,9 @@ Currently available key bindings:
   (save-excursion
 (beginning-of-line)
 (let ((beg (point)))
-  (forward-word)
+  (save-match-data
+   (re-search-forward "[ \t]" nil t))
+  (backward-char)
   (filter-buffer-substring beg (point)

 (defun notmuch-folder-show-search ( folder)
-- 
1.6.5


[notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code

2010-01-29 Thread Sebastian Spaeth
First, I think this FCC method is phantastic and it works like a
charm. I agree that we should include the snippets at least in some
"contrib" directory (or doc/examples) to make it easier to find.

Jameson Rollins  wrote:
> (defun my-message-header-setup ()
>   (message-add-header "Fcc: ~/.mail/sent"))
> (add-hook 'message-send-hook 'my-message-header-setup)

I tried to replace that snippet with:

(setq message-default-mail-headers "Fcc:  ~/.mail/sent\n")

because I like to see the Fcc header when composing, but this only works
for new messages (via ctrl-x m) and not when invoked with "r"(eply) on
an existing message in notmuch.

Is message-default-mail-headers only invoked for completely new mails?
The message mode manual doesn't state anything about that.

And I agree with JRollins patch to not add the BCC to myself from
notmuch.el by default. Either make it a notmuch option, or specify how to
set up a default BCC in emacs in the docs.

Sebastian


[notmuch] [PATCH 2/2] Preserve folder information when indexing

2010-01-29 Thread Michal Sojka
On Thursday 28 of January 2010 18:13:06 micah anderson wrote:
> On Thu, 28 Jan 2010 16:25:17 +0100, Michal Sojka  
wrote:
> > This patch was originally sent by Andreas Kl?ckner. This is a slightly
> > reworked version (only coding style changes) which was manually rebased
> > to the current HEAD.
> 
> Just a quick note about this patch: I received an offline email back
> From Andreas who said he is no longer going to improve the patch because
> he has stopped using notmuch. I hope that this doesn't mean that this is

I know. Andreas wrote it to the list as well. That was the reason why I tried 
to update the patch myself.

> dropped, it provides a pretty useful functionality for transitioning
> From a folder-based IMAP setup to notmuch! I wish I could volunteer to
> pick this up and finish it myself, but I cannot commit to doing this at
> the moment.

I have the same goal as you so I'll probably invest some time to this patch in 
order to be merged.

Michal


[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

2010-01-29 Thread martin f krafft
also sprach Ben Gamari  [2010.01.29.0949 +1300]:
> > I guess I just dislike having to run notmuch new regularly,
> > rather than integrating the database more closely with the mail
> > flow.
> > 
> Sounds like you need to add a line to crontab.

It still feels like a hack. It's a bit like making many changes to
a source code repository (new mails get delivered) and committing
only once every hour (notmuch new), rather than making and
committing transactional changes (delivering and catalogueing mails
individually).

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

a Hooloovoo is a superintelligent shade of the color blue.
-- douglas adams, "the hitchhiker's guide to the galaxy"

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100129/be7dc948/attachment.pgp>


[notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code

2010-01-29 Thread Jesse Rosenthal
On Fri, 29 Jan 2010 14:21:56 +0100, Sebastian Spaeth  
wrote:
> First, I think this FCC method is phantastic and it works like a
> charm. I agree that we should include the snippets at least in some
> "contrib" directory (or doc/examples) to make it easier to find.

I'm glad it's proved useful. However, I should say that I'd be wary of
distributing it, or even recommending it, without at least rudimentary
error checking -- even if it's just the delivery function returning
either 0 or -1, and the emacs wrapper reporting failure back to the user
in a sensible fashion. As it is now, a failed delivery will either go
silently by, or muck everything up in a not-so-useful way.

Returning some sort of success/fail would just take a couple of
try/except lines. I would have put that in myself, but I just whipped it
up for personal use (and then never used it).

Best,
Jesse


[notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code

2010-01-29 Thread Jameson Rollins
On Fri, 29 Jan 2010 14:21:56 +0100, "Sebastian Spaeth"  wrote:
> First, I think this FCC method is phantastic and it works like a
> charm. I agree that we should include the snippets at least in some
> "contrib" directory (or doc/examples) to make it easier to find.

I'm really glad this was useful.  Thanks of course to Jesse, who
initially figured all this out.

I'm pretty convinced that soon enough we'll have a new packages worth of
notmuch helper functions and scripts.

> Jameson Rollins  wrote:
> > (defun my-message-header-setup ()
> >   (message-add-header "Fcc: ~/.mail/sent"))
> > (add-hook 'message-send-hook 'my-message-header-setup)
> 
> I tried to replace that snippet with:
> 
> (setq message-default-mail-headers "Fcc:  ~/.mail/sent\n")
>
> because I like to see the Fcc header when composing, but this only works
> for new messages (via ctrl-x m) and not when invoked with "r"(eply) on
> an existing message in notmuch.
>
> Is message-default-mail-headers only invoked for completely new mails?
> The message mode manual doesn't state anything about that.

Yeah, I started out doing that as well, but I tried every permutation of
setup hooks I could think of and couldn't get consisten behavior when
doing replys or new messages.  I ended up just using the send-hook
because it was simple and consistent.

> And I agree with JRollins patch to not add the BCC to myself from
> notmuch.el by default. Either make it a notmuch option, or specify how to
> set up a default BCC in emacs in the docs.

I think this needs to just be done via a personal emacs config.  There's
really no need for the notmuch CLI to handle this, when it can easily
enough be handled by the reader UI.

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/20100129/09a2640a/attachment.pgp>


Re: [notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code

2010-01-29 Thread Sebastian Spaeth
First, I think this FCC method is phantastic and it works like a
charm. I agree that we should include the snippets at least in some
contrib directory (or doc/examples) to make it easier to find.

Jameson Rollins jroll...@finestructure.net wrote:
 (defun my-message-header-setup ()
   (message-add-header Fcc: ~/.mail/sent))
 (add-hook 'message-send-hook 'my-message-header-setup)

I tried to replace that snippet with:

(setq message-default-mail-headers Fcc:  ~/.mail/sent\n)

because I like to see the Fcc header when composing, but this only works
for new messages (via ctrl-x m) and not when invoked with r(eply) on
an existing message in notmuch.

Is message-default-mail-headers only invoked for completely new mails?
The message mode manual doesn't state anything about that.

And I agree with JRollins patch to not add the BCC to myself from
notmuch.el by default. Either make it a notmuch option, or specify how to
set up a default BCC in emacs in the docs.

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


Re: [notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code

2010-01-29 Thread Jesse Rosenthal
On Fri, 29 Jan 2010 14:21:56 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 First, I think this FCC method is phantastic and it works like a
 charm. I agree that we should include the snippets at least in some
 contrib directory (or doc/examples) to make it easier to find.

I'm glad it's proved useful. However, I should say that I'd be wary of
distributing it, or even recommending it, without at least rudimentary
error checking -- even if it's just the delivery function returning
either 0 or -1, and the emacs wrapper reporting failure back to the user
in a sensible fashion. As it is now, a failed delivery will either go
silently by, or muck everything up in a not-so-useful way.

Returning some sort of success/fail would just take a couple of
try/except lines. I would have put that in myself, but I just whipped it
up for personal use (and then never used it).

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


[notmuch] [PATCH] Better folder name search strategy.

2010-01-29 Thread Servilio Afre Puentes
This allows the use non-word characters (e.g.: /) as the folder name
in the notmuch-folders variable.
---
 notmuch.el |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 97914f2..bdb0200 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1467,7 +1467,9 @@ Currently available key bindings:
   (save-excursion
 (beginning-of-line)
 (let ((beg (point)))
-  (forward-word)
+  (save-match-data
+   (re-search-forward [ \t] nil t))
+  (backward-char)
   (filter-buffer-substring beg (point)

 (defun notmuch-folder-show-search (optional folder)
-- 
1.6.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[notmuch] Some thoughts about notmuch sync with other agents

2010-01-29 Thread Paul R


Hi,

before going into details, I'd like to tell you how much I like the
notmuch workflow, thank you for producing this nice piece of software !

Like most potential users, I can not really fully jump into notmuch
because of the current synchronisation issues with others MUA. One may
or may not like IMAP for good reasons, the fact is that it is here and
has allowed users to read mails from various places and terminals,
keeping important information synced. So I think that notmuch will have
to live with that, and provide what is required to integrate smoothly
into this environment. Redefining a new mail retrieval protocol and
a mail storing format are both really exciting projects, but they are
projects on their own that could only distract notmuch from its most
beautiful goal : giving *today* users the power to process mail in an
efficient way.

As you see, I advocate a NotMuch - IMAP synchronisation ASAP :)

At the moment, notmuch input are mail-as-file + user-defined tags.
OfflineIMAP allows to do the IMAP - mail-as-file transition, in both
directions, mail-as-file being namely MailDir. So we can simply aim at
a NotMuch - MailDir synchronisation, offlineimap will take care of
IMAP itself.

Of course, my proposal does not require to implement any MailDir
specific logic inside NotMuch, but rather describes how should notmuch
evolve to allow easy third-party-tool jobs.


Preliminary thoughts :
--

First of all, processing mail with MUA involves some simple logic that
is shared by most MUA. This is about receiving *new* mails, *reading*
mail, *replying* to mail and so on... IMHO, this really belongs to the
mail processing logic and not to the user logic. Hence my first
request :

  1: Don't use user tags space to store MUA flags.

 That means no more seen, unread, replied as tags. These are
 MUA processing *flags*, that must belong to an established set.
 Tags, on the other hand, are user-land information. So no more
 [seen, replied, grandma, important] tag sets :)

Once this is done, notmuch will know, in a robust a predictable way,
what happened to a mail. Simply put, NotMuch will store and expose MUA
flags (Passed, Replied, Seen, Trashed, Draft, and Flagged [1]). For each
flag, notmuch should associate a flag_synced flag. When changing
flag from notmuch, it should set the flag_synced bit to 0. These are
MUA mail flags.

Additionally, in a third « space », notmuch should store its « new »
bit, as well as a « missing » bit probably. Again, this is neither MUA
logic or user logic, so this should not interfer with user
classification facility provided by tags, nor with MUA flags. It,
really, is something else, let's name it status. Once this is done,
the 'notmuch new' command should find new mails and set the 'new' bit
for them, and find the missing mails and set the 'missing' bit for them.
This will allow for robust external processing.

Finally, notmuch should provide a switch to output a list of filenames
to stdout and to process a list of filenames from stdin.


NotMuch - MailDir synchronisation :
-

Provided the behaviour described above, notmuch - MailDir
synchronisation could be done fully externally, by a 'notmuch-maildir'
adapter.

Here is some pseudo code, that could be wrapped into a single
'notmuch-sync' command. The | are unix stream pipes, and everything
should be on a single line.

# 1/ Sync from NotMuch to MailDir

notmuch list flags:(seen and not seen_synced) 
  | notmuch-maildir --mark-mail seen
  | notmuch move --stdin
  | notmuch set flags:+seen_synced --stdin

The output of the first command would be a list of filenames for mails
'seen' since last sync. The second one, an external notmuch--maildir
helper, would propagate this logic to the MailDir store (easy, this is
simply a rename), and output the list of (old-name ! new-name). Then
notmuch would use this information, via a generic 'move' switch, to know
that mail has been moved, and would output the list of the new places.
Finaly, notmuch would set the seen_synced flag.

Same would apply for the Replied, Trashed, Flagged and Passed flags.

# 2/ Then lets do the MailDir - IMAP sync

 offlineimap

... done ! that was easy :)

# 3/ notmuch new

 notmuch new

At this point, notmuch should set the 'new' or the 'missing' status bit
to the mails. Let's forget how to deal with the missing bit, that should
be easy to do.

# 4/ Sync from MailDir to NotMuch

  notmuch list status:new 
   | notmuch-maildir --filter seen
   | notmuch set flags:+seen+seen_synced --stdin

First command outputs newly discovered mail. Second one reads stdin and
output only files that are already seen (again, this is as easy as
a filter based on a regular expression). Third one reads stdin and
applies the seen and seen_synced flags.

Same applies for the Replied, Trashed, Flagged and Passed flags.


Conclusion:
---

As we have seen, this would allow most IMAP -