LGTM in principle, though I'd like to see a test of some of the
malformed RFC 2047 that this lets us decode. Is there a summary
somewhere of exactly what these workarounds enable?
This isn't directly related to this patch, but is there a reason we
g_mime_init in so many different places? Both
On Tue, 10 Sep 2013, Daniel Kahn Gillmor wrote:
> On 09/10/2013 06:35 PM, Austin Clements wrote:
>
>> I haven't looked at exactly what workarounds this enables, but if it's
>> what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text
>> tokens), are there really subject lines that this
As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]:
> Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init()
> *should* solve the decoding problem mentioned in the thread. This
> flag should be safe to pass into g_mime_init() without any bad side
> effects and my
David Bremner writes:
> Ramakrishnan Muthukrishnan writes:
>
>>
>> If I startup notmuch and then do a M-x notmuch-search and then *, I see
>> the messages with the newest on the top. But if I instead, startup
>> notmuch and then hit "s", I see that the new messages are at the
>> bottom. The
esc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20130910/19dde093/attachment.pgp>
Quoth Daniel Kahn Gillmor on Sep 10 at 3:31 pm:
> On 09/10/2013 02:51 PM, Jani Nikula wrote:
> > As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]:
> >
> >> Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init()
> >> *should* solve the decoding problem mentioned in
notmuchmail.org/pipermail/notmuch/attachments/20130910/3afe99ce/attachment.pgp>
> Ideally, we would put this output in the notmuch errors buffer but the
> handler is called asynchronously so we don't know when the output will
> appear. Thus if we put it straight into the errors buffer it could get
> interleaved with other errors, otoh we can't easily tell when we
> have got
Hello
I was trying to reply to a message I had forwarded to someone (to update
the information sent in the first message) and came across some strange
behaviour.
The initial forward was done using notmuch-emacs: this took the message
and sent it as a message/rfc822 mimetype complete message.
Hi
>> Do you have a particular use case where indexing is required but tagging
>> is not? For my uses I would prefer failing if either indexing or tagging
>> failed. (My use being postponing messages; If they don't get the
>> postponed tag they could be hard to find)
>
> You're right.
>
> What
Simon Hirscher writes:
>
> $ gpg --recv-keys
>
> $ notmuch show --decrypt id:xyz at example.com
>
> [?]
> Hey there,
> Now the decryption worked!
> [?]
>
Is this related to Jamie's report?
id:87obwrix8s.fsf at servo.finestructure.net
Jamie, did you ever narrow down the gmime
Ramakrishnan Muthukrishnan writes:
>
> If I startup notmuch and then do a M-x notmuch-search and then *, I see
> the messages with the newest on the top. But if I instead, startup
> notmuch and then hit "s", I see that the new messages are at the
> bottom. The value of
Istvan Marko writes:
> When text/html parts include images as multipart/related and the
> text/plain alternative is used these images can be completely hidden
> with no easy way to access them or even find out that they are there.
pushed,
d
Austin Clements writes:
> This is v2 of id:1377793557-28878-1-git-send-email-amdragon at mit.edu.
> This fixes a problem found by Jani where notmuch-hello would reset
> point placement when refreshing in Emacs 24. It also inverts the
> sense of notmuch-hello-auto-refresh and makes it a
Mark Walters writes:
> The lazy part handler had a bug that it allowed the button to be
> toggled to be specified. During toggling it needs to save and restore
> the text-properties for the button but it actually saved the text
> properties at point rather than from the button.
pushed,
d
Hi
Do you have a particular use case where indexing is required but tagging
is not? For my uses I would prefer failing if either indexing or tagging
failed. (My use being postponing messages; If they don't get the
postponed tag they could be hard to find)
You're right.
What about a
Hello
I was trying to reply to a message I had forwarded to someone (to update
the information sent in the first message) and came across some strange
behaviour.
The initial forward was done using notmuch-emacs: this took the message
and sent it as a message/rfc822 mimetype complete message.
Mark Walters markwalters1...@gmail.com writes:
The lazy part handler had a bug that it allowed the button to be
toggled to be specified. During toggling it needs to save and restore
the text-properties for the button but it actually saved the text
properties at point rather than from the
Austin Clements amdra...@mit.edu writes:
This is v2 of id:1377793557-28878-1-git-send-email-amdra...@mit.edu.
This fixes a problem found by Jani where notmuch-hello would reset
point placement when refreshing in Emacs 24. It also inverts the
sense of notmuch-hello-auto-refresh and makes it a
Istvan Marko notm...@kismala.com writes:
When text/html parts include images as multipart/related and the
text/plain alternative is used these images can be completely hidden
with no easy way to access them or even find out that they are there.
pushed,
d
Ramakrishnan Muthukrishnan r...@rkrishnan.org writes:
If I startup notmuch and then do a M-x notmuch-search and then *, I see
the messages with the newest on the top. But if I instead, startup
notmuch and then hit s, I see that the new messages are at the
bottom. The value of
Simon Hirscher pub...@simonhirscher.de writes:
$ gpg --recv-keys sender's key
$ notmuch show --decrypt id:x...@example.com
[…]
Hey there,
Now the decryption worked!
[…]
Is this related to Jamie's report?
id:87obwrix8s@servo.finestructure.net
Jamie, did you ever narrow down the
Ideally, we would put this output in the notmuch errors buffer but the
handler is called asynchronously so we don't know when the output will
appear. Thus if we put it straight into the errors buffer it could get
interleaved with other errors, otoh we can't easily tell when we
have got all
David Bremner da...@tethera.net writes:
Ramakrishnan Muthukrishnan r...@rkrishnan.org writes:
If I startup notmuch and then do a M-x notmuch-search and then *, I see
the messages with the newest on the top. But if I instead, startup
notmuch and then hit s, I see that the new messages are at
As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]:
Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init()
*should* solve the decoding problem mentioned in the thread. This
flag should be safe to pass into g_mime_init() without any bad side
effects and my unit
On 09/10/2013 02:51 PM, Jani Nikula wrote:
As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]:
Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init()
*should* solve the decoding problem mentioned in the thread. This
flag should be safe to pass into g_mime_init()
On 09/10/2013 06:35 PM, Austin Clements wrote:
I haven't looked at exactly what workarounds this enables, but if it's
what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text
tokens), are there really subject lines that this will misinterpret
that weren't obviously crafted to break
On Tue, 10 Sep 2013, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
On 09/10/2013 06:35 PM, Austin Clements wrote:
I haven't looked at exactly what workarounds this enables, but if it's
what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text
tokens), are there really subject
LGTM in principle, though I'd like to see a test of some of the
malformed RFC 2047 that this lets us decode. Is there a summary
somewhere of exactly what these workarounds enable?
This isn't directly related to this patch, but is there a reason we
g_mime_init in so many different places? Both
29 matches
Mail list logo