After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744417 - GMimeFilterHTML: ignoring URL at end of message part
GMimeFilterHTML: ignoring URL at end of message part
Status: RESOLVED NOTABUG
Product: gmime
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jeffrey Stedfast
Jeffrey Stedfast
Depends on:
Blocks:
 
 
Reported: 2015-02-12 18:40 UTC by Gaute Hope
Modified: 2015-04-11 11:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Gaute Hope 2015-02-12 18:40:07 UTC
I reported this on the mailing list, but I'll put it here for reference since the issue is still unresolved.

I am parsing an email message that came in as a GitHub comment. I want to
get the plain-text part converted to HTML (yes, I know there is an HTML
part I could have used).

However, when I try to convert the plain-text to HTML by using the
GMimeFilterHTML I end up with missing the plain-text link that is at
the very end of the message. It seems to be simply ignored. I have tried
turning on-off some of the filter options, but to no avail.

I am using a gmime_iostream wrapper [0] or originally from [1], the code
that does the parsing is also online [2].

If I add a newline to the message source right before the second: 

----==_mimepart_540ffd23a9176_53cd3ffb4d3fb2bc2852c3

the message parses as it should. Is this something I am doing wrong or
is this a bug?

Excerpts of the problematic email is included below, hopefully this is
sufficient to show the problem.

Jeff suggested this might be because I am pulling data through the filter as opposed to pushing the data through, I tried debugging, but could not concluded with what is the reason.

The original discussion: https://mail.gnome.org/archives/gmime-devel-list/2014-September/msg00000.html

[0] https://github.com/gauteh/astroid/blob/master/src/gmime_iostream.cc
[1] http://the-ner.org/
[2] https://github.com/gauteh/astroid/blob/master/src/chunk.cc#L137


Cheers, Gaute


Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_540ffd23a9176_53cd3ffb4d3fb2bc2852c3";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list


----==_mimepart_540ffd23a9176_53cd3ffb4d3fb2bc2852c3
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

messagecontent.

---
Reply to this email directly or view it on GitHub:
https://github.com/sup-heliotrope/sup/issues/326#issuecomment-55080027
----==_mimepart_540ffd23a9176_53cd3ffb4d3fb2bc2852c3
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p>messagecontent</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br>Reply to this email directly or <a href="https://github.com/sup-heliotrope/sup/issues/326#issuecomment-55080027">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/56827__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyNTk1MzE4NywiZGF0YSI6eyJpZCI6NDIwNDY3OTZ9fQ==--81335445e04e60c40309a26418c095a0a3c8c1e8.gif" width="1" /></p>
----==_mimepart_540ffd23a9176_53cd3ffb4d3fb2bc2852c3--
Comment 1 Gaute Hope 2015-02-12 18:41:41 UTC
The code parsing line is now at: https://github.com/gauteh/astroid/blob/master/src/chunk.cc#L145
Comment 2 Gaute Hope 2015-04-11 11:38:06 UTC
It seems this was a bug in my implementation, closing.