g_object_unref() releases the memory of the InternetAddressList object
returned by internet_address_list_parse_string() -- when last (only)
reference is released, internet_address_list_finalize() will do cleanup.
---
hmm, have to agree amdragon's "suggested alternative" is more robust
(in maintai
On Fri, 9 Dec 2011 14:54:27 -0500, Austin Clements wrote:
> This function matches how we number parts for the --part argument to
> show. It will allow us to jump directly to the desired part, rather
> than traversing the entire tree and carefully tracking whether or not
> we're "in the zone".
>
From: David Bremner
The code is already duplicated once, and I want to add a third
configuration item that is also a list.
---
Mainly I am curious if people think using macros to declare these
"getters" and "setters" makes the code less maintainable.
notmuch-config.c | 112 +++
Deduplicating this code seems like a great idea, but I don't think
macros are the way to do it; especially not one that expands to an
important top-level construct like a function definition.
What about something like
const char **
notmuch_config_get_user_other_email (notmuch_config_t *config,
Hello all!
Quick question: why isn't it reasonable to export a **single**
email in JSON format (by using the `show` sub-command)? (I mean I
understand that in order to be able to correctly parse the output we
need only one "object" (i.e. a list of threads, containing a list of
emails, etc.
On Sat, 10 Dec 2011 20:32:22 +0200, Ciprian Dorin Craciun
wrote:
> Quick question: why isn't it reasonable to export a **single**
> email in JSON format (by using the `show` sub-command)? (I mean I
> understand that in order to be able to correctly parse the output we
> need only one "object"
On Sat, 10 Dec 2011 13:24:36 -0500, Austin Clements wrote:
> What about something like
>
> const char **
> notmuch_config_get_user_other_email (notmuch_config_t *config,
> size_t *length)
> {
> return _config_get_list (config, "user", "other_email",
>
Hey, Austin. This is a really great rework of mime part handling. Your
new solution is much more elegant, and makes things much cleaner.
The patch series looks very good to me. I only have a couple of
comments on the crypto processing stuff, to follow.
I definitely support pushing this series
On Sat, 10 Dec 2011 03:25:48 +0400, Dmitry Kurochkin
wrote:
> +notmuch_bool_t decrypt_success;
>
> Perhaps s/decrypt_success/is_decrypted/ for consistency with
> is_encrypted?
This difference doesn't seem so bad to me, since the is_ variables point
to states of the original message, where a
On Fri, 9 Dec 2011 14:54:26 -0500, Austin Clements wrote:
> +/* Handle PGP/MIME parts */
> +if (GMIME_IS_MULTIPART_ENCRYPTED (part) && out->ctx->decrypt) {
> + if (out->children != 2) {
> + /* this violates RFC 3156 section 4, so we won't bother with it. */
> + fprintf
Hi, Jani. This is a nice patch series. I've been using both the pre-
and post-new hooks for a couple days now without any problems. It's a
nice bit of new functionality.
The patches have already had a good review, and it all looks good to me,
so I definitely supporting pushing them. They confl
On Sat, Dec 10, 2011 at 22:15, Jameson Graef Rollins
wrote:
> On Sat, 10 Dec 2011 20:32:22 +0200, Ciprian Dorin Craciun
> wrote:
>> Quick question: why isn't it reasonable to export a **single**
>> email in JSON format (by using the `show` sub-command)? (I mean I
>> understand that in order
On Sun, 11 Dec 2011 00:46:51 +0200, Ciprian Dorin Craciun
wrote:
> I've given a quick look into `notmuch-show.c` (commit from
> December 4) and indeed it seems quite trivial to add new formats.
>
> Thus I wonder:
> a) Is the code suitable for experimenting such a feature? (I mean
> i
On Sun, Dec 11, 2011 at 01:19, Jameson Graef Rollins
wrote:
> On Sun, 11 Dec 2011 00:46:51 +0200, Ciprian Dorin Craciun
> wrote:
>> * in my use-case I would need each line of the output to be a
>> standalone JSON object of an individual message; (thus I can script
>> with Bash `notmuch ... |
I have pushed a branch jlog
git://pivot.cs.unb.ca/notmuch.git
This uses the jlog library (http://labs.omniti.com/labs/jlog)
to atomically log messages in pub-sub model.
On this branch you can enable logging of tagging operations by
notmuch config set log.subscribers 'name1;name2;name3'
Just to add to Jameson's email...
Quoth Ciprian Dorin Craciun on Dec 11 at 12:46 am:
> On Sat, Dec 10, 2011 at 22:15, Jameson Graef Rollins
> wrote:
> > On Sat, 10 Dec 2011 20:32:22 +0200, Ciprian Dorin Craciun
> > wrote:
> >> Quick question: why isn't it reasonable to export a **single**
>
Hi Austin.
+/* The number of children of this part. */
+int children;
Consider renaming to children_count or similar to make it clear that it
is a counter and not the actual children.
+notmuch_bool_t decrypt_success;
Perhaps s/decrypt_success/is_decrypted/ for consistency with
is_en
g_object_unref() releases the memory of the InternetAddressList object
returned by internet_address_list_parse_string() -- when last (only)
reference is released, internet_address_list_finalize() will do cleanup.
---
hmm, have to agree amdragon's "suggested alternative" is more robust
(in maintai
On Fri, 9 Dec 2011 14:54:27 -0500, Austin Clements wrote:
> This function matches how we number parts for the --part argument to
> show. It will allow us to jump directly to the desired part, rather
> than traversing the entire tree and carefully tracking whether or not
> we're "in the zone".
>
From: David Bremner
The code is already duplicated once, and I want to add a third
configuration item that is also a list.
---
Mainly I am curious if people think using macros to declare these
"getters" and "setters" makes the code less maintainable.
notmuch-config.c | 112 +++
Deduplicating this code seems like a great idea, but I don't think
macros are the way to do it; especially not one that expands to an
important top-level construct like a function definition.
What about something like
const char **
notmuch_config_get_user_other_email (notmuch_config_t *config,
Hello all!
Quick question: why isn't it reasonable to export a **single**
email in JSON format (by using the `show` sub-command)? (I mean I
understand that in order to be able to correctly parse the output we
need only one "object" (i.e. a list of threads, containing a list of
emails, etc.
get some
sort of single-message output going.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111210/ba9c91ce/attachment.pgp>
On Sat, 10 Dec 2011 13:24:36 -0500, Austin Clements wrote:
> What about something like
>
> const char **
> notmuch_config_get_user_other_email (notmuch_config_t *config,
> size_t *length)
> {
> return _config_get_list (config, "user", "other_email",
>
(or maybe a v3 of it) into
master.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111210/7c656
or decryption?
We probably should. We can probably fix this in followup patches, since
Austin is just working off of what dkg and I put in there originally.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
S
ity is not UNKNOWN.
I've really been meaning to overhaul this stuff for gmime 2.6.
Hopefully I'll start looking at that after these patches go through.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111210/5d5b4372/attachment.pgp>
ble
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111210/840b1d54/attachment.pgp>
attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111210/4f968d6e/attachment.pgp>
ment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111210/4f2ba21f/attachment.pgp>
Just to add to Jameson's email...
Quoth Ciprian Dorin Craciun on Dec 11 at 12:46 am:
> On Sat, Dec 10, 2011 at 22:15, Jameson Graef Rollins
> wrote:
> > On Sat, 10 Dec 2011 20:32:22 +0200, Ciprian Dorin Craciun > at gmail.com> wrote:
> >> ? ? Quick question: why isn't it reasonable to export a *
31 matches
Mail list logo
