[Libreoffice-bugs] [Bug 123752] EDITING: Regression in handling of the group separator in formula context

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=123752

--- Comment #11 from Jouni Kosonen <bugz.j at tukesoft.com> ---
I think I see some of what's happening now. 

In i18npool/source/characterclassification/cclass_unicode_parser.cxx 
cclass_Unicode::initParserTable, KParseTokens::GROUP_SEPARATOR_IN_NUMBER isn't
on in nContTypes, but I don't know why. I can't seem to find where that bit is
supposed to be set.

This means that the cGroupSep code point doesn't get the ParserFlags::VALUE bit
set and is actually set to zero itself.

This then means that the code in cclass_Unicode::parseText handling cGroupSep
not only doesn't look at the right codepoint, it doesn't even get run because
it is conditioned on the ParserFlags::VALUE bit and the group separator is
handled as nMask ParserFlags::(VALUE_SEP | WORD_SEP | CHAR_DONTCARE). This
ssBounces the parser out of the ssGetValue state and the separator gets
reevaluated in a new ssGetChar state as nMask ParserFlags::CHAR_WORD. 

That would be why the value gets emitted as sequence multiple tokens instead of
a single parsed number. The numbers following the group separator get parsed in
the same ssGetWord state that started from the group separator. If the value
ends with a decimal part, that comma ends the word and gets evaluated outside
the parseText state machine and appended to the sequence.

TLDR: I get a working binary if I simply set the ParserFlags::VALUE bit on for
the group separator code point regardless of
KParseTokens::GROUP_SEPARATOR_IN_NUMBER being off in nContTypes, but that would
presumably have some other effect elsewhere.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190401/63d18522/attachment.html>