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
Jani Nikula j...@nikula.org 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
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.
---
test/encoding | 18 ++
1 file changed, 18 insertions(+)
diff --git a/test/encoding b/test
v2 LGTM.
Quoth Jani Nikula on Sep 11 at 8:36 pm:
> 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.
> ---
> test/encoding | 18 +
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.
---
test/encoding | 18 ++
1 file changed, 18 insertions(+)
diff --git a/test/encoding b/test
v2 LGTM.
Quoth Jani Nikula on Sep 11 at 8:36 pm:
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.
---
test/encoding | 18 ++
1 file
On Wed, Sep 11 2013, Jani Nikula j...@nikula.org wrote:
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.
---
V2 LGTM.
Tomi
test/encoding | 18
r locale.
I agree that it would be very nice indeed if it was safe to assume
all tags are utf-8. But i also see that it's a bit of an effort
to ensure this as all UI's would have to explicitly recode
stuff that isn't utf-8.
It seems to be a conciously made design decision to allow
other encodings for
Hi Patrick,
On Tue, Jul 12, 2011 at 10:29:58PM +0100, Patrick Totzke wrote:
> I noticed that commit 687366b920caa5de6ea0b66b70cf2a11e5399f7b
> breaks things with Database.get_all_tags:
>
> -->%-
> AttributeError
Hi Patrick,
On Tue, Jul 12, 2011 at 10:29:58PM +0100, Patrick Totzke wrote:
I noticed that commit 687366b920caa5de6ea0b66b70cf2a11e5399f7b
breaks things with Database.get_all_tags:
--%-
AttributeError
that it would be very nice indeed if it was safe to assume
all tags are utf-8. But i also see that it's a bit of an effort
to ensure this as all UI's would have to explicitly recode
stuff that isn't utf-8.
It seems to be a conciously made design decision to allow
other encodings for tags, which is up
Hiya,
I noticed that commit 687366b920caa5de6ea0b66b70cf2a11e5399f7b
breaks things with Database.get_all_tags:
-->%-
AttributeErrorTraceback (most recent call last)
/home/pazz/projects/alot/ in
that things are very implicit. notmuch.h speaks of
> > strings but never mentions encodings
>
> Much of this was intentional on my part.
>
> For example, I intentionally avoided restrictions on what could be
> stored as a tag in the database, (other than the terminating characte
is that things are very implicit. notmuch.h speaks of
strings but never mentions encodings
Much of this was intentional on my part.
For example, I intentionally avoided restrictions on what could be
stored as a tag in the database, (other than the terminating character
implied by string of course
Hiya,
I noticed that commit 687366b920caa5de6ea0b66b70cf2a11e5399f7b
breaks things with Database.get_all_tags:
--%-
AttributeErrorTraceback (most recent call last)
Hi all,
after I was notified about how notmuch's python bindings perform
differently depending on whether we hand it (byte-based) ASCII strings
or unicode, I tried to disentangle what encodings to expect and send it
to. The answer is that things are very implicit. notmuch.h speaks of
strings
On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth
wrote:
> The answer is that things are very implicit. notmuch.h speaks of
> strings but never mentions encodings
Much of this was intentional on my part.
For example, I intentionally avoided restrictions on what could be
stored as
Hi all,
after I was notified about how notmuch's python bindings perform
differently depending on whether we hand it (byte-based) ASCII strings
or unicode, I tried to disentangle what encodings to expect and send it
to. The answer is that things are very implicit. notmuch.h speaks of
strings
On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth sebast...@sspaeth.de
wrote:
The answer is that things are very implicit. notmuch.h speaks of
strings but never mentions encodings
Much of this was intentional on my part.
For example, I intentionally avoided restrictions on what could
19 matches
Mail list logo
