Re: [notmuch] semi-usable notmuch-gtk client

[Baruch Even]

Bart Trojanowski wrote:

* 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?


I created them now at http://baruch.github.com/notmuch-gtk

They are not pretty and not meant to be, I'm currently just tracing out 
the client to get it somewhat functional as a mail client. The niceties 
will come once I actually get to use it as properly.


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

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

[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.

[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.

[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

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[Jeffrey Ollie]

On Sat, Nov 28, 2009 at 12:43 AM, Carl Worth  wrote:
>
> Have you actually *looked* at the implementation of libsha1.c that we
> have in notmuch? I can't say with 100% certainty that it's free of any
> buffer overruns, but I can see that it's not doing any memory allocation
> nor network communication. So there are entire classes of security
> problems, (such as have afflicted libraries in your examples), that just
> aren't present here.

I've looked at the code, if only briefly.  But you're wrong that the
code doesn't do any "network communication" - we feed libsha1 hostile
data every time we take the hash of a message.

> And as for security compromises due to a bug in the cryptographic nature
> of this function---well, notmuch isn't even *using* SHA-1 for any secure
> purpose.

>From a distributor's point of view, it doesn't matter what you use the
code for, it only matters that it has the bug and someone has to spend
the time to track down all of the copies of the code and replace the
code with a fixed version.  If the code is confined to one shared
library it's trivial to update the shared library, if the code has
been copied to N packages, it's at least N times the work to verify
that all of those packages get updated.

> The actual functionality that we need here is *so* small that I am
> unwilling to introduce a required dependency on any library as large as
> libcrypt. I mean, look at the actual sizes we're talking about

If libgcrypt were some obscure library that wasn't already packaged up
by your favorite distribution or took up hundreds of megabytes of RAM
and/or disk you might have a point.  But the fact is that it *doesn't
matter* how big libgcrypt is because we essentially get it for free -
I'd bet that libgcrypt is already installed on most people's systems.
As a test I tried to remove libgcrypt from my laptop - if I actually
had gone though with it I would have crippled my system because things
like the X server and the package manager depend (albeit indirectly)
on it.

> Now, if somebody wanted to maintain libsha1 inside a distribution like
> Debian, say, then I'd be happy to link against that version rather than
> a locally compiled version. And like I said earlier, if people would
> rather link against a large cyptographic library for this one tiny
> function, then we could arrange that too, but I don't think that
> justifies dropping this code from notmuch and introducing a hard
> dependency.

Given Debian's reputation for packaging the kitchen sink I'm surprised
that it doesn't already.  Fedora tends not to package libraries unless
there is an application that is going to make use of it...

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

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

[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

[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

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

[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


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

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

[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>

Re: [notmuch] [PATCH] Send mail to notmuch list, not Carl

[Carl Worth]

On Sat, 28 Nov 2009 00:07:54 -0600, Alec Berryman  wrote:
>  those of the notmuch developers. Then, please email those details to
> -Carl Worth  so that we can hopefully make future
> -versions of notmuch easier for you to use.
> +the Notmuch list (notmuch@notmuchmail.org) so that we can hopefully make
> +future versions of notmuch easier for you to use.

Thanks. I've pushed this out now.

-Carl


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

[notmuch] [PATCH] Send mail to notmuch list, not Carl

[Carl Worth]

On Sat, 28 Nov 2009 00:07:54 -0600, Alec Berryman  wrote:
>  those of the notmuch developers. Then, please email those details to
> -Carl Worth  so that we can hopefully make future
> -versions of notmuch easier for you to use.
> +the Notmuch list (notmuch at notmuchmail.org) so that we can hopefully make
> +future versions of notmuch easier for you to use.

Thanks. I've pushed this out 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/ebf07d90/attachment.pgp>

Re: [notmuch] Problems importing my mail...

[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


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

[notmuch] Problems importing my mail...

[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>

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[Carl Worth]

On Fri, 27 Nov 2009 23:41:40 -0600, Jeffrey Ollie  wrote:
> 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.

Hi Jeffrey,

Have you actually *looked* at the implementation of libsha1.c that we
have in notmuch? I can't say with 100% certainty that it's free of any
buffer overruns, but I can see that it's not doing any memory allocation
nor network communication. So there are entire classes of security
problems, (such as have afflicted libraries in your examples), that just
aren't present here.

And as for security compromises due to a bug in the cryptographic nature
of this function---well, notmuch isn't even *using* SHA-1 for any secure
purpose.

The actual functionality that we need here is *so* small that I am
unwilling to introduce a required dependency on any library as large as
libcrypt. I mean, look at the actual sizes we're talking about

$ size lib/notmuch.a
   textdata bss dec hex filename
   6774   0   067741a76 libsha1.o (ex lib/notmuch.a)
   2372   0   42376 948 message-file.o (ex lib/notmuch.a)
756   0   0 756 2f4 messages.o (ex lib/notmuch.a)
405   0   0 405 195 sha1.o (ex lib/notmuch.a)
406   0   0 406 196 tags.o (ex lib/notmuch.a)
842   0   0 842 34a xutil.o (ex lib/notmuch.a)
  15834 100   1   159353e3f database.o (ex lib/notmuch.a)
   2826   0   42830 b0e index.o (ex lib/notmuch.a)
  11834   0   4   118382e3e message.o (ex lib/notmuch.a)
   7042   0   070421b82 query.o (ex lib/notmuch.a)
   2553   0   02553 9f9 thread.o (ex lib/notmuch.a)

$ size /usr/lib/libgcrypt.so.11.5.2 
   textdata bss dec hex filename
 4662368424 748  475408   74110 /usr/lib/libgcrypt.so.11.5.2

You can see that libgcrypt is 7 times the size of all of libnotmuch.a
combined.

Now, if somebody wanted to maintain libsha1 inside a distribution like
Debian, say, then I'd be happy to link against that version rather than
a locally compiled version. And like I said earlier, if people would
rather link against a large cyptographic library for this one tiny
function, then we could arrange that too, but I don't think that
justifies dropping this code from notmuch and introducing a hard
dependency.

-Carl


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

[notmuch] [PATCH] Use libgcrypt for hashing.

[Carl Worth]

On Fri, 27 Nov 2009 23:41:40 -0600, Jeffrey Ollie  wrote:
> 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.

Hi Jeffrey,

Have you actually *looked* at the implementation of libsha1.c that we
have in notmuch? I can't say with 100% certainty that it's free of any
buffer overruns, but I can see that it's not doing any memory allocation
nor network communication. So there are entire classes of security
problems, (such as have afflicted libraries in your examples), that just
aren't present here.

And as for security compromises due to a bug in the cryptographic nature
of this function---well, notmuch isn't even *using* SHA-1 for any secure
purpose.

The actual functionality that we need here is *so* small that I am
unwilling to introduce a required dependency on any library as large as
libcrypt. I mean, look at the actual sizes we're talking about

$ size lib/notmuch.a
   textdata bss dec hex filename
   6774   0   067741a76 libsha1.o (ex lib/notmuch.a)
   2372   0   42376 948 message-file.o (ex lib/notmuch.a)
756   0   0 756 2f4 messages.o (ex lib/notmuch.a)
405   0   0 405 195 sha1.o (ex lib/notmuch.a)
406   0   0 406 196 tags.o (ex lib/notmuch.a)
842   0   0 842 34a xutil.o (ex lib/notmuch.a)
  15834 100   1   159353e3f database.o (ex lib/notmuch.a)
   2826   0   42830 b0e index.o (ex lib/notmuch.a)
  11834   0   4   118382e3e message.o (ex lib/notmuch.a)
   7042   0   070421b82 query.o (ex lib/notmuch.a)
   2553   0   02553 9f9 thread.o (ex lib/notmuch.a)

$ size /usr/lib/libgcrypt.so.11.5.2 
   textdata bss dec hex filename
 4662368424 748  475408   74110 /usr/lib/libgcrypt.so.11.5.2

You can see that libgcrypt is 7 times the size of all of libnotmuch.a
combined.

Now, if somebody wanted to maintain libsha1 inside a distribution like
Debian, say, then I'd be happy to link against that version rather than
a locally compiled version. And like I said earlier, if people would
rather link against a large cyptographic library for this one tiny
function, then we could arrange that too, but I don't think that
justifies dropping this code from notmuch and introducing a hard
dependency.

-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/489b6277/attachment.pgp>

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[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



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

[notmuch] [PATCH] Use libgcrypt for hashing.

[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>

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[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


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

[notmuch] [PATCH] Use libgcrypt for hashing.

[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>

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

[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


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

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

[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

[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

[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

Re: [notmuch] Problems importing my mail...

[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).
> [j...@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


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

[notmuch] Problems importing my mail...

[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] Send mail to notmuch list, not Carl

[Alec Berryman]

---
 configure |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index b4770ec..e55f067 100755
--- a/configure
+++ b/configure
@@ -10,8 +10,8 @@ more efficiently than ever.
 If anything goes wrong in this process, please do as much as you can
 to figure out what could be different on your machine compared to
 those of the notmuch developers. Then, please email those details to
-Carl Worth  so that we can hopefully make future
-versions of notmuch easier for you to use.
+the Notmuch list (notmuch@notmuchmail.org) so that we can hopefully make
+future versions of notmuch easier for you to use.
 
 We'll now investigate your system to find verify that various software
 components that notmuch relies on are available.
-- 
1.6.5


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

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

[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 |   30 +-
 1 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index e9786c0..5cbfedf 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -846,6 +846,23 @@ 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)
+  (background dark))
+ (:foreground "OliveDrab1"))
+(((class color)
+  (background light))
+ (:foreground "navy blue" :bold t))
+(t
+ (:bold t)))
+  "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.
@@ -876,7 +893,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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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


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

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

[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>

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

[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


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

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

[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>

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Use libgcrypt for hashing.

[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

[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

[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

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

[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


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

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

[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>

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[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 j...@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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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


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

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

[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>

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

[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


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

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

[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

[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

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

[Carl Worth]

On Fri, 27 Nov 2009 05:30:15 -0800, cama...@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


pgpWYJy0wiyuF.pgp
Description: PGP signature
___
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

[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>

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

[Carl Worth]

On Fri, 27 Nov 2009 05:30:14 -0800, cama...@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


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

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

[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.

[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

[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

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

[Alexander Botero-Lowry]

On Fri, 27 Nov 2009 21:10:42 -0800, Carl Worth  wrote:
> On Fri, 27 Nov 2009 05:30:10 -0800, cama...@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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[Carl Worth]

On Fri, 27 Nov 2009 05:30:12 -0800, cama...@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


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

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

[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

[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

[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 **) &hashed_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

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

[Carl Worth]

On Fri, 27 Nov 2009 05:30:11 -0800, cama...@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


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

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

[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>

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

[Carl Worth]

On Fri, 27 Nov 2009 05:30:10 -0800, cama...@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


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

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

[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>

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

[Carl Worth]

On Fri, 27 Nov 2009 05:30:08 -0800, cama...@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


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

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

[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>

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

[Carl Worth]

On Fri, 27 Nov 2009 05:30:07 -0800, cama...@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


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

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

[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>

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

[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


pgpdtPKxRuzmz.pgp
Description: PGP signature
___
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

[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>

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

[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


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

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

[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>

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

[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


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

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

[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>

Re: [notmuch] Show mode enhancements

[Carl Worth]

On Fri, 27 Nov 2009 05:30:06 -0800, cama...@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



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

[notmuch] Show mode enhancements

[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>

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

[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


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

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

[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>

Re: [notmuch] OpenPGP support

[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


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

[notmuch] OpenPGP support

[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>

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

[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@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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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---

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[Ingmar Vanhassel]

Excerpts from Mikhail Gusarov's message of Sat Nov 28 04:31:15 +0100 2009:
> 
> Twas brillig at 21:28:03 27.11.2009 UTC-06 when j...@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.

>From a distribution & security point of view I'd much rather be able to
choose one hashing library & use that as widely as possible, rather than
having every application ship its own copy.

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

Right, but on top of that, it would still be preferable to keep the
option for packagers to use a system library instead.
Most distributions have a rather strict policy to use system libraries
over internal copies.

-- 
Exherbo KDE, X.org maintainer
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] semi-usable notmuch-gtk client

[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

Re: [notmuch] notmuch_threads_back and notmuch_messages_back

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] notmuch_threads_back and notmuch_messages_back

[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

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

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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

Re: [notmuch] Gmane

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Gmane

[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

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

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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

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

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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

Re: [notmuch] [PATCH] Use libgcrypt for hashing.

[Mikhail Gusarov]

Twas brillig at 21:28:03 27.11.2009 UTC-06 when j...@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.

 JCO> This means less code of our own to maintain and

As libsha1 maintainer I'm volunteering to maintain in-tree copy in
notmuch :)

-- 
  http://fossarchy.blogspot.com/


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

[notmuch] [PATCH] Use libgcrypt for hashing.

[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[((

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

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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

Re: [notmuch] semi-usable notmuch-gtk client

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Problems importing my mail...

[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

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

[Mikhail Gusarov]

Twas brillig at 18:55:28 27.11.2009 UTC-08 when cwo...@cworth.org did gyre and 
gimble:

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

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

I imagine hook that counts the number of sentences and inserts proper
signature :)

-- 
  http://fossarchy.blogspot.com/


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

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

[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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[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