problems with multipart/mixed
Hehe, as the reply below shows... there's still something screwy even with the latest git version... in multipart messages things just go wrong. Whether I reply (this below should have included your text/plain part as quote), or whether I try to see the html part of a text/plain + text/html multipart message... /D On Mon, 23 May 2011 14:38:05 -0700, Carl Worth wrote: Non-text part: multipart/signed
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
Before the change, save-excursion was used to save the point. But the restored position is affected by buffer modifications, which results in jumping cursor. The patch saves and restores point explicitly by using a variable instead of save-excursion. --- emacs/notmuch-wash.el | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 863459e..b6d791f 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -82,13 +82,14 @@ collapse the remaining lines into a button.") (let* ((new-start (button-start cite-button)) (overlay (button-get cite-button 'overlay)) (button-label (notmuch-wash-button-label overlay)) +(old-point (point)) (inhibit-read-only t)) -(save-excursion - (goto-char new-start) - (insert button-label) - (let ((old-end (button-end cite-button))) - (move-overlay cite-button new-start (point)) - (delete-region (point) old-end +(goto-char new-start) +(insert button-label) +(let ((old-end (button-end cite-button))) + (move-overlay cite-button new-start (point)) + (delete-region (point) old-end)) +(goto-char old-point)) (force-window-update) (redisplay t)) -- 1.7.5.1
[BUG] multipart ID of show != part
Hi all,
I found some problems with the multipart/mixed behavior of current
master. I have several multipart mails where the html part is not
displayed and a text/plain attachment is wrongly reported as text/html.
I have no real insight into the inner workings of notmuch-show but have
found this discrepancy between "notmuch show" and "notmuch part":
(master last commit c4e00ab69a14bfe5756056614a5fb7df8580cd33)
show produces this JSON:
^Lbody{
^Lpart{ ID: 1, Content-type: multipart/mixed
^Lpart{ ID: 2, Content-type: text/html
Non-text part: text/html
^Lpart}
^Lattachment{ ID: 3, Content-type: text/plain
Attachment: ATT1.c (text/plain)
___
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
^Lattachment}
^Lpart}
^Lbody}
whereas "notmuch part --part=2" produces this (the content of the
ATT1.c file):
___
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
the man page states that the part number is equal to the ID, but here
part=2 returns the content of ID=3 and therefore the wrong message
part.
regards
Matthias
problems with multipart/mixed
> If you did then I'm in the same boat. Notmuch/emacs used to display both
welcome to the boat!
I found the reason why that happens. Basically it appears because of a
bug in the ongoing multipart development.
In my example, the problem is as follows: currently the outer multipart
message gets ID 1, the first html part ID 2, and the attachment ID 3.
This seems to be correct in the JSON output. But for whatever reason,
show in emacs does not display the html part at all and the attachment
as text/html (it is text/plain). So it seems that the show is off by 1
somewhere.
Now a quick-and-dirty way around this:
reset to c51d5b3cdb5ca0816816e88ca6f7136a24e74eee
and apply this patch:
8<-
diff --git a/show-message.c b/show-message.c
index ff9146e..6913d7f 100644
--- a/show-message.c
+++ b/show-message.c
@@ -30,8 +30,8 @@ show_message_part (GMimeObject *part, int *part_count,
GMimeMultipart *multipart = GMIME_MULTIPART (part);
int i;
- *part_count = *part_count + 1;
- (*show_part) (part, part_count);
+ //*part_count = *part_count + 1;
+ //(*show_part) (part, part_count);
for (i = 0; i < g_mime_multipart_get_count (multipart); i++) {
show_message_part (g_mime_multipart_get_part (multipart, i),
8<-
current master is already some steps further, so probably this will be
fixed in a correct way soon, but for now I'll use this.
regards
Matthias
[BUG] multipart ID of show != part
On Mon, 23 May 2011 19:25:01 +0200, Matthias Guedemann wrote:
> show produces this JSON:
>
> ^Lbody{
> ^Lpart{ ID: 1, Content-type: multipart/mixed
> ^Lpart{ ID: 2, Content-type: text/html
...
> whereas "notmuch part --part=2" produces this (the content of the
> ATT1.c file):
It used to be that the "multipart" containers were not printed in
"notmuch show" (so they weren't counted). We recently began emitting
these, and counting them, but we neglected to update the "notmuch part"
code to count them equivalently.
I've just pushed a quick patch to "notmuch part" to fix this problem for
now.
Soon, we'll have a patch series from Jameson committed that replaces the
"notmuch part" command with "notmuch show --part". That will have the
advantage of implementing both pieces of functionality with one piece of
code, so that skew like this will no longer be possible.
Thanks for the report.
-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/20110523/26c43ced/attachment.pgp>
problems with multipart/mixed
On Mon, 23 May 2011 15:39:07 +0200, Matthias Guedemann wrote: > > > If you did then I'm in the same boat. Notmuch/emacs used to display both > > welcome to the boat! My fault. I'm sorry about this breakage. > Now a quick-and-dirty way around this: > > reset to c51d5b3cdb5ca0816816e88ca6f7136a24e74eee > > and apply this patch: .. > - *part_count = *part_count + 1; > - (*show_part) (part, part_count); > + //*part_count = *part_count + 1; > + //(*show_part) (part, part_count); Your patch here removes the change to the part numbering for "notmuch show". I've just pushed a change which instead adds this same part numbering to "notmuch part". Please try it out and let me know if you have any further trouble. Clearly, we've got a hole in our test suite since it didn't notice this problem at all. Meanwhile, Jameson has proposed (in IRC) a patch series to further rework the way that "notmuch part" works. That series also adds various tests for "notmuch part" (which will instead be called "notmuch show --part") to the test suite. So hopefully we won't have this same regression appear in the future. Thanks, everyone for reporting this bug. -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/20110523/20eac1d0/attachment.pgp>
[BUG] multipart ID of show != part
On 05/23/2011 01:25 PM, Matthias Guedemann wrote: > Hi all, > > I found some problems with the multipart/mixed behavior of current > master. I have several multipart mails where the html part is not > displayed and a text/plain attachment is wrongly reported as text/html. > > I have no real insight into the inner workings of notmuch-show but have > found this discrepancy between "notmuch show" and "notmuch part": the part numbering and representations are in the middle of a major reorganization; the part numbers should be normalized across all uses (with the exception of decrypted messages, whose part numberings will change based on a successful decryption) once the overhaul is done. i believe that the "notmuch part" subcommand itself is likely to go away in favor of a --part=X argument to "notmuch show". We will ensure that the part numbering is correct, but i agree with you that current master isn't there yet. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110523/30627ada/attachment.pgp>
a python terminal gui?
On Sat, 21 May 2011 19:50:37 +0100, Patrick Totzke wrote: > That is surprising! I only fill the screen by iterating over an initial > part of the iterator returned by Query.search_threads() > I do a second query to count the messages by Query.count_messages(), > but I'd guess that this translates to some sort of "SELECT COUNT" > and should also be fast. Maybe there's some copying going on > at lower levels? The "count" operation should be something very fast, yes. It might be worth some investigation to see if there's actually a problem here or not. > > * The '/' key didn't seem to do anything for me, so I wasn't able to > > actually do any custom searches. > This is because it really is "\" :P that was a typo in the README. Ah. Thanks. That definitely helps. > Thanks, that's helpful. I guess it would make sense to place this under > notmuch/contrib at a later point if it gets usable. Sure. I'll be glad to do that. Just let me know when you want it. > Ah I have question regarding "toplevel" messages in threads: > How can it be that a mail that is not the one that started a thread > is contained in thread.get_toplevel_messages() ? > The only thing I can think of is that a user somehow forced two threads > to become one. Take this very thread for example. Why do I get > Mueen Nawaz's reply as a toplevel message? does this mean > that messages header has incorrect Reply-to headers set? Hmmm... I do seem to be seeing that behavior. The message from Mueen Nawaz (id:"87y620subn.fsf at fester.com") does not have any In-Reply-To header, but it does contain the following: References: <1305888097-sup-2343 at optimusprime> which is the correct message ID for the original top-level message in the thread. So it looks like there's a bug here in notmuch not correctly stitching this message to its parent in this case. It should be an easy test case to add to the suite (and hopefully an easy bug to fix as well). -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/20110523/67ef22c2/attachment.pgp>
problems with multipart/mixed
On Sat, 21 May 2011 08:35:13 +0200, Matthias Guedemann wrote: > > Hi all, > > I am using notmuch / emacs as my main mail client now for several months > and loosely follow master. > > After an update yesterday I now have problems with some multipart/mixed > mails from mailing lists which are displayed for example as follows (I > could also provide the raw mail if needed): > > 8<-- > Subject: [Haskell-cafe] Can't access map value with key. > To: "haskell-cafe at haskell.org" > > Date: Sat, 21 May 2011 04:04:31 +0200 > > > > [ multipart/mixed ] > [ text/html ] > > ___ Haskell-Cafe mailing > list Haskell-Cafe at haskell.org http:// > www.haskell.org/mailman/listinfo/haskell-cafe > > > > [ ATT1.c: text/plain ] > > [ 4-line signature. Click/Enter to toggle visibility. ] > 8<-- > > i.e. the html part is not displayed. I'd like to have it displayed > inline (using w3m), just as other html mails and just like it worked > before (at least I think it worked). I probably just missed a simple > configuration option. If you did then I'm in the same boat. Notmuch/emacs used to display both parts, text and html, and now only displays text with no way (that I could find) to display the html part as well. /D
Re: problems with multipart/mixed
On Sat, 21 May 2011 08:35:13 +0200, Matthias Guedemann matthias.guedem...@ovgu.de wrote: Hi all, I am using notmuch / emacs as my main mail client now for several months and loosely follow master. After an update yesterday I now have problems with some multipart/mixed mails from mailing lists which are displayed for example as follows (I could also provide the raw mail if needed): 8-- Subject: [Haskell-cafe] Can't access map value with key. To: haskell-c...@haskell.org haskell-c...@haskell.org Date: Sat, 21 May 2011 04:04:31 +0200 [ multipart/mixed ] [ text/html ] ___ Haskell-Cafe mailing list haskell-c...@haskell.org http:// www.haskell.org/mailman/listinfo/haskell-cafe [ ATT1.c: text/plain ] [ 4-line signature. Click/Enter to toggle visibility. ] 8-- i.e. the html part is not displayed. I'd like to have it displayed inline (using w3m), just as other html mails and just like it worked before (at least I think it worked). I probably just missed a simple configuration option. If you did then I'm in the same boat. Notmuch/emacs used to display both parts, text and html, and now only displays text with no way (that I could find) to display the html part as well. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
If you did then I'm in the same boat. Notmuch/emacs used to display both
welcome to the boat!
I found the reason why that happens. Basically it appears because of a
bug in the ongoing multipart development.
In my example, the problem is as follows: currently the outer multipart
message gets ID 1, the first html part ID 2, and the attachment ID 3.
This seems to be correct in the JSON output. But for whatever reason,
show in emacs does not display the html part at all and the attachment
as text/html (it is text/plain). So it seems that the show is off by 1
somewhere.
Now a quick-and-dirty way around this:
reset to c51d5b3cdb5ca0816816e88ca6f7136a24e74eee
and apply this patch:
8-
diff --git a/show-message.c b/show-message.c
index ff9146e..6913d7f 100644
--- a/show-message.c
+++ b/show-message.c
@@ -30,8 +30,8 @@ show_message_part (GMimeObject *part, int *part_count,
GMimeMultipart *multipart = GMIME_MULTIPART (part);
int i;
- *part_count = *part_count + 1;
- (*show_part) (part, part_count);
+ //*part_count = *part_count + 1;
+ //(*show_part) (part, part_count);
for (i = 0; i g_mime_multipart_get_count (multipart); i++) {
show_message_part (g_mime_multipart_get_part (multipart, i),
8-
current master is already some steps further, so probably this will be
fixed in a correct way soon, but for now I'll use this.
regards
Matthias
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
Before the change, save-excursion was used to save the point. But the restored position is affected by buffer modifications, which results in jumping cursor. The patch saves and restores point explicitly by using a variable instead of save-excursion. --- emacs/notmuch-wash.el | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 863459e..b6d791f 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -82,13 +82,14 @@ collapse the remaining lines into a button.) (let* ((new-start (button-start cite-button)) (overlay (button-get cite-button 'overlay)) (button-label (notmuch-wash-button-label overlay)) +(old-point (point)) (inhibit-read-only t)) -(save-excursion - (goto-char new-start) - (insert button-label) - (let ((old-end (button-end cite-button))) - (move-overlay cite-button new-start (point)) - (delete-region (point) old-end +(goto-char new-start) +(insert button-label) +(let ((old-end (button-end cite-button))) + (move-overlay cite-button new-start (point)) + (delete-region (point) old-end)) +(goto-char old-point)) (force-window-update) (redisplay t)) -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: a python terminal gui?
On Sat, 21 May 2011 19:50:37 +0100, Patrick Totzke patricktot...@googlemail.com wrote: That is surprising! I only fill the screen by iterating over an initial part of the iterator returned by Query.search_threads() I do a second query to count the messages by Query.count_messages(), but I'd guess that this translates to some sort of SELECT COUNT and should also be fast. Maybe there's some copying going on at lower levels? The count operation should be something very fast, yes. It might be worth some investigation to see if there's actually a problem here or not. * The '/' key didn't seem to do anything for me, so I wasn't able to actually do any custom searches. This is because it really is \ :P that was a typo in the README. Ah. Thanks. That definitely helps. Thanks, that's helpful. I guess it would make sense to place this under notmuch/contrib at a later point if it gets usable. Sure. I'll be glad to do that. Just let me know when you want it. Ah I have question regarding toplevel messages in threads: How can it be that a mail that is not the one that started a thread is contained in thread.get_toplevel_messages() ? The only thing I can think of is that a user somehow forced two threads to become one. Take this very thread for example. Why do I get Mueen Nawaz's reply as a toplevel message? does this mean that messages header has incorrect Reply-to headers set? Hmmm... I do seem to be seeing that behavior. The message from Mueen Nawaz (id:87y620subn@fester.com) does not have any In-Reply-To header, but it does contain the following: References: 1305888097-sup-2343@optimusprime which is the correct message ID for the original top-level message in the thread. So it looks like there's a bug here in notmuch not correctly stitching this message to its parent in this case. It should be an easy test case to add to the suite (and hopefully an easy bug to fix as well). -Carl pgpMWqSqTQmuX.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[BUG] multipart ID of show != part
Hi all,
I found some problems with the multipart/mixed behavior of current
master. I have several multipart mails where the html part is not
displayed and a text/plain attachment is wrongly reported as text/html.
I have no real insight into the inner workings of notmuch-show but have
found this discrepancy between notmuch show and notmuch part:
(master last commit c4e00ab69a14bfe5756056614a5fb7df8580cd33)
show produces this JSON:
^Lbody{
^Lpart{ ID: 1, Content-type: multipart/mixed
^Lpart{ ID: 2, Content-type: text/html
Non-text part: text/html
^Lpart}
^Lattachment{ ID: 3, Content-type: text/plain
Attachment: ATT1.c (text/plain)
___
Haskell-Cafe mailing list
haskell-c...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
^Lattachment}
^Lpart}
^Lbody}
whereas notmuch part --part=2 produces this (the content of the
ATT1.c file):
___
Haskell-Cafe mailing list
haskell-c...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
the man page states that the part number is equal to the ID, but here
part=2 returns the content of ID=3 and therefore the wrong message
part.
regards
Matthias
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] multipart ID of show != part
On 05/23/2011 01:25 PM, Matthias Guedemann wrote: Hi all, I found some problems with the multipart/mixed behavior of current master. I have several multipart mails where the html part is not displayed and a text/plain attachment is wrongly reported as text/html. I have no real insight into the inner workings of notmuch-show but have found this discrepancy between notmuch show and notmuch part: the part numbering and representations are in the middle of a major reorganization; the part numbers should be normalized across all uses (with the exception of decrypted messages, whose part numberings will change based on a successful decryption) once the overhaul is done. i believe that the notmuch part subcommand itself is likely to go away in favor of a --part=X argument to notmuch show. We will ensure that the part numbering is correct, but i agree with you that current master isn't there yet. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
On Mon, 23 May 2011 15:39:07 +0200, Matthias Guedemann matthias.guedem...@ovgu.de wrote: If you did then I'm in the same boat. Notmuch/emacs used to display both welcome to the boat! My fault. I'm sorry about this breakage. Now a quick-and-dirty way around this: reset to c51d5b3cdb5ca0816816e88ca6f7136a24e74eee and apply this patch: .. - *part_count = *part_count + 1; - (*show_part) (part, part_count); + //*part_count = *part_count + 1; + //(*show_part) (part, part_count); Your patch here removes the change to the part numbering for notmuch show. I've just pushed a change which instead adds this same part numbering to notmuch part. Please try it out and let me know if you have any further trouble. Clearly, we've got a hole in our test suite since it didn't notice this problem at all. Meanwhile, Jameson has proposed (in IRC) a patch series to further rework the way that notmuch part works. That series also adds various tests for notmuch part (which will instead be called notmuch show --part) to the test suite. So hopefully we won't have this same regression appear in the future. Thanks, everyone for reporting this bug. -Carl pgphf39PsS9sj.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] multipart ID of show != part
On Mon, 23 May 2011 19:25:01 +0200, Matthias Guedemann
matthias.guedem...@ovgu.de wrote:
show produces this JSON:
^Lbody{
^Lpart{ ID: 1, Content-type: multipart/mixed
^Lpart{ ID: 2, Content-type: text/html
...
whereas notmuch part --part=2 produces this (the content of the
ATT1.c file):
It used to be that the multipart containers were not printed in
notmuch show (so they weren't counted). We recently began emitting
these, and counting them, but we neglected to update the notmuch part
code to count them equivalently.
I've just pushed a quick patch to notmuch part to fix this problem for
now.
Soon, we'll have a patch series from Jameson committed that replaces the
notmuch part command with notmuch show --part. That will have the
advantage of implementing both pieces of functionality with one piece of
code, so that skew like this will no longer be possible.
Thanks for the report.
-Carl
--
carl.d.wo...@intel.com
pgpQOBStm7juW.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
Hehe, as the reply below shows... there's still something screwy even with the latest git version... in multipart messages things just go wrong. Whether I reply (this below should have included your text/plain part as quote), or whether I try to see the html part of a text/plain + text/html multipart message... /D On Mon, 23 May 2011 14:38:05 -0700, Carl Worth cwo...@cworth.org wrote: Non-text part: multipart/signed ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
