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
bbed...
Name: 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() function,
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 v
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 ve
On Fri, 3 Jun 2011 19:57:46 -0400, Daniel Kahn Gillmor
wrote:
> Our use of GMimeSession was unneeded boilerplate, and we weren't doing
> anything with it. This simplifies and clarifies that assumption.
Very nice. This is pushed now.
-Carl
pgpMIWmM0YltL.pgp
Description: PGP signature
___
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/323082b2/attachment.pgp>
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
http://notmuchma
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
On 06/03/2011 07:15 PM, Carl Worth wrote:
> On Fri, 3 Jun 2011 19:03:08 -0400, Daniel Kahn Gillmor
> 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 proces
On Fri, 3 Jun 2011 19:03:08 -0400, Daniel Kahn Gillmor
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. gpg-agent).
>
> Previ
emory 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/pi
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() function,
On Fri, 03 Jun 2011 15:38:29 -0700, Carl Worth wrote:
> commit d5b4d950245605b84c56ce991fa3c59a073a70e5
> Author: Jameson Graef Rollins
> Date: Sat May 28 14:52:00 2011 -0700
>
> show: Avoid inadvertently closing stdout
>
> GMime has a nasty habit of taking ownership by default of
...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/ee1f143f/attachment-0001.pgp>
On Fri, 03 Jun 2011 14:39:13 -0700, Jameson Graef Rollins
wrote:
> Can we set a target date for 0.6 release? So we'll all start feeling
> really bad if we miss it?
Frankly, I wouldn't mind doing strict time-based releases with something
like the following:
* We schedule a release perio
-Carl
--
carl.d.worth at intel.com
-- 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/eccc812f/attachment.pgp>
A non-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
On Fri, 03 Jun 2011 14:26:48 -0700, Jameson Graef Rollins
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 the problem! Without t
redirected "notmuch show" calls to the test suite
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-
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth 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 great news, Carl.
.
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/4e3aeb2f/attachment.pgp>
On Sat, 28 May 2011 14:31:08 -0700, Jameson Graef Rollins
wrote:
> On Fri, 27 May 2011 17:53:44 -0700, Carl Worth 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, so whether
> or not it's set by default
rt --
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/4dd4149a/attachment.pgp>
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth wrote:
> On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins
> 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
ime_stream_file_new() 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 avai
On Thu, 12 May 2011 17:56:25 +0400, Dmitry Kurochkin
wrote:
> Mail-header-parse-address may fail for an invalid address.
> Before the change, this would result in empty notmuch-show buffer
> with an error message like: Scan error: "Unbalanced parentheses".
> The patch wraps the function in condit
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/89821ae3/attachment-0001.pgp>
On Sat, 04 Jun 2011 00:22:04 +0400, Dmitry Kurochkin
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 wrong-type-argument lisp error
e: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/4137e868/attachment.pgp>
On Fri, 03 Jun 2011 13:05:00 -0700, Carl Worth wrote:
Non-text part: multipart/signed
> On Thu, 02 Jun 2011 10:49:57 +0400, Dmitry Kurochkin
> 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 "new" refers to 0.5.
>
> Sure, bu
On Thu, 02 Jun 2011 10:49:57 +0400, Dmitry Kurochkin
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 "new" refers to 0.5.
Sure, but I happen to ahve already forgotten the details of how the
variable could be configured in 0.4 and
scriptions,
not relative 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>
On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins
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. Scoping the declaration to th
: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110603/48e88dcd/attachment.pgp>
On Sat, 28 May 2011 14:51:52 -0700, Jameson Graef Rollins
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 generate a compiler
error in
Thanks for your attention, (and thanks 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 cer
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 cer
On Fri, 27 May 2011 20:52:01 +0200, Daniel Schoepe
wrote:
> I'll also work on some tests for this functionality, (if no one
> has big, structural complaints about the code).
I rebased my patch against the current master and wrote some tests.
From 42b87fca9b8b2ca5ba6748185dac4e945d7c594b Mon Sep
41 matches
Mail list logo
