In the recent changes for search order handling the default-value of
notmuch-search-oldest-first was used. However, default-value needs a
symbol so the symbol-name needs to be quoted.
This missing quote was causing strange sort-orders in some cases.
---
I think this is clearly correct (and what w
Definitely LGTM.
Quoth Mark Walters on Sep 14 at 9:17 pm:
> In the recent changes for search order handling the default-value of
> notmuch-search-oldest-first was used. However, default-value needs a
> symbol so the symbol-name needs to be quoted.
>
> This missing quote was causing strange sort-
Jani Nikula writes:
> Some common broken RFC 2047 encodings that we currently let gmime
> parse strictly. We could tell gmime to be forgiving in what it accepts
> as RFC 2047 encoding, making these tests pass.
Pushed this version.
d
Definitely LGTM.
Quoth Mark Walters on Sep 14 at 9:17 pm:
> In the recent changes for search order handling the default-value of
> notmuch-search-oldest-first was used. However, default-value needs a
> symbol so the symbol-name needs to be quoted.
>
> This missing quote was causing strange sort-
In the recent changes for search order handling the default-value of
notmuch-search-oldest-first was used. However, default-value needs a
symbol so the symbol-name needs to be quoted.
This missing quote was causing strange sort-orders in some cases.
---
I think this is clearly correct (and what w
On Mon, Sep 02 2013, Mark Walters wrote:
> Currently pick makes the tree box graphics part of the "subject". This
> is rather unsatisfactory: the tree graphics should be a field in their
> own right.
>
> However, there is no mechanism in the current setup for allowing 2
> fields to have fixed com
Jani Nikula writes:
> Some common broken RFC 2047 encodings that we currently let gmime
> parse strictly. We could tell gmime to be forgiving in what it accepts
> as RFC 2047 encoding, making these tests pass.
Pushed this version.
d
___
notmuch mailin
On Mon, Sep 02 2013, Mark Walters wrote:
> Currently pick makes the tree box graphics part of the "subject". This
> is rather unsatisfactory: the tree graphics should be a field in their
> own right.
>
> However, there is no mechanism in the current setup for allowing 2
> fields to have fixed com