[notmuch] [PATCH] notmuch-new: Eliminate tallocs whilst construct filenames.

2009-11-27 Thread Jeffrey Ollie
On Fri, Nov 27, 2009 at 11:41 PM, Carl Worth  wrote:
>
> But yes, we need a test suite.

I have zero experience, but Check[1] looks interesting.

> Oh, and we'll also need to deal with remaining glib usage inside of
> notmuch, (and inside of GMime as well), before we can do good testing
> for memory-fault injection. Maybe what we'll end up with is a patch to
> de-glib-ify GMime? I'm not sure.

Rather than de-glib-ify'ing GMime wouldn't it be better to find a non
glib-based library for MIME processing?  I do most of my development
in Python these days so I don't know of any examples.  My googling
turned up several C++ libraries or c-client and I wouldn't want to go
down either of those paths.

[1] http://check.sourceforge.net/

-- 
Jeff Ollie


[notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Jeffrey Ollie
On Fri, Nov 27, 2009 at 9:59 PM, Ingmar Vanhassel  wrote:
>
> Most distributions have a rather strict policy to use system libraries
> over internal copies.

Fedora:

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Debian:

http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

If there are other distributions out there that have similar policies
I'd be interested in learning about them.

-- 
Jeff Ollie


[notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Jeffrey Ollie
On Fri, Nov 27, 2009 at 9:31 PM, Mikhail Gusarov
 wrote:
> Twas brillig at 21:28:03 27.11.2009 UTC-06 when jeff at ocjtech.us did gyre 
> and gimble:
>
> ?JCO> Instead of including a private implementation of the SHA1 hash
>
> xserver went this road, and now it has
> --with-sha1=libc|libmd|libgcrypt|libcrypto|libsha1|CommonCrypto in
> configure.

I doubt that we'll get to that level of insanity.

> ?JCO> This means less code of our own to maintain and
>
> As libsha1 maintainer I'm volunteering to maintain in-tree copy in
> notmuch :)

That's great that you're willing to take on the task, but as I do a
lot of work for Fedora I tend to think about these things differently.
 It's not about a project here or there making private copies of some
code, it's about tracking down *all* of the projects that have private
copies of the code when something goes wrong, especially when there
are security implications.

The most famous example is Zlib.  Based upon what Google turned up I
see that you've been around long enough that you should have heard of
the problems the computer world had when security flaws turned up in
Zlib.  There's even a project[1] that developed methods for
identifying vulnerable code in binaries the problem was so pervasive.

A more recent example is a cross-site ajax request vulnerability in
the Prototype JavaScript framework[2].  A lot of projects copied that
code into their repositories as well, and now someone has to track all
of those down and get them fixed as well.

When projects copy code into their repositories like this, it makes
things a lot more difficult for someone else down the road.  Both
Fedora[3] and Debian[4] (and Ubuntu by extension), while not expressly
forbidding the practice, *strongly* recommend against it.  I'd really
recommend reading the Fedora page that explains the policy as it has a
great summation of the problem.

[1] http://www.enyo.de/fw/security/zlib-fingerprint/
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7220
[3] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
[4] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

-- 
Jeff Ollie


[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer

2009-11-27 Thread Tassilo Horn
Carl Worth  writes:

Hi Carl,

> On Tue, 24 Nov 2009 09:02:46 +0100, Tassilo Horn  
> wrote:
>> I'm a Gnus user and use notmuch mostly for searching.  When I want to
>> reply to a message, I need to get back to Gnus, so that my Gnus
>> posting styles (gcc into that group, right email address, correct
>> signature,...)  are applied.
>
> Oh, good. I've been hoping to be able to get some advice from gnus
> users. I want to figure out how to get gnus support for viewing
> encrypted messages, etc.

Oh, I don't have any clue about encryption.  EasyPG is a keyword, that I
can provide, though.

> Do you happen to know some good documentation for how to get started
> with gnus for reading mail? I'd be happy even with the bare minimum to
> just get gnus to view one single message from out of my mail
> store. (Which is something I tried to figure out from the gnus manual,
> but I never succeeded at.)

Well, if you only want to have a look at a maildir or mbox, and don't
want to make the group permanent and let gnus fetch mail, then this
should do the trick.

  M-x gnus RET ;; brings you into the *Group* buffer, and then

,[ (info "(gnus)Foreign Groups") ]
| `G m'
|  Make a new group (`gnus-group-make-group').  Gnus will prompt you
|  for a name, a method and possibly an "address".  For an easier way
|  to subscribe to NNTP groups (*note Browse Foreign Server::).
`

>> Therefore, I created this small snippet.  Now C-c C-c inside some
>> message in the *notmuch-show* buffer opens this article in a Gnus
>> *Summary* buffer, where I can reply to it, forward it, ...
>
> And this would be exactly the thing I would want for exploring gnus,
> if only I could get it working.

This does only work if the group already exists inside Gnus.  So you
might consider setting it up properly, although it's a bit first-time
effort.

> If I just try to run it, I get:
>
>   Symbol's function definition is void: org-gnus-follow-link

Do you use Emacs 23?  If yes, put a (require 'org-gnus) before the
call.  If not, you have to install org-mode manually.

> And I suppose that's expected since I don't have gnus "running". If I
> try to start gnus with "M-x gnus", I get:
>
>   Unable to open server nntp+news, go offline? (y or n) 

Hm, I can reproduce that with "emacs -Q".  Looks wrong to me, probably a
bug...  Normally, an unconfigured Gnus should start having one nndoc
server providing some groups with static Gnus infos (FAQ and stuff).

> What's the simplest way for me to tell gnus that I won't be using it
> in any other way than with the "nnimap+" folder I can tell you're
> using in your snippet?

Here's a quick walkthrough my .gnus.el with only the basics (getting
mail/news).

--8<---cut here---start->8---
;; Gnus has the concept of one select method, and a list of so-called
;; secondary select methods.  I set the former to a do-nothing backend
;; and only use the secondary ones, so that it's a bit more uniformly.

(setq gnus-select-method '(nnnil))

;; Fetch news from my university's nntp server
(add-to-list 'gnus-secondary-select-methods
 '(nntp "Uni"
(nntp-address "news.uni-koblenz.de")
(nntp-open-connection-function nntp-open-tls-stream)
(nntp-port-number 563)))

;; Fetch mail from some POP3 accounts and split them according to
;; address

;; The mails are stored in an nnml group at the given directory
(add-to-list 'gnus-secondary-select-methods
 '(nnml "Popmail"
(nnml-directory   "~/Mail/Popmail")
(nnml-active-file "~/Mail/Popmail/active")))

;; Here the mails are fetched
(setq mail-sources `((pop :server "pop.gmx.de"
  :user "x at gmx.de"
  :password ,th-gnus-gmx-password)
 (pop :server "pop3.freenet.de"
  :user "x at freenet.de"
  :password ,th-gnus-freenet-password)))

;; Split them into the groups nnml+Popmail:gmx, freenet, and misc
(setq nnmail-split-methods 'nnmail-split-fancy
  nnmail-split-fancy
  '(| (any "x at gmx.de" "gmx")
  (any "x at freenet.de" "freenet")
  "misc"))

;; Get mail from my local Dovecot IMAP server which I sync with my
;; different accounts using OfflineIMAP
(add-to-list 'gnus-secondary-select-methods
 '(nnimap "Fastmail"
  (nnimap-address "localhost")
  (nnimap-stream network)
  (nnimap-authenticator login)))

(add-to-list 'gnus-secondary-select-methods
 '(nnimap "Uni"
  (nnimap-address "localhost")
  (nnimap-stream network)
  (nnimap-authenticator login)))
--8<---cut here---end--->8---

HTH,
Tassilo


[notmuch] [PATCH] Add tests to configure script to detect strndup and getline

2009-11-27 Thread Marten Veldthuis
On Mon, Nov 23, 2009 at 12:14:15PM -0600, Jeffrey C. Ollie wrote:
> cat > Makefile.config < prefix = /usr/local
> bash_completion_dir = /etc/bash_completion.d
>-CFLAGS += ${have_valgrind}
>+CFLAGS += ${have_valgrind} ${strndup} ${getline}
> EOF

This doesn't seem to do much for me, they don't seem to end up in the args 
passed to g++. I'm no Makefile wizard, so I got notmuch finally compiling by 
simply copy/pasting the ${strndup} and ${getline} from Makefile.config to 
Makefile:

# Now smash together user's values with our extra values
override CFLAGS += $(WARN_FLAGS) $(extra_cflags) -Dstrndup=_notmuch_strndup 
-Dgetline=_notmuch_getline
override CXXFLAGS += $(WARN_FLAGS) $(extra_cflags) $(extra_cxxflags) 
-Dstrndup=_notmuch_strndup -Dgetline=_notmuch_getline

-- 
- Marten


[notmuch] [PATCH -v6] notmuch.el: Add face support to search mode

2009-11-27 Thread Carl Worth
On Sat, 28 Nov 2009 11:37:05 +0530, "Aneesh Kumar K.V"  wrote:
> This patch use notmuch-tag-face showing tags in the
> notmuch-search-mode.

Thanks, Aneesh! Your patience has prevailed again and I've pushed out
this patch.

> We can selectively highlight each tag by setting notmuch-tag-face-alist as 
> below
> 
> (defface notmuch-tag-unread-face
>  'class color)) (:foreground "goldenrod")))
>   "Notmuch search mode face used to highligh tags.")
> 
> (defface notmuch-tag-inbox-face
>  'class color)) (:foreground "red")))
>   "Notmuch search mode face used to highligh tags.")
> 
> (setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
>  ("inbox" . 'notmuch-tag-inbox-face)))

I'm a bit concerned that this documentation is going to just disappear
in the commit log and not be where people might actually look for
it. You've got the beginnings of the documentation here:

> +(defvar notmuch-tag-face-alist nil
> +  "List containing the tag list that need to be highlighed")

Which could be expanded to include basically the example above.

Anyway, thanks for the patch.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/427b9084/attachment.pgp>


[notmuch] Problems importing my mail...

2009-11-27 Thread Carl Worth
On Sat, 28 Nov 2009 00:37:07 -0600, Jeffrey Ollie  wrote:
> On Sat, Nov 28, 2009 at 12:09 AM, Carl Worth  wrote:
> >> Warning: Unexpected extra parts of multipart/signed. Indexing anyway.
> >
> > Oh, that's a warning I put in place because I wasn't sure if it was
> > legitimate for a multipart/signed message to have more than two
> > parts. I'd actually be interested to know if the mail is correct, (and I
> > should just eliminate the warning), or if the mail is somehow malformed
> > and the warning is correct.
> 
> No, I think it's legitimate to have multiple parts inside of a
> multipart/signed (just very rare).

OK. Then it sounds like the warning flagged an actual bug.

What the code is trying to do is simply to avoid indexing the signature
part. It's currently doing this by skipping the second part of a
multipart/signed message. Perhaps instead it should just be skipping the
final part? (It appears that that would be correct given the example
message.)

> Yes, all of those appear to not be complete mail messages, why they
> are in one of my IMAP servers remains to be seen.

OK. I'll let you puzzle that piece out.

> Unfortunately I deleted the database and am in the process of
> recreating it with the verbose flag turned on.  So far the problem has
> not occurred again.  So if there's a real bug somewhere I'm wondering
> if there isn't a timing-related component to it.

Alright. Well, let us know if things go wrong again.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/d9cec710/attachment.pgp>


[notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Carl Worth
On Sat, 28 Nov 2009 09:31:15 +0600, Mikhail Gusarov  wrote:
>  JCO> This means less code of our own to maintain and
> 
> As libsha1 maintainer I'm volunteering to maintain in-tree copy in
> notmuch :)

And Mikhail,

I wanted to thank you publicly for your maintenance work of libsha1. It
was a pleasant surprise to see you on the notmuch list and contributing
patches after I had independently found and incorporated libsha1
previously.

-Carl

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/6e45f2a9/attachment.pgp>


[notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 21:28:03 -0600, "Jeffrey C. Ollie"  
wrote:
> Instead of including a private implementation of the SHA1 hash, use
> libgcrypt.  This means less code of our own to maintain and it will be
> easier to switch to a different hash function like SHA256.

I don't believe we have a significant code-maintenance burden with
libsha1.c. And as for different hash functions, the only use of sha-1 in
notmuch is as a fallback in the case of a message not including a
Message-ID header.

So I don't see it as important at all to try to remove this code.

> libgcrypt was chosen because it has a fairly simple API, it's well
> tested (it's used in gnutls and gnupg2), and it's licensed under the
> LGPL.

What might make more sense is an option to compile against an existing
library (if present) but not to introduce an error in the build if the
library is not present, (in which case just build the builtin libsha1.c
code).

But if that wouldn't solve the problem you were trying to solve, (to
actually remove libsha1.c), then maybe we don't need to do anything for
now?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/b002ab9f/attachment.pgp>


[notmuch] [PATCH RFC] debugger: detect presence of ptrace type debuggers

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 22:11:04 -0500, Bart Trojanowski  wrote:
> According to the internet [1], this is a more reliable way of detecting if
> one is under the spell of a debugger.  Should work for ptrace, strace,
> gdb, etc.  Basically anything that uses the ptrace() syscall.

Doesn't avoid having side effects in the non-debugger case:

$ ./notmuch new
No new mail---and that's not much.

[1]+  Stopped ./notmuch new
$

Not pushed.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/68b5e759/attachment.pgp>


[notmuch] semi-usable notmuch-gtk client

2009-11-27 Thread Bart Trojanowski
* Baruch Even  [091127 12:58]:
> I added a quick hack to show a message thread in notmuch-gtk and this  
> makes it semi-usable. I don't actually parse the reply of notmuch-show  
> but it's already passably usable to read mail.

got screenshots?

Cheers,
-Bart

-- 
WebSig: http://www.jukie.net/~bart/sig/


[notmuch] [PATCH RFC] debugger: detect presence of ptrace type debuggers

2009-11-27 Thread Bart Trojanowski
According to the internet [1], this is a more reliable way of detecting if
one is under the spell of a debugger.  Should work for ptrace, strace,
gdb, etc.  Basically anything that uses the ptrace() syscall.

[1] http://vx.netlux.org/lib/vsc04.html
---
 debugger.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/debugger.c b/debugger.c
index e8b9378..f486032 100644
--- a/debugger.c
+++ b/debugger.c
@@ -22,6 +22,8 @@

 #include 

+#include 
+
 #if HAVE_VALGRIND
 #include 
 #else
@@ -36,6 +38,9 @@ debugger_is_active (void)
 if (RUNNING_ON_VALGRIND)
return TRUE;

+if (ptrace(PTRACE_TRACEME, 0, 1, 0) < 0)
+   return TRUE;
+
 sprintf (buf, "/proc/%d/exe", getppid ());
 if (readlink (buf, buf, sizeof (buf)) != -1 &&
strncmp (basename (buf), "gdb", 3) == 0)
-- 
1.6.4.4.2.gc2f148



[notmuch] Problems importing my mail...

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 19:09:56 -0600, Jeffrey Ollie  wrote:
> I'm having some problems importing my mail.  I've got quite a bit
> stored up, and some of them I'm sure are quite large.  After several
> hours I get the following.  Is notmuch running out of memory on me?

Comments below (as far as I can make them):

> $ ./notmuch new
> Found 328184 total files.

That's certainly not the largest number of messages we've seen indexed
successfully by notmuch, (I think Keith has near 3 times that
number). [Maybe notmuch should be reporting the total size of the mail
store as well...]

> Warning: Unexpected extra parts of multipart/signed. Indexing anyway.

Oh, that's a warning I put in place because I wasn't sure if it was
legitimate for a multipart/signed message to have more than two
parts. I'd actually be interested to know if the mail is correct, (and I
should just eliminate the warning), or if the mail is somehow malformed
and the warning is correct.

> Note: Ignoring non-mail file:
> /home/jeff/mail/message/6/5/65c74c15a686187bb6bbf9958f494fc6b80068034a659a9ad44991b08c58f2d2
> Note: Ignoring non-mail file:
> /home/jeff/mail/message/7/9/7902699be42c8a8e46fbbb4501726517e86b22c56a189f7625a6da49081b2451
> Note: Ignoring non-mail file:
> /home/jeff/mail/message/8/0/802071f7fcd8b0b74a19e1ca64e5468184fee0c9171bacb77ae1fe1669c426ee

Those you should check to see if they actually do look like mail
messages. Notmuch decides to ignore a file when it can't find any of the
following headers: Subject:, From:, not To:.

> A Xapian exception occurred creating message: Db block overwritten -
> are there multiple writers?
> Error: A Xapian exception occurred. Halting processing.

That's an error I've never seen before. We might want to talk to the
Xapian folks to see what that could be. There's really no way there can
be multiple writers here. So I don't know what the actual problem might
be.

> Internal error: Message with document ID of 175013 has no thread ID.
>  (lib/message.cc:353).
> [jeff at max1 notmuch]$ ./notmuch new
> Internal error: Message with document ID of 175013 has no thread ID.
>  (lib/message.cc:353).

Hmm... we could probably do better here. The fatal error you're getting
here is for an invariant that notmuch thinks is fairly important, (no
mail document should exist without a thread ID). Meanwhile, however when
adding a new message we do actually create a mail document in the
database, and only later resolve its thread ID and add that to the
database as well. A better solution would be to resolve the thread ID
before adding anything to the database so that this invariant would
never be violated.

Some people have been proposing a "notmuch gc" command or so for
cleaning up problems like this.

In the meantime, you could explore the current state of your database by
changing the code that's currently giving you an internal error to
instead return a fake thread ID. For example:

if (i == message->doc.termlist_end () || id[0] != *prefix)
message->thread_id = talloc_strdup (message, 
"");
else
message->thread_id = talloc_strdup (message, id.c_str () + 1);

Good luck!

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/1e284ef9/attachment.pgp>


[notmuch] [PATCH] Return unpropertized strings for filename and message-id

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 18:31:23 -0500 (EST), Bart Trojanowski  
wrote:
> [[ First of all I am jazzed because this is the first email I am
> sending to anyone other than myself from the vim interface to
> notmuch ]]

Congratulations Bart on a fine milestone!

Well done.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/9fca7f74/attachment.pgp>


[notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id.

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 15:18:31 +0100, Jed Brown  wrote:
> On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth  wrote:
> > Thanks for the patch, Jed, I almost pushed it, but noticed that it's
> > calling `called-interactively-p' with an argument even though that
> > function does not accept an argument.
> 
> My docs say it does take an argument:

Ah. So we have our first case of emacs-lisp portability issues. This is
what I get:

called-interactively-p is a built-in function in `C source code'.

(called-interactively-p)

Return t if the function using this was called with
`call-interactively'.  This is used for implementing advice and
other function-modifying features of Emacs.

The cleanest way to test whether your function was called with
`call-interactively' is by adding an extra optional argument, and
making the `interactive' spec specify non-nil unconditionally for
that argument.  (`p' is a good way to do this.)

> I thought my usage fell precisely under "in deciding whether to display
> a helpful message, or how to display it".  This message is just noise if
> executed inside a macro.  As further evidence, see copy-region-as-kill
> (simple.el):

Here's what I see for that:

(defun copy-region-as-kill (beg end)
  "Save the region as if killed, but don't kill it.
In Transient Mark mode, deactivate the mark.
If `interprogram-cut-function' is non-nil, also save the text for a window
system cut and paste.

This command's old key binding has been given to `kill-ring-save'."
  (interactive "r")
  (if (eq last-command 'kill-region)
  (kill-append (filter-buffer-substring beg end) (< end beg))
(kill-new (filter-buffer-substring beg end)))
  (setq deactivate-mark t)
  nil)

No called-interactively anywhere.

> Let me know if you still want me to change it.

I can't apply the patch as it since it just results in an error.

I'm using "GNU emacs 23.1.1" currently, for what it's worth.

> > So for passing the thread ID to notmuch users, the "id:" prefix is
> > convenient. For passing it not non-notmuch-based consumers it won't be
> > desired. And that's hard to fix.
> 
> I'm thinking of having a prefix determine whether it is stripped or not.
> Do you have a preference about which is the non-prefix behavior?

Not a strong preference either way. It's just a few characters after
all.

> > I think long-term, a good solution would be to switch from "id:foo" to
> > "" as the syntax for message-ID-based search strings. That's then a
> > syntax that almost any consumer of a message ID should be prepared to
> > accept.
> 
> Downside is that it requires shell escapes when pasting into a terminal.

Yeah, there is that.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/e25bf6e8/attachment-0001.pgp>


[notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Alexander Botero-Lowry
On Fri, 27 Nov 2009 23:43:34 -0600, Jeffrey Ollie  wrote:
> On Fri, Nov 27, 2009 at 9:59 PM, Ingmar Vanhassel  
> wrote:
> >
> > Most distributions have a rather strict policy to use system libraries
> > over internal copies.
> 
> Fedora [...], Debian [...]
> 
> If there are other distributions out there that have similar policies
> I'd be interested in learning about them.
> 
FreeBSD ports are expected to not use bundled libraries as well.

Alex


[notmuch] [PATCH 2/2] vim: use notmuch show --entire-thread

2009-11-27 Thread Bart Trojanowski
---
 vim/plugin/notmuch.vim |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 34d70d9..a226f20 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -409,7 +409,7 @@ endfunction

 function! s:NM_cmd_show(words)
 let prev_bufnr = bufnr('%')
-let data = s:NM_run(['show'] + a:words)
+let data = s:NM_run(['show', '--entire-thread'] + a:words)
 let lines = split(data, "\n")

 let info = s:NM_cmd_show_parse(lines)
-- 
1.6.4.4.2.gc2f148



[notmuch] [PATCH 1/2] notmuch-show: limit display to only matching messages

2009-11-27 Thread Bart Trojanowski
This patch changes the default behaviour of notmuch show to display only
messages that match the search expression.  However, --entire-thread
option is provided to display all messages in threads that matched the
search expression.

It is deemed that will be more useful for human users on the command line.
Scripts can be modified to include the --entire-thread option so that they
can display all messages once more.

Example:

$ notmuch search subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b
thread:23d99d0f364f93e90e15df8b42eddb5b  July 31 [4/12] Johan Herland; 
[RFCv2 00/12] Foreign VCS helper program for CVS repositories (inbox unread)

Note that in this thread 4 out of 12 messages matched.  The default show
behaviour is to show only those messages that match:

$ notmuch show subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b | grep 
'message{' | wc -l
4

With the --only-matching-messages option the output will contain all dozen
messages:

$ notmuch show --entire-thread subject:git AND 
thread:23d99d0f364f93e90e15df8b42eddb5b | grep 'message{' | wc -l
12

Signed-off-by: Bart Trojanowski 
---
 notmuch-show.c |   48 +---
 notmuch.c  |8 
 2 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index 13c91e4..60339d0 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -212,6 +212,24 @@ notmuch_show_command (void *ctx, unused (int argc), unused 
(char *argv[]))
 notmuch_thread_t *thread;
 notmuch_messages_t *messages;
 char *query_string;
+int entire_thread = 0;
+int i;
+
+for (i = 0; i < argc && argv[i][0] == '-'; i++) {
+   if (strcmp (argv[i], "--") == 0) {
+   i++;
+   break;
+   }
+if (strcmp(argv[i], "--entire-thread") == 0) {
+   entire_thread = 1;
+   } else {
+   fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
+   return 1;
+   }
+}
+
+argc -= i;
+argv += i;

 config = notmuch_config_open (ctx, NULL, NULL);
 if (config == NULL)
@@ -239,21 +257,29 @@ notmuch_show_command (void *ctx, unused (int argc), 
unused (char *argv[]))
return 1;
 }

-for (threads = notmuch_query_search_threads (query);
-notmuch_threads_has_more (threads);
-notmuch_threads_advance (threads))
-{
-   thread = notmuch_threads_get (threads);
+if (!entire_thread) {
+   messages = notmuch_query_search_messages (query);
+   if (messages == NULL)
+   INTERNAL_ERROR ("No messages.\n");
+   show_messages (ctx, messages, 0);

-   messages = notmuch_thread_get_toplevel_messages (thread);
+} else {
+   for (threads = notmuch_query_search_threads (query);
+   notmuch_threads_has_more (threads);
+   notmuch_threads_advance (threads))
+   {
+   thread = notmuch_threads_get (threads);

-   if (messages == NULL)
-   INTERNAL_ERROR ("Thread %s has no toplevel messages.\n",
-   notmuch_thread_get_thread_id (thread));
+   messages = notmuch_thread_get_toplevel_messages (thread);

-   show_messages (ctx, messages, 0);
+   if (messages == NULL)
+   INTERNAL_ERROR ("Thread %s has no toplevel messages.\n",
+   notmuch_thread_get_thread_id (thread));
+
+   show_messages (ctx, messages, 0);

-   notmuch_thread_destroy (thread);
+   notmuch_thread_destroy (thread);
+   }
 }

 notmuch_query_destroy (query);
diff --git a/notmuch.c b/notmuch.c
index 5b0284c..ea67b4f 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -177,6 +177,14 @@ command_t commands[] = {
   "\t\t(all replies to a particular message appear immediately\n"
   "\t\tafter that message in date order).\n"
   "\n"
+  "\t\tSupported options for show include:\n"
+  "\n"
+  "\t\t--entire-thread\n"
+  "\n"
+  "\t\t\tBy default only messages strictly matching the\n"
+  "\t\t\tsearch expression will be displayed.  With this\n"
+  "\t\t\toption all messages in matching threads are shown.\n"
+  "\n"
   "\t\tThe output format is plain-text, with all text-content\n"
   "\t\tMIME parts decoded. Various components in the output,\n"
   "\t\t('message', 'header', 'body', 'attachment', and MIME 'part')\n"
-- 
1.6.4.4.2.gc2f148



[notmuch] [PATCH 1/2] New function notmuch-search-operate-all: operate on all messages in the current query.

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 15:32:44 +0100, Jed Brown  wrote:
> On Fri, 27 Nov 2009 06:02:45 -0800, Carl Worth  wrote:
> > Since this operates via a single call to "notmuch tag" you might mention
> > here that all tag removals occur before any tag additions.
> 
> I was unaware of this point, if I do
> 
>   notmuch tag -inbox +star tag:inbox some-expression
> 
> I will have starred nothing?

Oh no, it's not that.

It does one search and then does a single pass over all the messages
returned. So the above will star things.

The clarification about removing and adding really only matters if you
have the same tag appearing as both -foo and +foo in the same command
line, (which doesn't seem that useful, but there you have it).

I don't recall now why I made the special effort to handle tag removal
before tag addition rather than just applying tag changes in order. But
since that's what the current "notmuch tag" code does, I thought I
should point it out.

> > > + (unless (string-match-p "^[\+\-][_\+\-\\w]+$" (car words))
> > > +   (error "Action must be of the form `+thistag -that_tag'"))
> > 
> > The error message has inconsistent "thistag" and "that_tag".
> 
> That was somewhat intentional to illustrate that non-alphanumeric
> characters could be used in tags.  Should the alphabet for tags be based
> on a whitelist or blacklist?  It would be rather hard to validate a tag
> operation when there is no assumption/restriction on the alphabet.

Yeah, that's something we need to document. The current interface does
use space-separated tag lists without any escaping. But the command line
doesn't yet impose any restriction on tag names, and I did accidentally
add a tag once of just " " (oops!).

We should nail this down so that interface authors can know how to
validate things consistently. Any suggestions?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/04c40ff3/attachment.pgp>


[notmuch] [PATCH] notmuch-new: Eliminate tallocs whilst construct filenames.

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 14:17:02 +, Chris Wilson  
wrote:
> > I *know* I composed a reply to this message earlier, but apparently
> > you're right that it never went out. (*sigh*---if only I had a reliable
> > mail client[*]).
> 
> I hear there's one called sup... ;-)

Heh. But seriously, I hit a lot of crashes with sup, and that invariably
led to *lots* of lost tag changes. I'm willing to live with lots of
Xapian-defect-250 pain right now to avoid that lossage.

> The issue I see with the "error, continue" pattern is that we are in
> danger of not reporting the first error but the last one.

OK. That would be a problem, yes.

> Is notmuch ready for fault-injection yet? Maybe once you have a nasty
> testsuite...

It's not "ready" in the sense that there is going to be a huge series of
fixes that fault-injection will find. But it's definitely "ready" in
the sense that I want to start doing this kind of testing.

But yes, we need a test suite.

Oh, and we'll also need to deal with remaining glib usage inside of
notmuch, (and inside of GMime as well), before we can do good testing
for memory-fault injection. Maybe what we'll end up with is a patch to
de-glib-ify GMime? I'm not sure.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/4e9dbb16/attachment.pgp>


[notmuch] [PATCH] notmuch-new: Check for non-fatal errors from stat()

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 13:50:11 +, Chris Wilson  
wrote:
> Currently we assume that all errors on stat() a dname is fatal (but
> continue anyway and report the error at the end). However, some errors
> reported by stat() such as a missing file or insufficient privilege,
> we can simply ignore and skip the file. For the others, such as a fault
> (unlikely!) or out-of-memory, we handle like the other fatal errors by
> jumping to the end.

Thanks! Pushed.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/8e2b3386/attachment.pgp>


[notmuch] [PATCH] vim: preserve the 'show everything' flag when finding next/prev buffer

2009-11-27 Thread Bart Trojanowski
When show mode is invoked it could be displaying just the matched messages
or everything.  This flag is passed to NM_search_show_thread().  It is then
stored in a buffer variable, b:nm_show_everything, and used for subsequent
calls to NM_search_show_thread() triggered by ,  and .

Signed-off-by: Bart Trojanowski 
---
 vim/plugin/notmuch.vim |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index b415f50..34d70d9 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -275,6 +275,7 @@ function! s:NM_search_show_thread(everything)
 call add(words, ')')
 endif
 call NM_cmd_show(words)
+let b:nm_show_everything = a:everything
 endfunction

 function! s:NM_search_prompt()
@@ -430,6 +431,7 @@ function! s:NM_cmd_show(words)
 endfunction

 function! s:NM_show_previous(can_change_thread, find_matching)
+let everything = exists('b:nm_show_everything') ? b:nm_show_everything 
: 0
 let info = b:nm_raw_info
 let lnum = line('.')
 for msg in reverse(copy(info['msgs']))
@@ -450,7 +452,7 @@ function! s:NM_show_previous(can_change_thread, 
find_matching)
 call NM_kill_this_buffer()
 if line('.') > 1
 norm k
-call NM_search_show_thread()
+call NM_search_show_thread(everything)
 norm G
 call NM_show_previous(0, a:find_matching)
 else
@@ -479,10 +481,11 @@ function! s:NM_show_next(can_change_thread, find_matching)
 endfunction

 function! s:NM_show_next_thread()
+let everything = exists('b:nm_show_everything') ? b:nm_show_everything 
: 0
 call NM_kill_this_buffer()
 if line('.') != line('$')
 norm j
-call NM_search_show_thread()
+call NM_search_show_thread(everything)
 else
 echo 'No more messages.'
 endif
-- 
1.6.4.4.2.gc2f148



[notmuch] [PATCH 9/9] Key binding rearrangement for save attachments in show mode

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:15 -0800, camalot at picnicpark.org wrote:
> The most obvious bindings for save attachments are already taken.  The
> existing 'w' binding was bound to view the raw message.  This commit
> moves it to 'V' which still seems somewhat mnemonic and uses 'w' for
> save (write) attachments.

I'm fine giving up 'w' to this---'V' for view-raw is a better mnemonic
than my original, weak, 'w' for raW.

Thanks again,

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/96577413/attachment.pgp>


[notmuch] [PATCH 8/9] Provide ability to save attachments

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:14 -0800, camalot at picnicpark.org wrote:
> From: Keith Amidon 
> 
> Previously the only way to save an attachment was to attempt to view
> it and then save it from within the viewer program.

Very nice, Keith. Thanks again!

I've pushed this one out as well.

While we're talking about saving attachments, here are some additional
things I'd like for anybody that cares to attempt to implement them:

1. A binding to save all attachments to a single directory, (could be on
   'W' for example).

2. The ability to save an individual attachment based on a button.

3. The ability to view an individual attachment based on a button.

Parts (2) and (3) might end up wanting to be integrated via a new
command in the notmuch command-line program for extracting a numbered
mime part from the message. That command would then be usable by the
various interfaces that don't have all the functionality that emacs has
already builtin for handling MIME messages.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/5c370e71/attachment.pgp>


[notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Jeffrey C. Ollie
Instead of including a private implementation of the SHA1 hash, use
libgcrypt.  This means less code of our own to maintain and it will be
easier to switch to a different hash function like SHA256.

libgcrypt was chosen because it has a fairly simple API, it's well
tested (it's used in gnutls and gnupg2), and it's licensed under the
LGPL.

Signed-off-by: Jeffrey C. Ollie 
---
 Makefile   |6 +-
 configure  |   15 +++-
 lib/Makefile.local |1 -
 lib/libsha1.c  |  242 
 lib/libsha1.h  |   67 --
 lib/sha1.c |   44 +-
 6 files changed, 42 insertions(+), 333 deletions(-)
 delete mode 100644 lib/libsha1.c
 delete mode 100644 lib/libsha1.h

diff --git a/Makefile b/Makefile
index 2cd1b1b..a5ff3e7 100644
--- a/Makefile
+++ b/Makefile
@@ -10,7 +10,8 @@ gzip = gzip

 # Additional flags that we will append to whatever the user set.
 # These aren't intended for the user to manipulate.
-extra_cflags := $(shell pkg-config --cflags glib-2.0 gmime-2.4 talloc)
+extra_cflags := $(shell pkg-config --cflags glib-2.0 gmime-2.4 talloc) \
+   $(shell libgcrypt-config --cflags)
 extra_cxxflags := $(shell xapian-config --cxxflags)

 emacs_lispdir := $(shell pkg-config emacs --variable sitepkglispdir)
@@ -28,7 +29,8 @@ override CXXFLAGS += $(WARN_FLAGS) $(extra_cflags) 
$(extra_cxxflags)

 override LDFLAGS += \
$(shell pkg-config --libs glib-2.0 gmime-2.4 talloc) \
-   $(shell xapian-config --libs)
+   $(shell xapian-config --libs) \
+   $(shell libgcrypt-config --libs)

 # Include our local Makefile.local first so that its first target is default
 include Makefile.local
diff --git a/configure b/configure
index b4770ec..22f8066 100755
--- a/configure
+++ b/configure
@@ -61,6 +61,15 @@ else
 have_valgrind=
 fi

+if libgcrypt-config --version > /dev/null 2>&1; then
+echo "Checking for libgcrypt development files... Yes."
+have_libgcrypt=1
+else
+echo "Checking for libgcrypt development files... No."
+have_libgcrypt=0
+errors=$((errors + 1))
+fi
+
 if [ $errors -gt 0 ]; then
 cat > (32 - n)))
-#define rotr32(x,n)   (((x) >> n) | ((x) << (32 - n)))
-
-#define bswap_32(x) ((rotr32((x), 24) & 0x00ff00ff) | (rotr32((x), 8) & 
0xff00ff00))
-
-#if (PLATFORM_BYTE_ORDER == IS_LITTLE_ENDIAN)
-#define bsw_32(p,n) \
-{ int _i = (n); while(_i--) ((uint32_t*)p)[_i] = 
bswap_32(((uint32_t*)p)[_i]); }
-#else
-#define bsw_32(p,n)
-#endif
-
-#define SHA1_MASK   (SHA1_BLOCK_SIZE - 1)
-
-#if 0
-
-#define ch(x,y,z)   (((x) & (y)) ^ (~(x) & (z)))
-#define parity(x,y,z)   ((x) ^ (y) ^ (z))
-#define maj(x,y,z)  (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
-
-#else   /* Discovered by Rich Schroeppel and Colin Plumb   */
-
-#define ch(x,y,z)   ((z) ^ ((x) & ((y) ^ (z
-#define parity(x,y,z)   ((x) ^ (y) ^ (z))
-#define maj(x,y,z)  (((x) & (y)) | ((z) & ((x) ^ (y
-
-#endif
-
-/* Compile 64 bytes of hash data into SHA1 context. Note*/
-/* that this routine assumes that the byte order in the */
-/* ctx->wbuf[] at this point is in such an order that low   */
-/* address bytes in the ORIGINAL byte stream will go in */
-/* this buffer to the high end of 32-bit words on BOTH big  */
-/* and little endian systems*/
-
-#ifdef ARRAY
-#define q(v,n)  v[n]
-#else
-#define q(v,n)  v##n
-#endif
-
-#define one_cycle(v,a,b,c,d,e,f,k,h)\
-q(v,e) += rotr32(q(v,a),27) +   \
-  f(q(v,b),q(v,c),q(v,d)) + k + h;  \
-q(v,b)  = rotr32(q(v,b), 2)
-
-#define five_cycle(v,f,k,i) \
-one_cycle(v, 0,1,2,3,4, f,k,hf(i  ));   \
-one_cycle(v, 4,0,1,2,3, f,k,hf(i+1));   \
-one_cycle(v, 3,4,0,1,2, f,k,hf(i+2));   \
-one_cycle(v, 2,3,4,0,1, f,k,hf(i+3));   \
-one_cycle(v, 1,2,3,4,0, f,k,hf(i+4))
-
-static void sha1_compile(sha1_ctx ctx[1])
-{   uint32_t*w = ctx->wbuf;
-
-#ifdef ARRAY
-uint32_tv[5];
-memcpy(v, ctx->hash, 5 * sizeof(uint32_t));
-#else
-uint32_tv0, v1, v2, v3, v4;
-v0 = ctx->hash[0]; v1 = ctx->hash[1];
-v2 = ctx->hash[2]; v3 = ctx->hash[3];
-v4 = ctx->hash[4];
-#endif
-
-#define hf(i)   w[i]
-
-five_cycle(v, ch, 0x5a827999,  0);
-five_cycle(v, ch, 0x5a827999,  5);
-five_cycle(v, ch, 0x5a827999, 10);
-one_cycle(v,0,1,2,3,4, ch, 0x5a827999, hf(15)); \
-
-#undef  hf
-#define hf(i) (w[(i) & 15] = rotl32(\
- w[((i) + 13) & 15] ^ w[((i) + 8) & 15] \
-   ^ w[((i) +  

[notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts

2009-11-27 Thread Alexander Botero-Lowry
On Fri, 27 Nov 2009 21:10:42 -0800, Carl Worth  wrote:
> On Fri, 27 Nov 2009 05:30:10 -0800, camalot at picnicpark.org wrote:
> > From: Keith Amidon 
> > 
> > The ability to temporarily create a buffer containing only the
> > contents of the currently selected message in notmuch show mode is
> > generally useful.  This commit factors the majority of the code
> > required to do so out of notmuch-show-view-all-mime-parts into a macro
> > called with-current-notmuch-show-message and rewrites the original
> > function in terms of the macro.
> > 
> > A future set of commits will provide additional functionality using
> > the macro as well.
> 
> Hurrah! I'm glad to see that you are wholly more capable with emacs lisp
> than I am. I knew of lisp macros of course, but didn't know the actual
> syntax for writing one.
> 
I actually did something similar for my html support. except I used
`with-temp-buffer' macro instead. I'm hoping that the need to ever
actually use the raw message buffer directly goes away, so I think it
would be better to use with-temp-buffer in your macro instead of the
named buffer.

Alex


[notmuch] [PATCH 6/9] Reply to individual messages using message library

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:12 -0800, camalot at picnicpark.org wrote:
> From: Keith Amidon 
> 
> As an alternative to creating a reply from the current thread, this
> commit provides functions to create replies directly in emacs using
> the message library.
> 
> A future commit will provide keybindings so that they are easy to
> change if a different set is preferred.

Can you fill me in a little bit here? The message-mode documentation is
quite thin on what the distinctions are between "reply", "wide-reply",
and "followup".

Meanwhile, I don't think we have any need to support different
implementations of reply, (that is---I don't want one binding for a
"notmuch-based reply" and another for a "message-mode-based reply"
without any functional difference in the result).

Instead I'd like to define what the functionality is that we want here,
and then provide that. I do like taking advantage of things like
message-mode functionality wherever it exists, so I'm happy to have the
default reply button do (with-current-notmuch-show-message
(message-reply)) or whatever.

But meanwhile, I'll *also* want to understand what the variations are
here so that we can *also* implement them inside of "notmuch reply" so
that non-emacs-based interfaces can easily get at similar functionality.

So I'm holding off on pushing this patch until I understand it better,
(and documentation strings for the new functions might help for
that---provided they have more detail than the corresponding
documentation strings for the message-mode functions being called).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/b31aea51/attachment.pgp>


[notmuch] [PATCH 2/3] have _notmuch_thread_create mark which messages matched the query

2009-11-27 Thread Bart Trojanowski
On Fri, 27 Nov 2009 17:15:35 -0800, Carl Worth  wrote:
> This is a very useful feature, Bart. Thanks for coding it up. And it's a
> nicely-implemented patch series as well.

Thanks.  I've found it very handy.

> By the way, do you think that this support obviates the
> --only-matching-messages option for "notmuch search" or does anyone
> still want that?

I personally don't have much use for it (in the notmuch.vim UI).  However, I
can see it being useful if someone reads the messages on the terminal, maybe
using some less verbose output format.

> Or maybe the right fix is to make "notmuch show" display only matching
> messages by default, (which will likely be more friendly to a user
> manually typing "notmuch show" at the command line). And then make the
> user-interfaces pass an "--entire-thread" option (or so) to get the
> current results.

Sure, I'll fix up the patch and submit it in a bit.

> If we're going to make the command-line user-interface usable on its
> own, then I definitely want to make it be the user interfaces that have
> to pass extra-long command-line options to get what they want.

Agreed.  I still think we could use some templating for the different output
modes.  Maybe it will be important enough for soemone to implement :)

> One quick point on naming:
> 
> >  /* Message flags */
> >  typedef enum _notmuch_message_flag {
> > +NOTMUCH_MSG_FLAG_MATCHING_SEARCH,
> >  } notmuch_message_flag_t;
> 
> I like my enum values to match their type name without abbreviation. I
> also like internals (like this enum value) to match the way they are
> exposed in the interface, (which in this case is "match"). So I'd like
> the above value to instead be:
> 
>   NOTMUCH_MESSAGE_FLAG_MATCH

OK.  Patch is in flight.

Cheers,
-Bart

-- 
email sent from notmuch.vim plugin


[notmuch] [PATCH] correct message flag enum value so that it matches the type

2009-11-27 Thread Bart Trojanowski
As per Carl's request, this patch corrects the only value defined under
the notmuch_message_flag_t enum typedef to match the name of the type.

Signed-off-by: Bart Trojanowski 
---
 lib/notmuch.h  |2 +-
 lib/thread.cc  |2 +-
 notmuch-show.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/notmuch.h b/lib/notmuch.h
index e4f3992..60834fb 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -711,7 +711,7 @@ notmuch_message_get_filename (notmuch_message_t *message);

 /* Message flags */
 typedef enum _notmuch_message_flag {
-NOTMUCH_MSG_FLAG_MATCHING_SEARCH,
+NOTMUCH_MESSAGE_FLAG_MATCH,
 } notmuch_message_flag_t;

 /* Get a value of a flag for the email corresponding to 'message'. */
diff --git a/lib/thread.cc b/lib/thread.cc
index 9e4cb5c..321937b 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -148,7 +148,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,
notmuch_message_get_message_id (message), NULL,
(void **) _message)) {
notmuch_message_set_flag (hashed_message,
-   NOTMUCH_MSG_FLAG_MATCHING_SEARCH, 1);
+ NOTMUCH_MESSAGE_FLAG_MATCH, 1);
 }
 }

diff --git a/notmuch-show.c b/notmuch-show.c
index f189e94..13c91e4 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -158,7 +158,7 @@ show_message (void *ctx, notmuch_message_t *message, int 
indent)
 printf ("\fmessage{ id:%s depth:%d match:%d filename:%s\n",
notmuch_message_get_message_id (message),
indent,
-   notmuch_message_get_flag (message, 
NOTMUCH_MSG_FLAG_MATCHING_SEARCH),
+   notmuch_message_get_flag (message, NOTMUCH_MESSAGE_FLAG_MATCH),
notmuch_message_get_filename (message));

 printf ("\fheader{\n");
-- 
1.6.4.4.2.gc2f148



[notmuch] [PATCH 5/9] Forward individual messages using message-forward

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:11 -0800, camalot at picnicpark.org wrote:
> From: Keith Amidon 
> 
> Sometimes forwarding a message is preferable to replying and modifying
> the set of recipients.  This commit provides that ability using the
> message-forward function.

This is nice functionality---we were obviously missing a "forward"
command before. So I've pushed this.

Meanwhile, this does miss one piece of functionality that we have in
"notmuch reply" which is to select the From: address based on which
configured email address of the user was found in the recipient list of
the original message being forwarded.

Any suggestion for this functionality? Does message-mode provide
something similar? And if so, should notmuch.el simply read the notmuch
configuration for the various email addresses and provide them to
message-mode? I definitely don't want new users of notmuch to have to
configure email addresses both inside of notmuch and also inside of
message-mode, for example.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/b5d66f88/attachment.pgp>


[notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:10 -0800, camalot at picnicpark.org wrote:
> From: Keith Amidon 
> 
> The ability to temporarily create a buffer containing only the
> contents of the currently selected message in notmuch show mode is
> generally useful.  This commit factors the majority of the code
> required to do so out of notmuch-show-view-all-mime-parts into a macro
> called with-current-notmuch-show-message and rewrites the original
> function in terms of the macro.
> 
> A future set of commits will provide additional functionality using
> the macro as well.

Hurrah! I'm glad to see that you are wholly more capable with emacs lisp
than I am. I knew of lisp macros of course, but didn't know the actual
syntax for writing one.

As is probably painfully obvious, I've just been learning emacs lisp as
I've been forced to hear. And I'll be more than happy to step aside and
let experts take over. :-)

This piece is pushed.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/b545a2a5/attachment.pgp>


[notmuch] [PATCH 2/9] Adjust autoload comments

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:08 -0800, camalot at picnicpark.org wrote:
> From: Keith Amidon 
> 
> The previous location of autoload comments didn't seem to correspond
> with the functions most likely to be the entry points for using
> notmuch.  This change adjusts them to match those likely entry points.

I had a patch (on a side branch that I must have never merged) that just
removed these autoload comments. Do these even do anything for a file
that's not being built along with all the lisp code within emacs?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/14880643/attachment.pgp>


[notmuch] [PATCH 1/9] Explicitly require the message library

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:07 -0800, camalot at picnicpark.org wrote:
> From: Keith Amidon 
> 
> Functions provided by the message library were being used without
> ensuring it was loaded.

Thanks. This one at least we did just fix recently.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/51a17c63/attachment.pgp>


[notmuch] [PATCH -v6] notmuch.el: Use message-mode font-face to highlight mail headers

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 15:44:13 +0530, "Aneesh Kumar K.V"  wrote:
> Signed-off-by: Aneesh Kumar K.V 

Thanks for this patch, Aneesh. Deferring to existing message-mode faces
gets us out of the business of having to invent colors, and also means
user will only have to tweak the customization in one place to change
both composition and presentation of mail messages.

So I've pushed this out now.

This change does make a couple of other needed changes for our
presentation seem more urgent:

  1. We need to drop the reverse-video for the message summary line,
 (this was a standin for real face configuration which we have now).

  2. We need to figure out how to lose the underlining of the full-line
 buttons for the message-summary line and the subject line.

Anyway, thanks for the patch, and your patient submission of 6 versions
of it!

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/c85030c3/attachment.pgp>


[notmuch] [PATCH 2/2] add some very rudimentary support for handling html parts

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 01:13:33 -0800, Alexander Botero-Lowry  wrote:
> I was planning to be committing super awesome mime-handling support
> that would make notmuch rival every mail program ever for pure mime
> awesomeness. It turns out, that mime is confusing and hard, and the
> mm-* functions do awesome things like provide different forms based
> on the number and composition of mime-parts in a document, so I set
> my first-pass goal a bit lower. What this does, is if there is an
> html mime-part in the message and it's the first part, it gets inlined
> using `mm-display-part'. This should solve the biggest problem I was
> facing, which is HTML only messages that I have to go into the awful
> mime-mode to view.
> 
> This still even leaves in the Non-text part: message and all.

A very nice first step for support for HTML mail. Thanks, Alex!

This is definitely easier than viewing the raw mail message and trying
to read past all the tags. I did exercise some editorial license and
change the commit message, (removing references to future ideas,
etc.). Here's what I ended up with before pushing:

Add some very rudimentary support for handling html parts

If there is an html mime-part in the message and it's the first part,
it gets inlined using `mm-display-part' to convert it to plain text.

The HTML content is still available as a non-text part as well.

Thanks again,

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/e818f161/attachment.pgp>


[notmuch] [PATCH 1/2] add functions to toggle the nearest backwards button of a given type

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 01:13:32 -0800, Alexander Botero-Lowry  wrote:
> It was noted that though local expansion was nice, it was also pretty
> nice to have an easy way to just open the headers without moving to the
> header button. So this exposes a number of symbols which search backwards
> in the buffer for the nearest button of the desire type and push it

Why does this search backwards?

The binding I'm missing the most since we switched from global to local
toggling is 'h' for showing more of the current message's header.

I'd like that to work reliably for the current message regardless of
where point is, (whether before or after the header button in the
current message).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/5cd79ee0/attachment.pgp>


[notmuch] Show mode enhancements

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 05:30:06 -0800, camalot at picnicpark.org wrote:
> I started using notmuch a few days ago and was astounded at how much
> more efficiently I could process email with it.

Hi Keith, welcome to notmuch!

I'm delighted to hear a positive report like that about my little
project here. [Though, frankly, it's quickly gorwing beyond just "my"
project. We're about 10 days into the "public" phase of notmuch and
already I'm only creating about half of the commits going in. That's
fantastic!]

>  For my usage I needed
> a bit more flexibility in replying/forwarding messages and the ability
> to conveniently save attachments.  The set of patches that follow
> contain these two enhancements, a few minor fixes, and the addition of
> a binding of 's' in show mode to notmuch-search.

Hurrah! I'll go through each of these and review. But 's' in show mode I
know I'm going to love---I keep hitting 's' and then start typing
"tag:..." and end up archiving the current thread before I realize I'm
not doing what I think I am. :-}

> I'd be happy to address anything neded to get these changes into shape
> to be included in the main distribution.  Thanks for all your work
> putting together such a promising email client.

You're quite welcome, and thanks for your contributions!

-Carl

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/b30d363c/attachment-0001.pgp>


[notmuch] [PATCH 3/3] notmuch.el: Select tag names with completion.

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 12:30:38 +0100, Jan Janak  wrote:
> Oh, that's great, my first bigger contribution to nutmuch is in the
> repository, thanks so much! 

You're quite welcome.

> I was just thinking about giving you some time to catch up and review all the
> patches, but now I have a reason to send more again ;-).

Yes, please don't slow down. Like Keith recently mentioned to me---one
drawback with notmuch is that it makes it so easy and fun to get
through mail that you quickly end up without any mail and don't get to
play with notmuch anymore.

> Thanks for starting notmuch! I've been working on converting my 4GB mailbox
> with about a hundred tags from gmail to notmuch and while I am not there yet,
> I've made some good progress recently. That makes me really optimistic; I
> tried various other mail indexing tools before and never got that far.

Good luck with that! I know that the period of transitioning from one
mail system to another can be extremely painful. I hope you get through
it alright and end up better for it.

Happy hacking,

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/b852c092/attachment.pgp>


[notmuch] OpenPGP support

2009-11-27 Thread Carl Worth
On Thu, 26 Nov 2009 15:01:38 -0800, Keith Packard  wrote:
> On Thu, 26 Nov 2009 10:41:36 -0800, Carl Worth  wrote:
> 
> > I'm not sure how to make sure that I also get that when doing a reply
> > within notmuch. Keith, I think you worked this out, right? What did you
> > do?
> 
> ; sign messages by default
> (defun my-notmuch-message-mode-hook()
>   (if (buffer-modified-p)
>   (mml-secure-message-sign)))
> 
> (add-hook 'message-mode-hook 'my-notmuch-message-mode-hook)
> (add-hook 'message-setup-hook 'my-notmuch-message-mode-hook)

Thanks. And look! A signed reply now.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/a34f0f4a/attachment.pgp>


[notmuch] [PATCH] Return unpropertized strings for filename and message-id

2009-11-27 Thread Carl Worth
On Fri, 27 Nov 2009 09:13:12 +0100, Tassilo Horn  
wrote:
> I guess it won't be the last one.  There are some byte-compiler warnings
> with notmuch.el, that I'd like to remove.

Great! I'll look forward to more from you?

> So an email looking like this would be correct?

Almost. The place where you want to insert the explanatory text is
between the "---" marker and the line starting with "diff". See below.

> Normally it causes almost never any problems, but IMO it's just bad
> style.  When a user wants to get the Message-id, he most probably only
> wants to do some calculations on that (e.g. jump to that message in Gnus
> or rmail), or insert it somewhere else.  In the first case, text
> properties aren't needed, and in the second case, it's most unlikely
> that he wants to have exactly the same properties there, especially if
> there are properties different from faces.

Thanks for the explanation. The above paragraph would have been
*perfect* as the commit message.

> But instead of mailing each first-time committer a mail, you might
> consider putting those guidelines on the notmuch homepage. :-)

Yes, there's definitely a bunch of places that would be better to put
these things, (like in a HACKING file in the repository). But sometimes
it's just so *easy* to write email.

I will try to put things into better places before I repeat myself on
the list too much. But anyone can feel free to help by taking text I've
written in email and sending it back as patches to explanatory files
like HACKING.

And eventually I'll fix the website so that other people can contribute
to it as well.

Thanks again for all your help,

-Carl

--8<---cut here---start->8---
From: Tassilo Horn 
To: Carl Worth 
Cc: notmuch at notmuchmail.org
Date: Fri, 27 Nov 2009 08:54:41 +0100
Subject: [PATCH] Remove preprocessor code

Don't define RUNNING_ON_VALGRIND, so that notmuch is probably broken.
---
Hi Carl,

this patch is completely wrong.  Please don't apply it. :-)

And thanks again for the great work.

Bye,
Tassilo

 debugger.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/debugger.c b/debugger.c
index e8b9378..f32cdc9 100644
--- a/debugger.c
+++ b/debugger.c
@@ -24,8 +24,6 @@

 #if HAVE_VALGRIND
 #include 
-#else
-#define RUNNING_ON_VALGRIND 0
 #endif

 notmuch_bool_t
--8<---cut here---end--->8---


[notmuch] semi-usable notmuch-gtk client

2009-11-27 Thread Baruch Even
Hi,

I added a quick hack to show a message thread in notmuch-gtk and this 
makes it semi-usable. I don't actually parse the reply of notmuch-show 
but it's already passably usable to read mail.

Baruch


[notmuch] notmuch_threads_back and notmuch_messages_back

2009-11-27 Thread Carl Worth
On Thu, 26 Nov 2009 21:23:47 +0100, Ruben Pollan  
wrote:
> Is it possible to implement notmuch_threads_back and notmuch_messages_back?
> And I guess will make sense to have also notmuch_tags_back.
> 
> This functions will do the oposite than notmuch_threads_advance and
> notmuch_messages_advance. So I can use them as iterators going back and 
> forward.
> 
> I didn't check the implementation of notmuch. I don't know if will be easy or
> will need to redesign a lot of code.

Most cases of these iterators are built on Xapian iterators, (C++ objects with
overloaded operators). So those are just using ++ for advance() and can
easily use -- for the new function, (I'd like a verb that pairs better
with "advance" than the non-verb "back"---any suggestions)?

So those won't need any new code. The one case that will need new code
is that for notmuch_message_get_replies and
notmuch_message_get_toplevel_messages the messages iterator is currently
built on a singly-linked list. Making it doubly linked would obviously
not be hard though.

-Carl


[notmuch] [PATCH] add missing comma in debugging code

2009-11-27 Thread Carl Worth
On Thu, 26 Nov 2009 11:32:35 -0400, David Bremner  wrote:
> - INTERNAL_ERROR ("Message %s has duplicate In-Reply-To IDs: %s and %s\n"
> +   INTERNAL_ERROR ("Message %s has duplicate In-Reply-To IDs: %s and 
> %s\n",

Thanks. This is pushed.

-Carl



[notmuch] Gmane

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 23:24:03 +0100, Ingmar Vanhassel  
wrote:
> In case anyone's interested, I've submitted this list to gmane:
> http://dir.gmane.org/gmane.mail.notmuch.general
> 
> Maybe someone who was on this list from the very beginning can submit an
> archive to them, for future reference.

I'll be glad to.

Will need to have a "notmuch search" that can output filenames
first. Actually, it might be nice to have one that could output a
maildir instead (like mairix does).

-Carl


[notmuch] [PATCH] notmuch.el: Require message mode to avoid undefined function in replies.

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 14:14:20 -0800, Eric Anholt  wrote:
> Otherwise, those without keithp's .emacs would end up with reply mode
> not being entered.  Suggested by keithp.

Thanks, Eric. The fact that replies were only sometimes in message-mode
was really annoying me. Should be nice to have this fixed. This is
pushed.

-Carl


[notmuch] [PATCH] notmuch-new: Test if directory looks like Maildir before skipping tmp.

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 22:11:45 +0100, Jan Janak  wrote:
> Files and subdirectories with the name "tmp" that do not look like
> Maildir will still be processed by 'notmuch new'.

This is a nice improvement. I realize we neglected to document the
original "tmp" skipping. This should definitely be safer, (though we
should document this as well).

And this maildir detection will also be useful for the outstanding patch
to add tags based on flags in maildir filenames.

I pushed the patch and then made two, minor whitespace fixes:

> +static int is_maildir (struct dirent **entries, int count)

The function name in the definition here belongs on its own line.

> + if (found == 3) return 1;

Having the action of the "if" statement on the same line as the "if"
itself hides it too much. That also belongs on the next line.

-Carl


[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-27 Thread Carl Worth
On Thu, 26 Nov 2009 22:12:02 +0100, Michiel Buddingh'  wrote:
> Carl Worth  wrote:
>   I considered that approach; ideally, we could test for the presence of
> all three of cur, tmp and new--but this is rather messy to do in the
> current treewalk structure.  Taking any one of them as proof positive of
> a Maildir might lead to unpleasant surprises--it's not all that incon-
> ceivable for someone to name a mail folder 'tmp'.

The auto-detection is just three additional stats (at most) for each
directory, right? That seems cheap enough to me.

>   There's another matter; Some mail stores will place (large) index files
> in folder roots, i.e. one level above cur/, tmp/ and new/.  Looking
> at the ones dovecot (an IMAP server) uses, I can make out a from header,
> a subject header, and a message-id, as plaintext in the first 100k or
> so.  It's not all that inconceivable that notmuch might register it as
> a 'real' email, with unpleasant consequences for the index.

That seems orthogonal to me. Would the dovecot index files be easy to
skip with a pattern-based blacklist?

>   I've seen some patches fly by that add support for multiple mail
> stores.  Turning on Maildir support on a per-directory basis might
> resolve that problem while still supporting heterogenous mail archives
> to some degree.  I am not convinced we can do the right thing
> automatically without causing some grief to a subset of users.

With sup, I had the opposite extreme compared to current notmuch. Every
maildir in the hierarchy had to be configured independently. That was a
lot of pain, and is precisely why notmuch started out by simply taking a
single top-level directory.

> Haven't tested it, but it seems you can put
> 
> [core]
> whitespace = trailing-space,space-before-tab

Yes. According to the documentation of git-config, those two values are
the default. But the documentation also only says that these will make
"git diff" display the undesired whitespace in red, and "git apply
--whitespace=error" refuse to apply.

I can't find a builtin way to make "git commit" complain, or I would
recommend that.

> I'll be happy to implement them, although I'd like for others to chime
> in on the configure-as-Maildir vs. autodetect-Maildir issue.  And thanks
> for your patience in working through my patch.

No problem at all. I'll look forward to the next version of the
patch. Consider mine as a vote for autodetection of maildir rather than
configuration.

-Carl


[notmuch] Problems importing my mail...

2009-11-27 Thread Jeffrey Ollie
I'm having some problems importing my mail.  I've got quite a bit
stored up, and some of them I'm sure are quite large.  After several
hours I get the following.  Is notmuch running out of memory on me?

$ ./notmuch new
Found 328184 total files.
Warning: Unexpected extra parts of multipart/signed. Indexing anyway.
Note: Ignoring non-mail file:
/home/jeff/mail/message/6/5/65c74c15a686187bb6bbf9958f494fc6b80068034a659a9ad44991b08c58f2d2
Note: Ignoring non-mail file:
/home/jeff/mail/message/7/9/7902699be42c8a8e46fbbb4501726517e86b22c56a189f7625a6da49081b2451
Note: Ignoring non-mail file:
/home/jeff/mail/message/8/0/802071f7fcd8b0b74a19e1ca64e5468184fee0c9171bacb77ae1fe1669c426ee
A Xapian exception occurred creating message: Db block overwritten -
are there multiple writers?
Error: A Xapian exception occurred. Halting processing.
Internal error: Message with document ID of 175013 has no thread ID.
 (lib/message.cc:353).
[jeff at max1 notmuch]$ ./notmuch new
Internal error: Message with document ID of 175013 has no thread ID.
 (lib/message.cc:353).

-- 
Jeff Ollie


[notmuch] Using notmuch from Ruby, Python, et al.

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 09:58:00 -0800, Scott Robinson  
wrote:
> Excerpts from Jeffrey Ollie's message of Wed Nov 25 09:46:47 -0800 2009:
> 
> I selected cJSON because it was simple for integration. Given how libsha1.c is
> included in lib/, I figured adding a depedency wouldn't be very
> popular.

I'm not dead-set against additional dependencies, but I think I do take
a conservative approach, (hence copying in the tiny libsha1.c rather
than linking to any enormous encryption library).

> Would it be better to link with a previously existing library?

For something like this, I don't see the need for any library at
all---generating any particular format is always *much* easier than
parsing it.

So I wouldn't mind seeing a couple of tiny functions in notmuch for this
(or other formats). And I think it would be better to start with code
that's already written and debugged (and license compatible!) rather
than starting from scratch.

> Q: Why are my replies five sentences or less?
> A: http://five.sentenc.es/

There---just five this time. :-)

-Carl


[notmuch] Using notmuch from Ruby, Python, et al.

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 08:16:54 -0800, Scott Robinson  
wrote:
> I'm hoping this thread will provide a guide for my efforts.
> 
> I'm writing a web frontend for notmuch in Ruby. But, the output from the
> notmuch command-line is ambiguous. Therefore, I've started two branches
> experimenting with different ways of providing hooks.

Hi Scott, welcome to notmuch!

A web frontend sounds very interesting, and I'll look forward to see
what you come up with here.

> Which of these approaches are likely to be pulled upstream?

Both, in fact!

> == Shared Library
> 
> I have modified the build to output a shared library. It's a small change
> relying on libtool.

We definitely want to have a shared library at some point. To some
extent, publishing a shared library commits us to maintaining API/ABI
for that library, and that's something I'm not willing to commit to
at this point, (since we're still seeing a fair amount of churn in the
interface).

But then again, we're also not even putting out a tar-file release yet
either, so I think it's easy to say that we're not "publishing" anything
yet and the API is all still subject to change.

> However, the archives indicate Carl dislikes libtool?

I've been maintaining a mainstream library (cairo) for several years
that uses libtool in its build system. So I know what that's like and I
definitely don't like it.

I haven't yet tried maintaining a library without using libtool, but I'm
optimistic that it will be much less painful, so that's what I'd like to
do for now.

> == JSON output
> 
> I added a --output=(text|json) option to "search" and "show." Then, emit json
> results appropriately.
> 
> To accomplish this, I used the cJSON library sans parsing logic.
> 
> However, I saw discussion about providing a --format option?

Obviously the exact name isn't that important and is easy to change. But
yes, this kind of thing looks very interesting.

> Q: Why are my replies five sentences or less?
> A: http://five.sentenc.es/

I guess I lose (or you do since you're the one receiving it). I count
this as sentence number 13 in my reply. :-)

-Carl


[notmuch] [PATCH] Return unpropertized strings for filename and message-id

2009-11-27 Thread Bart Trojanowski
* Bart Trojanowski  [091127 18:32]:
> You can actually put arbitrary text between the diffstat output and the first
> diff --git line.  For example:

Oops, and that's exactly what you said...

> >  So to satisfy "git am", introductory and explanatory portions of
> >  the email, ("Hi!" and "Here's my first patch"), have to be
> >  relegated to past the "---" divider).

Sorry.

-- 
WebSig: http://www.jukie.net/~bart/sig/


[notmuch] [PATCH] Silence compiler warning by initializing a variable.

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 07:01:36 -0600, "Jeffrey C. Ollie"  
wrote:
> If Xapian threw an exception on notmuch_query_count_messages the count
> variable could be used uninitialized.  Initialize count to solve the
> problem.

Thanks for the fix. This is pushed.

-Carl


[notmuch] [PATCH] Return unpropertized strings for filename and message-id

2009-11-27 Thread Bart Trojanowski
[[ First of all I am jazzed because this is the first email I am sending to
anyone other than myself from the vim interface to notmuch ]]

Getting on wit the show...

>  So to satisfy "git am", introductory and explanatory portions of
>  the email, ("Hi!" and "Here's my first patch"), have to be
>  relegated to past the "---" divider).
> 
>  I actually don't love this about "git am", since I think those
>  introductory parts are essential to having cordial and friendly
>  exchanges on the mailing list, (rather than just dryly shooting
>  code back and forth). And it feels natural to have them first. One
>  thing that might be interesting is to teach "git am" about an
>  additional divider so that other text can came *before* the commit
>  message.
> 
>  Alternately, one can put introductory text in one message, and the
>  dry commit-only stuff as a reply.

You can actually put arbitrary text between the diffstat output and the first
diff --git line.  For example:

--- 8< ---
>From e6628e78d9ce3f9383a4699df9063a648617b428 Mon Sep 17 00:00:00 2001
From: Bart Trojanowski 
Date: Fri, 27 Nov 2009 18:02:05 -0500
Subject: [PATCH] this is the patch description

Text that goes here will end up in the git commit.
---
 vim/README |3 ++-
 1 files changed, 11 insertions(+), 12 deletions(-)

Anything that goes here will be ignored, so you can typ

diff --git a/vim/README b/vim/README
index 299c7f8..8cd3b1a 100644
--- a/vim/README
+++ b/vim/README
@@ -42,7 +42,8 @@ Buffer types:
 You are presented with the search results when you run :NotMuch.

 Keybindings:
- - show the selected message
+ - show the selected thread colapsing unmatched items
+ - show the entire selected thread
 a   - archive message (remove inbox tag)
 f   - filter the current search terms
 o   - toggle search screen order
-- 
1.6.4.4.2.gc2f148

--- 8< ---



-- 
email sent from notmuch.vim plugin


[notmuch] vim interface pull request

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 00:54:22 -0500, Bart Trojanowski  wrote:
> as you already know, I've spent some time working on a vim-based
> interface to notmuch.  I currently only depend on the 'march:[01]'
> patches that we talked about briefly on irc.  Everything else is
> isolated to the 'vim' directory and should not effect anyone else.
> 
> My efforts are cataloged here:
> 
> git://git.jukie.net/notmuch.git (vim branch)
> http://git.jukie.net/notmuch.git?a=shortlog;h=refs/heads/vim
> 
> Please consider pulling in the vim branch.

Thanks, Bart!

I've merged this branch now and pushed it out.

-Carl


[notmuch] [PATCH] notmuch-new: Fix notmuch new to look at files within symbolic links

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 10:28:24 +0530, "Aneesh Kumar K.V"  wrote:
> We look at the modified time of the database and the directory
> to decide whether we need to look at only the subdirectories.
> ie, if directory modified time is < database modified time
> then we have already looking at all the files withing the
> directory. So we just need to iterate through the subdirectories
> 
> But with symlinks we need to make sure we follow them even if
> the directory modified time is less than database modified time

Thanks, Aneesh!

I'm sure everyone with symlinks in their mail store is really going to
appreciate this fix. This is now pushed out.

-Carl


[notmuch] [PATCH -v2] notmuch.el: Use variable notmuch-search-oldest-first to decide the search order

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 10:28:13 +0530, "Aneesh Kumar K.V"  wrote:
> Make sure we use notmuch-search-oldest-first to decide the how
> the search result should be displayed. This helps to set the
> value to nil and have latest mail shown first. This also fix the
> notmuch-folder mode to use the right search order when we select
> a folder. Also the notmuch command is fixed to use the right ordering.

Thanks for the updated commit message. Unfortunately, I'd already
committed the earlier version of this patch.

I generally make passes over my queue of patches to review in
chronological order, (by thread of course). So when anyone has an
updated version of an earlier patch, it will help if the later patches
are sent as replies to the earlier patches.

Thanks,

-Carl


[notmuch] [PATCH 2/3] have _notmuch_thread_create mark which messages matched the query

2009-11-27 Thread Carl Worth
On Tue, 24 Nov 2009 23:54:34 -0500, Bart Trojanowski  wrote:
> When _notmuch_thread_create() is given a query string, it can return more
> messages than just those matching the query.  To distinguish those that
> matched the query expression, the MATCHING_SEARCH flag is set
> appropriately.

This is a very useful feature, Bart. Thanks for coding it up. And it's a
nicely-implemented patch series as well.

I've pushed this out now, so anyone reading along should be able to try
it with:

./notmuch show thread:6d5e3e276461188c5778c9f219f63782 and subject:"PATCH 2/3"

I can't wait to have the emacs support for opening only matched messages
by default.

By the way, do you think that this support obviates the
--only-matching-messages option for "notmuch search" or does anyone
still want that?

Or maybe the right fix is to make "notmuch show" display only matching
messages by default, (which will likely be more friendly to a user
manually typing "notmuch show" at the command line). And then make the
user-interfaces pass an "--entire-thread" option (or so) to get the
current results.

If we're going to make the command-line user-interface usable on its
own, then I definitely want to make it be the user interfaces that have
to pass extra-long command-line options to get what they want.

One quick point on naming:

>  /* Message flags */
>  typedef enum _notmuch_message_flag {
> +NOTMUCH_MSG_FLAG_MATCHING_SEARCH,
>  } notmuch_message_flag_t;

I like my enum values to match their type name without abbreviation. I
also like internals (like this enum value) to match the way they are
exposed in the interface, (which in this case is "match"). So I'd like
the above value to instead be:

NOTMUCH_MESSAGE_FLAG_MATCH

-Carl


[notmuch] [PATCH 2/2] Recognize reply --format=headers-only-git

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 19:02:19 +0100, Jed Brown  wrote:
> This currently means the same thing as --format=headers-only, but this
> name gives more freedom to change --format=headers-only without breaking
> existing versions of git.

While it may make sense in the future to put something git-specific
here, I'd rather wait on creating the additional option until we
actually have something.

Otherwise, our documentation is more complicated, and callers will feel
the need to call the longer option "just in case", and all for possibly
no reason at all.

-Carl


[notmuch] Notmuch-side support for git send-email --notmuch id:

2009-11-27 Thread Carl Worth
On Wed, 25 Nov 2009 02:35:12 +0100, Jed Brown  wrote:
> These two patches provide support for features like the one in the
> subject line.  Along with these two patches, I have one for git
> format-patch (which I will submit upstream soon) that uses the output
> from notmuch reply --format=headers-only to build a reply with proper
> referencing, To, and Cc fields.
> 
> Since options for git send-email are passed to git format-patch,
> 
>   git send-email --notmuch id:
> 
> is a substitute for
> 
>   git send-email --in-reply-to  --to  --cc  --add-header 
> 'References: ...'

Having "notmuch reply --format=headers-only" seems just great. Thanks
for submitting this.

I've pushed it all out except for the last --format=headers-only-git
piece, for which I'll comment on the patch.

Oh, and the documentation for "notmuch reply" needs to be updated, (in
notmuch.1 and notmuch.c). Could you take a whack at that?

Thanks,

-Carl



[notmuch] [PATCH -v6] notmuch.el: Use message-mode font-face to highlight mail headers

2009-11-27 Thread Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V 
---
 notmuch.el |   29 +++--
 1 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index d2ebb40..b089732 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -604,6 +604,32 @@ which this thread was originally shown."
   (set-marker beg nil)
   (set-marker end nil)
   )))
+(defun notmuch-fontify-headers ()
+  (progn
+(if (looking-at "[Tt]o:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-to))
+(if (looking-at "[B]?[Cc][Cc]:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-cc))
+(if (looking-at "[Ss]ubject:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-subject))
+(if (looking-at "[Ff]rom:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-other

 (defun notmuch-show-markup-header (depth)
   (re-search-forward notmuch-show-header-begin-regexp)
@@ -624,8 +650,7 @@ which this thread was originally shown."
 (forward-line)
 (while (looking-at "[A-Za-z][-A-Za-z0-9]*:")
   (beginning-of-line)
-  (overlay-put (make-overlay (point) (re-search-forward ":"))
-   'face 'bold)
+ (notmuch-fontify-headers)
   (forward-line)
   )
(indent-rigidly beg end depth)
-- 
1.6.5.2.74.g610f9



[notmuch] [PATCH 1/2] New function notmuch-search-operate-all: operate on all messages in the current query.

2009-11-27 Thread Jed Brown
On Fri, 27 Nov 2009 06:02:45 -0800, Carl Worth  wrote:
> Since this operates via a single call to "notmuch tag" you might mention
> here that all tag removals occur before any tag additions.

I was unaware of this point, if I do

  notmuch tag -inbox +star tag:inbox some-expression

I will have starred nothing?

> > +   (unless (string-match-p "^[\+\-][_\+\-\\w]+$" (car words))
> > + (error "Action must be of the form `+thistag -that_tag'"))
> 
> The error message has inconsistent "thistag" and "that_tag".

That was somewhat intentional to illustrate that non-alphanumeric
characters could be used in tags.  Should the alphabet for tags be based
on a whitelist or blacklist?  It would be rather hard to validate a tag
operation when there is no assumption/restriction on the alphabet.

Jed
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/f06fdd3e/attachment-0001.pgp>


[notmuch] [PATCH] notmuch-new: Remove the tiresome joke from the output.

2009-11-27 Thread Marten Veldthuis
On Fri, Nov 27, 2009 at 05:46:32AM -0800, Carl Worth wrote:
>> -} else {
>> -printf ("No new mail---and that's not much.\n");
>>  }
>
>Shouldn't we still print *something* here, though ("No new mail")?
>Imagine the new user trying to ensure "notmuch new" is working---and
>let's say it's not, (due to the current symlink bug or so). A silent
>success here won't make it clear whether "notmuch new" has actually done
>anything or not.

Yes, at first I thought I'd read the patch wrong... I think you definately 
want some output, just not the joke. Don't worry, it *was* funny the first 
time.

-- 
- Marten


[notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id.

2009-11-27 Thread Jed Brown
On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth  wrote:
> Thanks for the patch, Jed, I almost pushed it, but noticed that it's
> calling `called-interactively-p' with an argument even though that
> function does not accept an argument.

My docs say it does take an argument:

  called-interactively-p is a built-in function in `C source code'.

  (called-interactively-p KIND)

  Return t if the containing function was called by `call-interactively'.
  If KIND is `interactive', then only return t if the call was made
  interactively by the user, i.e. not in `noninteractive' mode nor
  when `executing-kbd-macro'.
  If KIND is `any', on the other hand, it will return t for any kind of
  interactive call, including being called as the binding of a key, or
  from a keyboard macro, or in `noninteractive' mode.

  The only known proper use of `interactive' for KIND is in deciding
  whether to display a helpful message, or how to display it.  If you're
  thinking of using it for any other purpose, it is quite likely that
  you're making a mistake.  Think: what do you want to do when the
  command is called from a keyboard macro?

  This function is meant for implementing advice and other
  function-modifying features.  Instead of using this, it is sometimes
  cleaner to give your function an extra optional argument whose
  `interactive' spec specifies non-nil unconditionally ("p" is a good
  way to do this), or via (not (or executing-kbd-macro noninteractive)).

> Meanwhile, the documentation of called-interactively-p suggests that
> using (interactive "p") is an easier way to check whether the function
> is called interactively.

I thought my usage fell precisely under "in deciding whether to display
a helpful message, or how to display it".  This message is just noise if
executed inside a macro.  As further evidence, see copy-region-as-kill
(simple.el):

  ;; This use of called-interactively-p is correct
  ;; because the code it controls just gives the user visual feedback.
  (if (called-interactively-p 'interactive)

Let me know if you still want me to change it.

> No, "git send-email" wouldn't strip that since it's a custom thing for
> notmuch.

Of course, I was just sloppy when pasting it into my shell, which rubbed
this issue in my face:

> So for passing the thread ID to notmuch users, the "id:" prefix is
> convenient. For passing it not non-notmuch-based consumers it won't be
> desired. And that's hard to fix.

I'm thinking of having a prefix determine whether it is stripped or not.
Do you have a preference about which is the non-prefix behavior?

> I think long-term, a good solution would be to switch from "id:foo" to
> "" as the syntax for message-ID-based search strings. That's then a
> syntax that almost any consumer of a message ID should be prepared to
> accept.

Downside is that it requires shell escapes when pasting into a terminal.

Jed
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/04e3f594/attachment.pgp>


[notmuch] [PATCH] notmuch-new: Eliminate tallocs whilst construct filenames.

2009-11-27 Thread Chris Wilson
Excerpts from Carl Worth's message of Fri Nov 27 13:23:06 + 2009:
> On Sun, 22 Nov 2009 00:57:10 +, Chris Wilson  chris-wilson.co.uk> wrote:
> > The majority of filenames will fit within PATH_MAX [4096] (because
> > that's a hard limit imposed by the filesystems) so we can avoid an
> > allocation per lookup and thereby eliminate a large proportion of the
> > overhead of scanning a maildir.
> 
> Hi Chris,
> 
> I *know* I composed a reply to this message earlier, but apparently
> you're right that it never went out. (*sigh*---if only I had a reliable
> mail client[*]).

I hear there's one called sup... ;-)

> Anyway, on to the promised review of the patch:
> 
> The basic idea of this I really like, of course. Thanks for helping to
> improve the efficiency of notmuch. But this part I don't:

It's a bit outdated now, the impact of the asprintf overhead is lost
with the introduction of the scandir. I'm sure the profiles will
indicate something else to improve beyond xapian...

> One might argue that the error-cleanup goto is a common and
> well-understood idiom, so that it's not bad to have. The problem I have
> with it is how much work it is to verify. If I'm reading one line of
> code in the middle of a function that's testing for an error case and
> handling it with goto, then I need to:
> 
> 1. Verify this condition, and that a return value variable gets
>set.
> 
> 2. Check down at the end of the function to ensure the correct
>objects are freed and the correct return value is returned.
> 
> 3. Check back up at the beginning of the function to ensure the
>relevant objects are initialized to NULL.
> 
> And beyond verification, one has to code in these three places
> simultaneously as well.
> 
> Meanwhile, by taking advantage of talloc like I did in the original
> version of this code, an error return becomes a much more local decision
> and is much simpler to code.

The issue I see with the "error, continue" pattern is that we are in
danger of not reporting the first error but the last one. The common
practice is abort on error and cleanup, and this single instance is
inconsistent with the rest of the error handling everywhere else in
notmuch-new.c. The argument to counter your 3 points is the unified
unwind approach where there is just a single exit path that handles
both error and normal returns. (You always have to set the appropriate
error value whether you continue or abort.)

The advantage of talloc is that it provides a convenient allocation
context that not only groups object by their associated lifetimes, but
provides a single point of access for reaping allocations on unwind. I
don't see how talloc affects the decision process on how to actually
handle errors, but it does make it easier to cleanup afterwards.

Is notmuch ready for fault-injection yet? Maybe once you have a nasty
testsuite...
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre


[notmuch] [PATCH -v5] notmuch.el: Use message-mode font-face to highlight mail headers

2009-11-27 Thread Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V 
---
 notmuch.el |   35 +--
 1 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 89ccef6..851c60c 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -595,6 +595,38 @@ which this thread was originally shown."
   (set-marker beg nil)
   (set-marker end nil)
   )))
+(defun notmuch-fontify-headers ()
+  (progn
+(if (looking-at "[Tt]o:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-to)))
+(beginning-of-line)
+(if (looking-at "[B]?[Cc][Cc]:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-cc)))
+(beginning-of-line)
+(if (looking-at "[Ss]ubject:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-subject)))
+(beginning-of-line)
+(if (looking-at "[Ff]rom:")
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward ":"))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward ".*$"))
+   'face 'message-header-other)))
+(beginning-of-line)
+
+))

 (defun notmuch-show-markup-header (depth)
   (re-search-forward notmuch-show-header-begin-regexp)
@@ -615,8 +647,7 @@ which this thread was originally shown."
 (forward-line)
 (while (looking-at "[A-Za-z][-A-Za-z0-9]*:")
   (beginning-of-line)
-  (overlay-put (make-overlay (point) (re-search-forward ":"))
-   'face 'bold)
+ (notmuch-fontify-headers)
   (forward-line)
   )
(indent-rigidly beg end depth)
-- 
1.6.5.2.74.g610f9



[notmuch] [PATCH -v5] notmuch.el: Add face support to search mode

2009-11-27 Thread Aneesh Kumar K.V
This patch use notmuch-tag-face showing tags in the notmuch-search-mode.

We can selectively highlight each tag by setting notmuch-tag-face-alist as below

(defface notmuch-tag-unread-face
 'class color)) (:foreground "goldenrod")))
  "Notmuch search mode face used to highligh tags.")

(defface notmuch-tag-inbox-face
 'class color)) (:foreground "red")))
  "Notmuch search mode face used to highligh tags.")

(setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
   ("inbox" . 'notmuch-tag-inbox-face)))
(require 'notmuch)

Signed-off-by: Aneesh Kumar K.V 
---
 notmuch.el |   23 ++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 551048a..4dc5a06 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -835,6 +835,16 @@ thread from that buffer can be show when done with this 
one)."
   (goto-char (point-max))
   (forward-line -1))

+(defface notmuch-tag-face
+ 'class color)) (:foreground "red")))
+  "Notmuch search mode face used to highligh tags."
+  :group 'notmuch)
+
+(defvar notmuch-tag-face-alist nil
+  "List containing the tag list that need to be highlighed")
+
+(defvar notmuch-search-font-lock-keywords  nil)
+
 ;;;###autoload
 (defun notmuch-search-mode ()
   "Major mode for searching mail with notmuch.
@@ -865,7 +875,18 @@ global search.
   (setq truncate-lines t)
   (setq major-mode 'notmuch-search-mode
mode-name "notmuch-search")
-  (setq buffer-read-only t))
+  (setq buffer-read-only t)
+  (if (not notmuch-tag-face-alist)
+  (add-to-list 'notmuch-search-font-lock-keywords (list
+   "\\(([^)]*)$\\)" '(1  'notmuch-tag-face)))
+(progn
+  (setq notmuch-search-tags (mapcar 'car notmuch-tag-face-alist))
+  (loop for notmuch-search-tag  in notmuch-search-tags
+do (add-to-list 'notmuch-search-font-lock-keywords (list
+   (concat "\\(" notmuch-search-tag "\\)")
+   `(1  ,(cdr (assoc notmuch-search-tag 
notmuch-tag-face-alist
+  (set (make-local-variable 'font-lock-defaults)
+ '(notmuch-search-font-lock-keywords t)))

 (defun notmuch-search-find-thread-id ()
   "Return the thread for the current thread"
-- 
1.6.5.2.74.g610f9



[notmuch] [PATCH] notmuch-new: Check for non-fatal errors from stat()

2009-11-27 Thread Chris Wilson
Currently we assume that all errors on stat() a dname is fatal (but
continue anyway and report the error at the end). However, some errors
reported by stat() such as a missing file or insufficient privilege,
we can simply ignore and skip the file. For the others, such as a fault
(unlikely!) or out-of-memory, we handle like the other fatal errors by
jumping to the end.

Signed-off-by: Chris Wilson 
---
 notmuch-new.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index 3cde3a7..71224c5 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -168,10 +168,21 @@ add_files_recursive (notmuch_database_t *notmuch,
next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);

if (stat (next, st)) {
+   int err = errno;
+
+   switch (err) {
+   case ENOENT:
+   /* The file was removed between scandir and now... */
+   case EPERM:
+   case EACCES:
+   /* We can't read this file so don't add it to the cache. */
+   continue;
+   }
+
fprintf (stderr, "Error reading %s: %s\n",
 next, strerror (errno));
ret = NOTMUCH_STATUS_FILE_ERROR;
-   continue;
+   goto DONE;
}

if (S_ISREG (st->st_mode)) {
-- 
1.6.5.3



[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-27 Thread Jan Janak
On 26-11 22:53, Ingmar Vanhassel wrote:
> Excerpts from Michiel Buddingh''s message of Thu Nov 26 22:12:02 +0100 2009:
> > Haven't tested it, but it seems you can put
> > 
> > [core]
> > whitespace = trailing-space,space-before-tab
> > 
> > into your ~/.gitconfig now.  I've also set emacs to mark trailing
> > whitespace with big red markers.
> 
> I think it should be in notmuch/.gitattributes, which doesn't relies on
> new contributors to set that up. It also doesn't force this on for every
> git repo one has.

This enforces the restrictions also on people's local commits, even those they
may never want to submit for inclusion into the official repository.

Asking people to follow certain rules when submitting patches for inclusion is
sensible, but I don't think notmuch should enforce this on all local commits
with notmuch/.gitattributes.

  -- Jan



[notmuch] [PATCH 3/3] notmuch.el: Select tag names with completion.

2009-11-27 Thread Jan Janak
Hi Carl,

On 26-11 07:15, Carl Worth wrote:
> On Mon, 23 Nov 2009 01:10:56 +0100, Jan Janak  wrote:
> > Several commands ask the user for a tag name. With this feature the
> > user can just press tab and Emacs automatically retrieves the list of
> > all existing tags from notmuch database with 'notmuch search-tags' and
> > presents a completion buffer to the user.
> > 
> > This feature is very useful for users who have a large number of tags
> > because it saves typing and minimizes the risk of typos.
> 
> Jan,
> 
> This feature is incredibly useful. Thanks so much for coding it!

You are welcome!

> I've had a bunch of messages that were effectively "lost" to me since
> switching from sup. I had been experimenting with different tag
> schemes, renaming tags, etc. within sup. But in sup there was no
> global-search-based tag manipulation command, so no easy way to update
> the tag names for messages tagged under the old scheme.
> 
> I'd been aware of the problem and knew I could just code something up to
> search for those old tags. But now I get to see the full list every time
> I hit TAB in emacs. So thanks!
> 
> I do still want to unify search, search-messages, search-tags, count,
> etc. But I've gone ahead and merged this whole series as-is to get the
> functionality out there for now.

Oh, that's great, my first bigger contribution to nutmuch is in the
repository, thanks so much! 

I was just thinking about giving you some time to catch up and review all the
patches, but now I have a reason to send more again ;-).

> I assume that everyone is aware that I'm reserving the right to change
> the library and command-line interface as much as I want right now.

Yeah, I personally have no problem with that. In fact I like it.

I think that not having the user interface fixed is a good thing at this early
stage. This is what makes notmuch so hackable :-), contributors like me don't
have to worry about breaking things (at least not too much).

>From my point of view, notmuch is still missing some important features. Also,
there is a bunch of people writing front-ends and they'll probably ask for
more, too. Personally, I think it would make sense to add what is missing and,
once you feel that notuch is reasonably feature-complete, you can design nice
and intuitive user interface for it.

I'd be happy to help you update the code that I contributed once you decide to
change the command-line interface.

> If you've got code or scripts that depend on these interfaces, I highly
> recommend that you get them contributed to the notmuch repository so
> that we can fix them up as we rework the library and command line.

Yeah, I will.

> (So, Bart, I'll merge the vim stuff which is using "notmuch count"
> before I change that, so I can fixup the vim stuff at the same time.)
> 
> Thanks again, Jan! Well done.

Thanks for starting notmuch! I've been working on converting my 4GB mailbox
with about a hundred tags from gmail to notmuch and while I am not there yet,
I've made some good progress recently. That makes me really optimistic; I
tried various other mail indexing tools before and never got that far.

-Jan


[notmuch] _notmuch_message_create_for_message_id makes extra call to notmuch_database_find_message

2009-11-27 Thread Keith Packard
On Fri, 27 Nov 2009 04:46:54 -0800, Carl Worth  wrote:

> Did the "if" statement immediately afterwards just look like error
> checking? It's not:

Yes, it did (I think my brain may have auto-inserted a '!' there).

Ok, having read the code a bit more carefully, this does look correct.

I have to say that _notmuch_message_create is a bit of a tricky name; as
it doesn't create a message so much as load a message from the database.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091127/01d51465/attachment.pgp>


[notmuch] [PATCH] Return unpropertized strings for filename and message-id

2009-11-27 Thread Tassilo Horn
Carl Worth  writes:

Hi Carl,

>> Here's my first patch.  It changes that notmuch-show-get-filename and
>> notmuch-show-get-message-id return simple strings and not propertited
>> strings.
>
> Thanks, Tassilo!
>
> It's great to have a contribution from you in notmuch. I've pushed
> this out now.

I guess it won't be the last one.  There are some byte-compiler warnings
with notmuch.el, that I'd like to remove.

> Two things with regards to your patch:
>
>   1. It's most convenient (for me) to apply emailed patches by sending
>  directly to "git am". And "git am" just happens to want to see the
>  complete commit message as the first thing in the mail message,
>  (continuing the summary of the commit which comes from the
>  subject).
>
>  So to satisfy "git am", introductory and explanatory portions of
>  the email, ("Hi!" and "Here's my first patch"), have to be
>  relegated to past the "---" divider).

So an email looking like this would be correct?

--8<---cut here---start->8---
From: Tassilo Horn 
To: Carl Worth 
Cc: notmuch at notmuchmail.org
Date: Fri, 27 Nov 2009 08:54:41 +0100
Subject: [PATCH] Remove preprocessor code

Don't define RUNNING_ON_VALGRIND, so that notmuch is probably broken.
---
 debugger.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/debugger.c b/debugger.c
index e8b9378..f32cdc9 100644
--- a/debugger.c
+++ b/debugger.c
@@ -24,8 +24,6 @@

 #if HAVE_VALGRIND
 #include 
-#else
-#define RUNNING_ON_VALGRIND 0
 #endif

 notmuch_bool_t
-- 
1.6.5.3

Hi Carl,

this patch is completely wrong.  Please don't apply it. :-)

And thanks again for the great work.

Bye,
Tassilo
--8<---cut here---end--->8---

>   2. Maybe I'll undermine my point above, but the commit here really
>  *does* need a commit message beyond the first line.
>
>  I've described this before as the one-line summary giving the
>  "what" and the rest of the commit message giving the "why".

Makes sense.

>  And this is a perfect case of that. I can see exactly what the
>  patch does, and it makes sense. But I tried to write the rest of
>  the commit message and found I couldn't. In what cases did the
>  presence of text properties cause a problem? I don't know, and
>  that's what the commit message should have said.

Normally it causes almost never any problems, but IMO it's just bad
style.  When a user wants to get the Message-id, he most probably only
wants to do some calculations on that (e.g. jump to that message in Gnus
or rmail), or insert it somewhere else.  In the first case, text
properties aren't needed, and in the second case, it's most unlikely
that he wants to have exactly the same properties there, especially if
there are properties different from faces.

> I'd said before that I would bounce patches with only a one-line
> summary. I guess I'm still too soft, but do expect me to be more
> strict on this in the future. :-)

Yes, that all makes perfect sense, and because there are so many people
and patches for notmuch (which is great!), there have to be some strict
guidelines.

But instead of mailing each first-time committer a mail, you might
consider putting those guidelines on the notmuch homepage. :-)

Bye,
Tassilo


[notmuch] [PATCH 6/9] Reply to individual messages using message library

2009-11-27 Thread Keith Amidon
{-- Fri, 27 Nov 2009 20:48:46 +0530: Aneesh  wrote: --}

  Aneesh> Hi, Really good set of patches. I am right now testing with
  Aneesh> the set of changes and found that

Thanks!

  Aneesh> a) notmuch-show-reply-current and other helpers doesn't put
  Aneesh> the mail content i am replying in the reply buffer in quoted
  Aneesh> form. What i was expecting was something similar to
  Aneesh> notmuch-show-reply but one that doesn't add all the email
  Aneesh> address.

Well, the fact that I mainly cared about message forwarding and not the
reply functions is turning out to show rather badly...  There appear to
be a number of problems with the reply functions starting with the fact
that I kill the buffer that has the original message contents in it as
soon as the reply buffer is constructed, which message doesn't really
like.  I can think of some ways around the problems but I'm getting the
sense that enhancing the notmuch C program's ability to generate
different styles of replies would be preferred to what I have done.

Forwarding works fine though... :-)

  Aneesh> b) The key-binding MA is really difficult to type. How about
  Aneesh> (kbd "M-a") ?  c) I liked the mail forward feature

My main criteria in selecting key bindings was that they not conflict
with current ones.  If this were to become the preferred way to do this
I'd be happy to change them to whatever consensus emerges.

 --- Keith




[notmuch] [PATCH 1/2] New function notmuch-search-operate-all: operate on all messages in the current query.

2009-11-27 Thread Carl Worth
On Thu, 26 Nov 2009 22:36:49 +0100, Jed Brown  wrote:
> It is often convenient to change tags on several messages at once.  This
> function applies any number of tag whitespace-delimited tag
> modifications to all messages matching the current query.

Thanks Jed,

I've applied both this and the following patch, (giving the consistent
treatment to '+, '-', and 'a'). One or two minor comments:

> +  +tagname  Add the tag `tagname'
> +  -tagname  Remove the tag `tagname'
> +
> +Each character of the tag name may consist of alphanumeric
> +characters as well as `_.+-'.

Since this operates via a single call to "notmuch tag" you might mention
here that all tag removals occur before any tag additions.

> + (unless (string-match-p "^[\+\-][_\+\-\\w]+$" (car words))
> +   (error "Action must be of the form `+thistag -that_tag'"))

The error message has inconsistent "thistag" and "that_tag".

But niether nit was worth blocking the commit on.

Thanks again,

-Carl


[notmuch] [PATCH] notmuch-new: Remove the tiresome joke from the output.

2009-11-27 Thread Carl Worth
On Tue, 24 Nov 2009 19:41:20 +, Chris Wilson  
wrote:
> As I see this every time I poll for new mail, the joke becomes very old
> very quickly.  The other instances of "not much" are shown much less
> often and have a much more natural style, this one however feels forced,
> impairing the humorous effect.

Fine. My joke wen stale quickly. I'll agree to remove it.

> -} else {
> - printf ("No new mail---and that's not much.\n");
>  }

Shouldn't we still print *something* here, though ("No new mail")?
Imagine the new user trying to ensure "notmuch new" is working---and
let's say it's not, (due to the current symlink bug or so). A silent
success here won't make it clear whether "notmuch new" has actually done
anything or not.

-Carl


[notmuch] [PATCH 1/5] make headers locally expandable/collapsable

2009-11-27 Thread Carl Worth
On Tue, 24 Nov 2009 11:49:40 -0800, Alexander Botero-Lowry  wrote:
> On Tue, 24 Nov 2009 11:40:24 -0800, Carl Worth  wrote:
>
> Odd. I wouldn't be suprised were that behavior the case, but I can not
> reproduce it locally. I totally agree it should be the case, but I seem
> to be able to expand collapse already open messages without a problem..

OK. I can't reproduce this now either. So feel free to ignore me.

-Carl


[notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id.

2009-11-27 Thread Carl Worth
Thanks for the patch, Jed, I almost pushed it, but noticed that it's
calling `called-interactively-p' with an argument even though that
function does not accept an argument. Meanwhile, the documentation of
called-interactively-p suggests that using (interactive "p") is an
easier way to check whether the function is called interactively.

Then, you also had one question:

On Tue, 24 Nov 2009 21:29:56 +0100, Jed Brown  wrote:
> It turns out that this ID has id: prefixed (which I thought was fine
> because I'm frequently doing another query with it).  But git send-email
> doesn't strip that, so this was not threaded correctly.  Would this be
> better with the id: prefix stripped?

No, "git send-email" wouldn't strip that since it's a custom thing for
notmuch.

So for passing the thread ID to notmuch users, the "id:" prefix is
convenient. For passing it not non-notmuch-based consumers it won't be
desired. And that's hard to fix.

I think long-term, a good solution would be to switch from "id:foo" to
"" as the syntax for message-ID-based search strings. That's then a
syntax that almost any consumer of a message ID should be prepared to
accept.

And that's something that will only really be possible when we bite the
bullet and write our own query parser rather than using the default
parser that Xapian provides.

-Carl



[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer

2009-11-27 Thread Carl Worth
[Sorry for the previous abbreviated reply---I suppose an early send is
bound to happen when you give me a new function with a "C-c C-c"
binding. ;-)]

On Tue, 24 Nov 2009 09:02:46 +0100, Tassilo Horn  
wrote:
> I'm a Gnus user and use notmuch mostly for searching.  When I want to
> reply to a message, I need to get back to Gnus, so that my Gnus posting
> styles (gcc into that group, right email address, correct signature,...)
> are applied.

Oh, good. I've been hoping to be able to get some advice from gnus
users. I want to figure out how to get gnus support for viewing
encrypted messages, etc.

Do you happen to know some good documentation for how to get started
with gnus for reading mail? I'd be happy even with the bare minimum to
just get gnus to view one single message from out of my mail
store. (Which is something I tried to figure out from the gnus manual,
but I never succeeded at.)

> Therefore, I created this small snippet.  Now C-c C-c inside some
> message in the *notmuch-show* buffer opens this article in a Gnus
> *Summary* buffer, where I can reply to it, forward it, ...

And this would be exactly the thing I would want for exploring gnus, if
only I could get it working.

If I just try to run it, I get:

Symbol's function definition is void: org-gnus-follow-link

And I suppose that's expected since I don't have gnus "running". If I
try to start gnus with "M-x gnus", I get:

Unable to open server nntp+news, go offline? (y or n) 

What's the simplest way for me to tell gnus that I won't be using it in
any other way than with the "nnimap+" folder I can tell you're using in
your snippet?

> BTW, why does `notmuch-show-get-message-id' prefix the message-id with
> "id:"?

That's to make the returned value a valid search string for sake of
"notmuch search". Compare to the way `notmuch-search-find-thread-id'
includes a "thread:" prefix.

-Carl


[notmuch] [PATCH 9/9] Key binding rearrangement for save attachments in show mode

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

The most obvious bindings for save attachments are already taken.  The
existing 'w' binding was bound to view the raw message.  This commit
moves it to 'V' which still seems somewhat mnemonic and uses 'w' for
save (write) attachments.
---
 notmuch.el |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 0c6b527..f0e8d65 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -76,7 +76,8 @@
 (define-key map "r" 'notmuch-show-reply)
 (define-key map "s" 'notmuch-search)
 (define-key map "v" 'notmuch-show-view-all-mime-parts)
-(define-key map "w" 'notmuch-show-view-raw-message)
+(define-key map "V" 'notmuch-show-view-raw-message)
+(define-key map "w" 'notmuch-show-save-attachments)
 (define-key map "x" 'kill-this-buffer)
 (define-key map "+" 'notmuch-show-add-tag)
 (define-key map "-" 'notmuch-show-remove-tag)
-- 
1.6.5.3



[notmuch] [PATCH 8/9] Provide ability to save attachments

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

Previously the only way to save an attachment was to attempt to view
it and then save it from within the viewer program.
---
 notmuch.el |   41 +
 1 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index eaa5798..0c6b527 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -303,6 +303,47 @@ buffer."
   (with-current-notmuch-show-message
(mm-display-parts (mm-dissect-buffer

+(defun notmuch-foreach-mime-part (function mm-handle)
+  (cond ((stringp (car mm-handle))
+ (dolist (part (cdr mm-handle))
+   (notmuch-foreach-mime-part function part)))
+((bufferp (car mm-handle))
+ (funcall function mm-handle))
+(t (dolist (part mm-handle)
+ (notmuch-foreach-mime-part function part)
+
+(defun notmuch-count-attachments (mm-handle)
+  (let ((count 0))
+(notmuch-foreach-mime-part
+ (lambda (p)
+   (let ((disposition (mm-handle-disposition p)))
+ (and (listp disposition)
+  (equal (car disposition) "attachment")
+  (incf count
+ mm-handle)
+count))
+
+(defun notmuch-save-attachments (mm-handle  queryp)
+  (notmuch-foreach-mime-part
+   (lambda (p)
+ (let ((disposition (mm-handle-disposition p)))
+   (and (listp disposition)
+(equal (car disposition) "attachment")
+(or (not queryp)
+(y-or-n-p
+ (concat "Save '" (cdr (assq 'filename disposition)) "' ")))
+(mm-save-part p
+   mm-handle))
+
+(defun notmuch-show-save-attachments ()
+  "Save the attachments to a message"
+  (interactive)
+  (with-current-notmuch-show-message
+   (let ((mm-handle (mm-dissect-buffer)))
+ (notmuch-save-attachments
+  mm-handle (> (notmuch-count-attachments mm-handle) 1
+  (message "Done"))
+
 (defun notmuch-reply (query-string)
   (switch-to-buffer (generate-new-buffer "notmuch-draft"))
   (call-process notmuch-command nil t nil "reply" query-string)
-- 
1.6.5.3



[notmuch] [PATCH 7/9] Key bindings for message library based replies

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

---
 notmuch.el |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index fe20b54..eaa5798 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -64,6 +64,9 @@
 (define-key map "A" 'notmuch-show-mark-read-then-archive-thread)
 (define-key map "f" 'notmuch-show-forward-current)
 (define-key map "m" 'message-mail)
+(define-key map "MA" 'notmuch-show-wide-reply-current)
+(define-key map "MR" 'notmuch-show-reply-current)
+(define-key map "MF" 'notmuch-show-followup-current)
 (define-key map "n" 'notmuch-show-next-message)
 (define-key map "N" 'notmuch-show-mark-read-then-next-open-message)
 (define-key map "p" 'notmuch-show-previous-message)
-- 
1.6.5.3



[notmuch] [PATCH 6/9] Reply to individual messages using message library

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

As an alternative to creating a reply from the current thread, this
commit provides functions to create replies directly in emacs using
the message library.

A future commit will provide keybindings so that they are easy to
change if a different set is preferred.
---
 notmuch.el |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index d3d75f9..fe20b54 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -323,6 +323,21 @@ buffer."
   (with-current-notmuch-show-message
(message-forward)))

+(defun notmuch-show-reply-current ()
+  (interactive)
+  (with-current-notmuch-show-message
+   (message-reply)))
+
+(defun notmuch-show-wide-reply-current ()
+  (interactive)
+  (with-current-notmuch-show-message
+   (message-wide-reply)))
+
+(defun notmuch-show-followup-current ()
+  (interactive)
+  (with-current-notmuch-show-message
+   (message-followup)))
+
 (defun notmuch-show-pipe-message (command)
   "Pipe the contents of the current message to the given command.

-- 
1.6.5.3



[notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

The ability to temporarily create a buffer containing only the
contents of the currently selected message in notmuch show mode is
generally useful.  This commit factors the majority of the code
required to do so out of notmuch-show-view-all-mime-parts into a macro
called with-current-notmuch-show-message and rewrites the original
function in terms of the macro.

A future set of commits will provide additional functionality using
the macro as well.
---
 notmuch.el |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index cd6609d..a71a9f7 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -283,17 +283,21 @@ buffer."
   (interactive)
   (view-file (notmuch-show-get-filename)))

+(defmacro with-current-notmuch-show-message ( body)
+  "Evaluate body with current buffer set to the text of current message"
+  `(save-excursion
+ (let ((filename (notmuch-show-get-filename)))
+   (let ((buf (generate-new-buffer (concat "*notmuch-msg-" filename "*"
+ (with-current-buffer buf
+   (insert-file-contents filename nil nil nil t)
+   , at body)
+(kill-buffer buf)
+
 (defun notmuch-show-view-all-mime-parts ()
   "Use external viewers (according to mailcap) to view all MIME-encoded parts."
   (interactive)
-  (save-excursion
-(let ((filename (notmuch-show-get-filename)))
-  (switch-to-buffer (generate-new-buffer (concat "*notmuch-mime-"
-filename
-"*")))
-  (insert-file-contents filename nil nil nil t)
-  (mm-display-parts (mm-dissect-buffer))
-  (kill-this-buffer
+  (with-current-notmuch-show-message
+   (mm-display-parts (mm-dissect-buffer

 (defun notmuch-reply (query-string)
   (switch-to-buffer (generate-new-buffer "notmuch-draft"))
-- 
1.6.5.3



[notmuch] [PATCH 3/9] Add key binding for notmuch-search in show-mode

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

It's not uncommon to want to start a search as a result of something
read in a message so this is convenient.
---
 notmuch.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6400199..cd6609d 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -70,6 +70,7 @@
 (define-key map (kbd "C-p") 'notmuch-show-previous-line)
 (define-key map "q" 'kill-this-buffer)
 (define-key map "r" 'notmuch-show-reply)
+(define-key map "s" 'notmuch-search)
 (define-key map "v" 'notmuch-show-view-all-mime-parts)
 (define-key map "w" 'notmuch-show-view-raw-message)
 (define-key map "x" 'kill-this-buffer)
-- 
1.6.5.3



[notmuch] [PATCH 2/9] Adjust autoload comments

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

The previous location of autoload comments didn't seem to correspond
with the functions most likely to be the entry points for using
notmuch.  This change adjusts them to match those likely entry points.
---
 notmuch.el |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a1efa4f..6400199 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -707,8 +707,6 @@ view, (remove the \"inbox\" tag from each), with
mode-name "notmuch-show")
   (setq buffer-read-only t))

-;;;###autoload
-
 (defgroup notmuch nil
   "Notmuch mail reader for Emacs."
   :group 'mail)
@@ -1002,6 +1000,7 @@ This function advances point to the next line when 
finished."
  (set 'more nil))
   (delete-process proc

+;;;###autoload
 (defun notmuch-search (query  oldest-first)
   "Run \"notmuch search\" with the given query string and display results."
   (interactive "sNotmuch search: ")
@@ -1081,6 +1080,8 @@ current search results AND that are tagged with the given 
tag."
(list (notmuch-select-tag-with-completion "Filter by tag: ")))
   (notmuch-search (concat notmuch-search-query-string " and tag:" tag) 
notmuch-search-oldest-first))

+
+;;;###autoload
 (defun notmuch ()
   "Run notmuch to display all mail with tag of 'inbox'"
   (interactive)
@@ -1156,6 +1157,7 @@ results for the search terms in that line.
 (if search
(notmuch-search (cdr search) notmuch-search-oldest-first

+;;;###autoload
 (defun notmuch-folder ()
   "Show the notmuch folder view and update the displayed counts."
   (interactive)
-- 
1.6.5.3



[notmuch] [PATCH 1/9] Explicitly require the message library

2009-11-27 Thread cama...@picnicpark.org
From: Keith Amidon 

Functions provided by the message library were being used without
ensuring it was loaded.
---
 notmuch.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index d7c973c..a1efa4f 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -49,6 +49,7 @@

 (require 'cl)
 (require 'mm-view)
+(require 'message)

 (defvar notmuch-show-mode-map
   (let ((map (make-sparse-keymap)))
-- 
1.6.5.3



[notmuch] Show mode enhancements

2009-11-27 Thread cama...@picnicpark.org
I started using notmuch a few days ago and was astounded at how much
more efficiently I could process email with it. For my usage I needed
a bit more flexibility in replying/forwarding messages and the ability
to conveniently save attachments.  The set of patches that follow
contain these two enhancements, a few minor fixes, and the addition of
a binding of 's' in show mode to notmuch-search.

I'd be happy to address anything neded to get these changes into shape
to be included in the main distribution.  Thanks for all your work
putting together such a promising email client.

   --- Keith



[notmuch] [PATCH] notmuch-count: make sure all created items are freed, even in error paths

2009-11-27 Thread Carl Worth
On Tue, 24 Nov 2009 16:22:02 +0200, Dirk-Jan C. Binnema  wrote:
> 
> Another minor patch, fixing a couple of resource leaks in error paths.

Thanks, Dirk-Jan, but we don't actually need this kind of care in some
cases, because these aren't leaks in a permanent sense since they are
talloc-based. Instead these "leaks" simply mean that on the error paths
these objects will live slightly longer than normal, until the caller
frees the talloc context.

And I'm perfectly happy to have slightly longer-lived objects in the
error paths, (while still guaranteeing leak-free behavior in all
cases). And I definitely like the easier-to-read-and-verify code that
comes with the early return values.

Now, we do have to be careful if there are side effects from having an
object live longer, (such as holding a database write lock or
something). So if there's a fix for something like that in an error
path, then yes, we'll definitely want that.

-Carl


[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer

2009-11-27 Thread Carl Worth
On Tue, 24 Nov 2009 09:02:46 +0100, Tassilo Horn  
wrote:
> I'm a Gnus user and use notmuch mostly for searching.  When I want to
> reply to a message, I need to get back to Gnus, so that my Gnus posting
> styles (gcc into that group, right email address, correct signature,...)
> are applied.

Oh, good. I've been hoping to be able to get some advice from gnus
users. I want to figure out how to get gnus support for viewing
encrypted messages, etc.

Do you happen to know some good documentation for how to get started
with gnus for reading mail? I'd be happy even with the bare minimum to
just get gnus to view one single message from out of my mail
store. (Which is something I tried to figure out from the gnus manual,
but I neve succeeded.)

> Therefore, I created this small snippet.  Now C-c C-c inside some
> message in the *notmuch-show* buffer opens this article in a Gnus
> *Summary* buffer, where I can reply to it, forward it, ...
> 
> Of course, the translation from file name to Gnus group name is
> something that is different for any user.  The essence of this code is
> the call to the org-gnus.el function `org-gnus-follow-link', which takes
> the group name and the message-id.  It's included in Emacsen >= 23.
> 
> --8<---cut here---start->8---
> (require 'notmuch)
> 
> (defun th-notmuch-file-to-group (file)
>   "Calculate the Gnus group name from the given file name.
> 
> Example:
> 
>   IN: /home/horn/Mail/Dovecot/uni/INBOX/dbox-Mails/u.4075
>   OUT: nnimap+Uni:INBOX"
>   (concat "nnimap+"
>   (replace-regexp-in-string 
>"^\\([^/]+\\)/" "\\1:"
>(replace-regexp-in-string 
> "/dbox-Mails/.*" ""
> (replace-regexp-in-string
>  "/home/horn/Mail/Dovecot/" "" file)
> 
> (defun th-notmuch-goto-message-in-gnus ()
>   "Open a summary buffer containing the current notmuch
> article."
>   (interactive)
>   (let ((group (th-notmuch-file-to-group (notmuch-show-get-filename)))
> (message-id (replace-regexp-in-string
>  "^id:" "" (notmuch-show-get-message-id
> (message "G: %s, mid: %s" group message-id)
> (if (and group message-id)
> (org-gnus-follow-link group message-id)
>   (message "Couldn't get relevant infos for switching to Gnus."
> 
> (define-key notmuch-show-mode-map (kbd "C-c C-c") 
> 'th-notmuch-goto-message-in-gnus)
> --8<---cut here---end--->8---
> 
> BTW, why does `notmuch-show-get-message-id' prefix the message-id with
> "id:"?
> 
> Bye,
> Tassilo
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
> 


[notmuch] _notmuch_message_create_for_message_id makes extra call to notmuch_database_find_message

2009-11-27 Thread Carl Worth
On Mon, 23 Nov 2009 12:29:44 -0800, Keith Packard  wrote:
> 
> Looking at _notmuch_message_create_for_message_id, the first thing it
> does is call notmuch_database_find_message, but the returned 'message'
> is never used. I haven't tried, but I suspect this call could just be
> removed.

Did the "if" statement immediately afterwards just look like error
checking? It's not:

message = notmuch_database_find_message (notmuch, message_id);
if (message)
return talloc_steal (notmuch, message);

That's "if there's a message is in the database with this message-id,
return it straight away".

Or am I looking at the wrong bit of code?

-Carl


[notmuch] [PATCH] Handle message renames in mail spool

2009-11-27 Thread Mikhail Gusarov
In order to handle message renames the following changes were deemed necessary:

* Mtime check on individual files was disabled. As files may be moved around
without changing their mtime, it's necessary to parse them even if they appear
old in case old message was moved. mtime check on directories was kept as moving
files changes mtime of directory.

* If message being parsed is already found in database under different path,
then this message is considered to be moved, path is updated in database and
this file does not undergo further processing.

Note that after applying this patch notmuch still does not handle copying files
(which is harmless, database will point to the last copy of message found during
'notmuch new') and deleting files (which is more serious, as dangling entries
will show up in searches).

Signed-off-by: Mikhail Gusarov 
---
 lib/database.cc |   32 +--
 notmuch-new.c   |   92 ++
 2 files changed, 66 insertions(+), 58 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index 2c90019..257c0b8 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -990,19 +990,31 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
if (private_status == NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND) {
_notmuch_message_set_filename (message, filename);
_notmuch_message_add_term (message, "type", "mail");
-   } else {
-   ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
-   goto DONE;
-   }

-   ret = _notmuch_database_link_message (notmuch, message, message_file);
-   if (ret)
-   goto DONE;
+   ret = _notmuch_database_link_message (notmuch, message, 
message_file);
+   if (ret)
+   goto DONE;

-   date = notmuch_message_file_get_header (message_file, "date");
-   _notmuch_message_set_date (message, date);
+   date = notmuch_message_file_get_header (message_file, "date");
+   _notmuch_message_set_date (message, date);

-   _notmuch_message_index_file (message, filename);
+   _notmuch_message_index_file (message, filename);
+   } else {
+   const char *old_filename = notmuch_message_get_filename (message);
+   if (strcmp (old_filename, filename) == 0) {
+   /* We have already seen it */
+   goto DONE;
+   } else {
+   if (access (old_filename, R_OK) == 0) {
+   /* old_filename still exists, we've got a duplicate */
+   ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
+   goto DONE;
+   } else {
+   /* Message file has been moved/renamed */
+   _notmuch_message_set_filename (message, filename);
+   }
+   }
+   }

_notmuch_message_sync (message);
 } catch (const Xapian::Error ) {
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..d16679c 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -174,54 +174,50 @@ add_files_recursive (notmuch_database_t *notmuch,
}

if (S_ISREG (st->st_mode)) {
-   /* If the file hasn't been modified since the last
-* add_files, then we need not look at it. */
-   if (path_dbtime == 0 || st->st_mtime > path_dbtime) {
-   state->processed_files++;
-
-   status = notmuch_database_add_message (notmuch, next, );
-   switch (status) {
-   /* success */
-   case NOTMUCH_STATUS_SUCCESS:
-   state->added_messages++;
-   tag_inbox_and_unread (message);
-   break;
-   /* Non-fatal issues (go on to next file) */
-   case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
-   /* Stay silent on this one. */
-   break;
-   case NOTMUCH_STATUS_FILE_NOT_EMAIL:
-   fprintf (stderr, "Note: Ignoring non-mail file: %s\n",
-next);
-   break;
-   /* Fatal issues. Don't process anymore. */
-   case NOTMUCH_STATUS_READONLY_DATABASE:
-   case NOTMUCH_STATUS_XAPIAN_EXCEPTION:
-   case NOTMUCH_STATUS_OUT_OF_MEMORY:
-   fprintf (stderr, "Error: %s. Halting processing.\n",
-notmuch_status_to_string (status));
-   ret = status;
-   goto DONE;
-   default:
-   case NOTMUCH_STATUS_FILE_ERROR:
-   case NOTMUCH_STATUS_NULL_POINTER:
-   case NOTMUCH_STATUS_TAG_TOO_LONG:
-   case NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW:
-   case NOTMUCH_STATUS_LAST_STATUS:
-   INTERNAL_ERROR ("add_message returned unexpected value: 
%d",  status);
-

[notmuch] [PATCH -v5] notmuch.el: Use message-mode font-face to highlight mail headers

2009-11-27 Thread Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
 notmuch.el |   35 +--
 1 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 89ccef6..851c60c 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -595,6 +595,38 @@ which this thread was originally shown.
   (set-marker beg nil)
   (set-marker end nil)
   )))
+(defun notmuch-fontify-headers ()
+  (progn
+(if (looking-at [Tt]o:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-to)))
+(beginning-of-line)
+(if (looking-at [B]?[Cc][Cc]:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-cc)))
+(beginning-of-line)
+(if (looking-at [Ss]ubject:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-subject)))
+(beginning-of-line)
+(if (looking-at [Ff]rom:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-other)))
+(beginning-of-line)
+
+))
 
 (defun notmuch-show-markup-header (depth)
   (re-search-forward notmuch-show-header-begin-regexp)
@@ -615,8 +647,7 @@ which this thread was originally shown.
 (forward-line)
 (while (looking-at [A-Za-z][-A-Za-z0-9]*:)
   (beginning-of-line)
-  (overlay-put (make-overlay (point) (re-search-forward :))
-   'face 'bold)
+ (notmuch-fontify-headers)
   (forward-line)
   )
(indent-rigidly beg end depth)
-- 
1.6.5.2.74.g610f9

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


[notmuch] [PATCH -v6] notmuch.el: Use message-mode font-face to highlight mail headers

2009-11-27 Thread Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
 notmuch.el |   29 +++--
 1 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index d2ebb40..b089732 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -604,6 +604,32 @@ which this thread was originally shown.
   (set-marker beg nil)
   (set-marker end nil)
   )))
+(defun notmuch-fontify-headers ()
+  (progn
+(if (looking-at [Tt]o:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-to))
+(if (looking-at [B]?[Cc][Cc]:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-cc))
+(if (looking-at [Ss]ubject:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-subject))
+(if (looking-at [Ff]rom:)
+   (progn
+ (overlay-put (make-overlay (point) (re-search-forward :))
+   'face 'message-header-name)
+  (overlay-put (make-overlay (point) (re-search-forward .*$))
+   'face 'message-header-other
 
 (defun notmuch-show-markup-header (depth)
   (re-search-forward notmuch-show-header-begin-regexp)
@@ -624,8 +650,7 @@ which this thread was originally shown.
 (forward-line)
 (while (looking-at [A-Za-z][-A-Za-z0-9]*:)
   (beginning-of-line)
-  (overlay-put (make-overlay (point) (re-search-forward :))
-   'face 'bold)
+ (notmuch-fontify-headers)
   (forward-line)
   )
(indent-rigidly beg end depth)
-- 
1.6.5.2.74.g610f9

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


Re: [notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-27 Thread Jan Janak
On 26-11 22:53, Ingmar Vanhassel wrote:
 Excerpts from Michiel Buddingh''s message of Thu Nov 26 22:12:02 +0100 2009:
  Haven't tested it, but it seems you can put
  
  [core]
  whitespace = trailing-space,space-before-tab
  
  into your ~/.gitconfig now.  I've also set emacs to mark trailing
  whitespace with big red markers.
 
 I think it should be in notmuch/.gitattributes, which doesn't relies on
 new contributors to set that up. It also doesn't force this on for every
 git repo one has.

This enforces the restrictions also on people's local commits, even those they
may never want to submit for inclusion into the official repository.

Asking people to follow certain rules when submitting patches for inclusion is
sensible, but I don't think notmuch should enforce this on all local commits
with notmuch/.gitattributes.

  -- Jan

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


Re: [notmuch] _notmuch_message_create_for_message_id makes extra call to notmuch_database_find_message

2009-11-27 Thread Carl Worth
On Mon, 23 Nov 2009 12:29:44 -0800, Keith Packard kei...@keithp.com wrote:
 
 Looking at _notmuch_message_create_for_message_id, the first thing it
 does is call notmuch_database_find_message, but the returned 'message'
 is never used. I haven't tried, but I suspect this call could just be
 removed.

Did the if statement immediately afterwards just look like error
checking? It's not:

message = notmuch_database_find_message (notmuch, message_id);
if (message)
return talloc_steal (notmuch, message);

That's if there's a message is in the database with this message-id,
return it straight away.

Or am I looking at the wrong bit of code?

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


Re: [notmuch] [PATCH] notmuch-new: Eliminate tallocs whilst construct filenames.

2009-11-27 Thread Carl Worth
On Sun, 22 Nov 2009 00:57:10 +, Chris Wilson ch...@chris-wilson.co.uk 
wrote:
 The majority of filenames will fit within PATH_MAX [4096] (because
 that's a hard limit imposed by the filesystems) so we can avoid an
 allocation per lookup and thereby eliminate a large proportion of the
 overhead of scanning a maildir.

Hi Chris,

I *know* I composed a reply to this message earlier, but apparently
you're right that it never went out. (*sigh*---if only I had a reliable
mail client[*]).

  [*] I tried and tried to figure out how to get gnus to save an Fcc (a
  file copy of all outgoing messages), and failed to configure the
  various fake newsgroup things that gnus wanted for me to be able
  to do this. I also failed to get message-mode to do an Fcc. I
  settled instead for a Bcc to myself on all messages, deciding that
  it would be nice to see that mail actually went *out* and not just
  that I thought I sent it. Maybe that failed here, I don't know.

  The other piece I want is for unsent mail drafts to automatically
  be saved, and for notmuch to prompt me to continue with a draft if
  I start composing a new message while a draft is
  around. Currently, I can save a draft while composing in
  message-mode with C-x C-s but the big bug here is that the
  drafts never get deleted when I send the message, so I can't tell
  unfinished drafts apart from completed-and-sent messages.

Anyway, on to the promised review of the patch:

The basic idea of this I really like, of course. Thanks for helping to
improve the efficiency of notmuch. But this part I don't:

 - continue;
 - }
 -
 - if (S_ISREG (st-st_mode)) {
 - /* If the file hasn't been modified since the last
 -  * add_files, then we need not look at it. */
 - if (path_dbtime == 0 || st-st_mtime  path_dbtime) {
 - state-processed_files++;
 -
 - status = notmuch_database_add_message (notmuch, next, message);
 - switch (status) {
 - /* success */
 + } else {

It's true that in a former life, one of your primary jobs was to clean
up after me, especially cleaning up things like memory leaks on error
paths. But in my new talloc-enabled world, I'm quite happy to keep
cleaner, easier-to-understand code for the price of just having a
talloced object live slightly longer on an error path.

We do still have to be careful that we don't let such object accumulate
without bounds in some error case, and that they don't lock up important
resources. But when it's just a matter of a dozen bytes or so, talloced
into the parent's context which is going to be freed in the error path
above, then I'm much happier to allow for this transient leak rather
than convoluting the code with more cleanup gotos.

One might argue that the error-cleanup goto is a common and
well-understood idiom, so that it's not bad to have. The problem I have
with it is how much work it is to verify. If I'm reading one line of
code in the middle of a function that's testing for an error case and
handling it with goto, then I need to:

1. Verify this condition, and that a return value variable gets
   set.

2. Check down at the end of the function to ensure the correct
   objects are freed and the correct return value is returned.

3. Check back up at the beginning of the function to ensure the
   relevant objects are initialized to NULL.

And beyond verification, one has to code in these three places
simultaneously as well.

Meanwhile, by taking advantage of talloc like I did in the original
version of this code, an error return becomes a much more local decision
and is much simpler to code.

Chris, I'd be interested to hear any thoughts you have on this pattern.

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


[notmuch] [PATCH 1/9] Explicitly require the message library

2009-11-27 Thread camalot
From: Keith Amidon ke...@nicira.com

Functions provided by the message library were being used without
ensuring it was loaded.
---
 notmuch.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index d7c973c..a1efa4f 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -49,6 +49,7 @@
 
 (require 'cl)
 (require 'mm-view)
+(require 'message)
 
 (defvar notmuch-show-mode-map
   (let ((map (make-sparse-keymap)))
-- 
1.6.5.3

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


[notmuch] [PATCH 2/9] Adjust autoload comments

2009-11-27 Thread camalot
From: Keith Amidon ke...@nicira.com

The previous location of autoload comments didn't seem to correspond
with the functions most likely to be the entry points for using
notmuch.  This change adjusts them to match those likely entry points.
---
 notmuch.el |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a1efa4f..6400199 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -707,8 +707,6 @@ view, (remove the \inbox\ tag from each), with
mode-name notmuch-show)
   (setq buffer-read-only t))
 
-;;;###autoload
-
 (defgroup notmuch nil
   Notmuch mail reader for Emacs.
   :group 'mail)
@@ -1002,6 +1000,7 @@ This function advances point to the next line when 
finished.
  (set 'more nil))
   (delete-process proc
 
+;;;###autoload
 (defun notmuch-search (query optional oldest-first)
   Run \notmuch search\ with the given query string and display results.
   (interactive sNotmuch search: )
@@ -1081,6 +1080,8 @@ current search results AND that are tagged with the given 
tag.
(list (notmuch-select-tag-with-completion Filter by tag: )))
   (notmuch-search (concat notmuch-search-query-string  and tag: tag) 
notmuch-search-oldest-first))
 
+
+;;;###autoload
 (defun notmuch ()
   Run notmuch to display all mail with tag of 'inbox'
   (interactive)
@@ -1156,6 +1157,7 @@ results for the search terms in that line.
 (if search
(notmuch-search (cdr search) notmuch-search-oldest-first
 
+;;;###autoload
 (defun notmuch-folder ()
   Show the notmuch folder view and update the displayed counts.
   (interactive)
-- 
1.6.5.3

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


[notmuch] [PATCH 3/9] Add key binding for notmuch-search in show-mode

2009-11-27 Thread camalot
From: Keith Amidon ke...@nicira.com

It's not uncommon to want to start a search as a result of something
read in a message so this is convenient.
---
 notmuch.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6400199..cd6609d 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -70,6 +70,7 @@
 (define-key map (kbd C-p) 'notmuch-show-previous-line)
 (define-key map q 'kill-this-buffer)
 (define-key map r 'notmuch-show-reply)
+(define-key map s 'notmuch-search)
 (define-key map v 'notmuch-show-view-all-mime-parts)
 (define-key map w 'notmuch-show-view-raw-message)
 (define-key map x 'kill-this-buffer)
-- 
1.6.5.3

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


[notmuch] [PATCH 9/9] Key binding rearrangement for save attachments in show mode

2009-11-27 Thread camalot
From: Keith Amidon ke...@nicira.com

The most obvious bindings for save attachments are already taken.  The
existing 'w' binding was bound to view the raw message.  This commit
moves it to 'V' which still seems somewhat mnemonic and uses 'w' for
save (write) attachments.
---
 notmuch.el |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 0c6b527..f0e8d65 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -76,7 +76,8 @@
 (define-key map r 'notmuch-show-reply)
 (define-key map s 'notmuch-search)
 (define-key map v 'notmuch-show-view-all-mime-parts)
-(define-key map w 'notmuch-show-view-raw-message)
+(define-key map V 'notmuch-show-view-raw-message)
+(define-key map w 'notmuch-show-save-attachments)
 (define-key map x 'kill-this-buffer)
 (define-key map + 'notmuch-show-add-tag)
 (define-key map - 'notmuch-show-remove-tag)
-- 
1.6.5.3

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


Re: [notmuch] [PATCH 1/2] New function notmuch-search-operate-all: operate on all messages in the current query.

2009-11-27 Thread Carl Worth
On Thu, 26 Nov 2009 22:36:49 +0100, Jed Brown j...@59a2.org wrote:
 It is often convenient to change tags on several messages at once.  This
 function applies any number of tag whitespace-delimited tag
 modifications to all messages matching the current query.

Thanks Jed,

I've applied both this and the following patch, (giving the consistent
treatment to '+, '-', and 'a'). One or two minor comments:

 +  +tagname  Add the tag `tagname'
 +  -tagname  Remove the tag `tagname'
 +
 +Each character of the tag name may consist of alphanumeric
 +characters as well as `_.+-'.

Since this operates via a single call to notmuch tag you might mention
here that all tag removals occur before any tag additions.

 + (unless (string-match-p ^[\+\-][_\+\-\\w]+$ (car words))
 +   (error Action must be of the form `+thistag -that_tag'))

The error message has inconsistent thistag and that_tag.

But niether nit was worth blocking the commit on.

Thanks again,

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


  1   2   >