only one use of it, in the case it was used for what the message is trying
to tell is the least concern (the system would be missing basic MIME data)
which means someone messed up at some level (shared-mime-info is required)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the output goes to the TTY and there is no rich text handler there, note
that the plain format for the "email" tag also contained entities (even
before the KuitSemantics reimplementation)
because the plain format for the "email" tag
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
not used in plain context, same as "p" in rich context. also now Katie will
detect the paragraphs as rich text
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
fun fact: there is CLDR data for ~1000 languages and only ~50 use different
number system (not "latn")
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
text with "<" in it is considered as rich text by Qt::mightBeRichText()
as special case. also entities are not markup and shall not be handled by
KuitSemantics (there is a class for that - KCharsets). entity is used
only in one place (kde-workspace/kate/part/view/kateviewhelpers.cpp) and it
does not even need special handling by KuitSemantics. so, instead of
slowing the whole markup parsing with redundant and unused feature I've
decided to not support it and even improve Katie's Qt::mightBeRichText()
function
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
is interesting how much simpler it can be by assuming that the tags are
strict and by using Qt::mightBeRichText() for the rich text detection.
while mostly compatible (entities are not converted, some tags were not
used and some even did not do anything) it is subject to optimization by
using QStringMatcher or other tricks (like using a separate tag for the
numbers precision)
overall - no regular expression matching, no XML parser is used and does
what the old implementation was doing but with less code. also passes
most tests (the exception is KLocalizedString test case that expect
entities to be replaced)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
otherwise KLocale::formatNumber() has to guess the precision that was
passed to KLocalizedString::subs() and make up a localized integer string
with a magic wand, the precision for precise number types (e.g. ulong,
qlonglong, etc.) remains -1
fixes KSignalPlotter test case failure
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
