Our use of GMimeSession was unneeded boilerplate, and we weren't doing
anything with it. This simplifies and clarifies that assumption.
If we want to do anything fancier later, the examples in the gmime
source are a reasonable source to work from in defining a new
GMimeSession derivative.
Since
This patch supercedes my patch from
1307142188-6551-1-git-send-email-dkg at fifthhorseman.net , and provides
what appears to be a much cleaner approach to achieve the same result.
--dkg
me: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/e67b8379/attachment.pgp>
The notmuch binary is not in the business of doing interactive
prompting with the user. If credentials are needed for decryption,
they should be supplied to the decrypting processes some other way
(e.g. gpg-agent).
Previously, we returned a NULL function pointer for the
request_passwd()
On Tue, 31 May 2011 11:43:31 -0700, Jameson Graef Rollins wrote:
> Hi, folks. I have pushed a new version of the release-candidate/0.6
> branch to my repo [0]. It is all reworked on top of notmuch/master [1],
> and includes:
...
> cworth: do you want to review this for the new release? We're
n-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/323082b2/attachment.pgp>
it a memory leak? (If it's not a leak, then
GMime really has some bizarre ownership semantics.)
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/piperma
vailable
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/ee1f143f/attachment-0001.pgp>
t part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/eccc812f/attachment.pgp>
n-text attachment was scrubbed...
Name: 0001-emacs-User-defined-sections-in-notmuch-hello.patch
Type: text/x-diff
Size: 20109 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/983b296b/attachment-0002.patch>
-- next part -
uite
to expose this bug).
Edited-by: Carl Worth with a new commit message to
explain the bug and fix.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<
ure
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/4e3aeb2f/attachment.pgp>
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/4dd4149a/attachment.pgp>
has already grabbed it.
I really wouldn't block on this, though, since the patch does fix an
actual bug.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.
ext part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/89821ae3/attachment-0001.pgp>
tion/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/4137e868/attachment.pgp>
pointers to information like "old style" or "new style".
Does that make sense?
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/f4538682/attachment.pgp>
tes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/48e88dcd/attachment.pgp>
anks for your patience if I seem off
my rocker).
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/97f8f7e7/attachment.pgp>
This was a minor oversite in checking of part type when outputing
content raw. This was causing gmime was to throw an exception to
stderr.
Unfortunately the gmime exception was not being caught by notmuch, or
the test suite. I'm not sure if notmuch should have done anything in
this case, but
On Sat, 28 May 2011 14:51:52 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
+if (NULL == str)
+ return NULL;
I haven't been blocking patches because of this, but can I please ask
everyone to not use the above style?
I understand that the above style is intended to
On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
The declaration of the GMimeStream pointer to stdout in
format_part_content_text was somehow preventing subsequent printf
calls from outputting to stdout if the output was redirected to a
file.
On Fri, 03 Jun 2011 13:05:00 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/signed
On Thu, 02 Jun 2011 10:49:57 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
Well, it says that changes are in notmuch 0.5. So old and previous
refer to pre-0.5 (i.e. 0.4) and
On Sat, 04 Jun 2011 00:22:04 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
notmuch was incorecctly detecting this as the ... is not right.
Thanks. I was sure my commit message wasn't right yet. That was my
point---I didn't know what the right message would be! ;-)
It is a
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth cwo...@cworth.org wrote:
On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
The declaration of the GMimeStream pointer to stdout in
format_part_content_text was somehow preventing subsequent printf
On Sat, 28 May 2011 14:31:08 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Fri, 27 May 2011 17:53:44 -0700, Carl Worth cwo...@cworth.org wrote:
* Should we set the crypto option to verify/decrypt by default?
...
I don't really have an opinion on this. I have it set now,
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth cwo...@cworth.org wrote:
Otherwise, the patches up to this point in the thread have all either
been pushed or I've asked for some additional information (perhaps
that's just this patch and the old style fcc dirs patch?).
Great! That's really
On Fri, 03 Jun 2011 14:26:48 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Well actually it's only meant to sound like the committer doesn't
understand the problem!
Heh, OK.
I'd like to investigate this more. Perhaps with a test case?
The current tests are how I found
On Fri, 03 Jun 2011 15:38:29 -0700, Carl Worth cwo...@cworth.org wrote:
commit d5b4d950245605b84c56ce991fa3c59a073a70e5
Author: Jameson Graef Rollins jroll...@finestructure.net
Date: Sat May 28 14:52:00 2011 -0700
show: Avoid inadvertently closing stdout
GMime has a nasty
The notmuch binary is not in the business of doing interactive
prompting with the user. If credentials are needed for decryption,
they should be supplied to the decrypting processes some other way
(e.g. gpg-agent).
Previously, we returned a NULL function pointer for the
request_passwd()
On Fri, 3 Jun 2011 19:03:08 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
The notmuch binary is not in the business of doing interactive
prompting with the user. If credentials are needed for decryption,
they should be supplied to the decrypting processes some other way
(e.g.
On 06/03/2011 07:15 PM, Carl Worth wrote:
On Fri, 3 Jun 2011 19:03:08 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
The notmuch binary is not in the business of doing interactive
prompting with the user. If credentials are needed for decryption,
they should be supplied to the
Our use of GMimeSession was unneeded boilerplate, and we weren't doing
anything with it. This simplifies and clarifies that assumption.
If we want to do anything fancier later, the examples in the gmime
source are a reasonable source to work from in defining a new
GMimeSession derivative.
Since
This patch supercedes my patch from
1307142188-6551-1-git-send-email-...@fifthhorseman.net , and provides
what appears to be a much cleaner approach to achieve the same result.
--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
34 matches
Mail list logo