Closed cfcs closed 9 years ago
this affects both directions - sending <foo>
should be html-escaped to <foo>
-- whereas on the receiving side html-unescaping should be done
...and this is already done for status messages... (but not for chat messages!)
also, annoyingly from xml stream I'm not here right now
get's into I;m not here right now
(in a presence message)
same happens for messages... I tend to think it is the xml parser thingy... (see #8, should be changed anyways)
Another annoying issue is that "<3" (very commonly used with my conversation partners for some reason!) gets shown as "<3", and, worse, don't show up in clients that do HTML parsing of messages. Not sure what the best course of action is. Perhaps a configuration entry for each contact to do HTML encoding/decoding?
Edit: Same decoding inconsistency is apparently an issue on Github, too.
@cfcs the issue of receiving ;3
has been solved in https://github.com/hannesm/xml/commit/4cc941e0dfa1082ebbc86e195bd17bf1ada8b013 , which I now included in xmpp-opam
repository... thus, opam update
followed by opam upgrade
should fix this (this is only for clear-text message so far, encrypted messages are still broken (<FONT>
and <3
))
now fixed with https://github.com/hannesm/jackline/commit/49f01a76f9245955d8bcf306b150244daa3de62c @cfcs @policecar
Thank you! Even tho i think those other clients shouldn't be sending html in the first place.
I thought so as well, but then gajim-otr and mcabber (calling into nohtml.c, and also remove tags and unescape (gajim as well), next to libpurple (no, I didn't look deeper into their source) were convincing enough to just implement the same behaviour..
Thanks!
Consider automatically stripping '' from the beginning of messages and '' from the end of messages so we don't have to look at libpurple's HTML crap. Perhaps this should be left in -- so users can tell people to stop using libpurple?