GNOME Bugzilla – Bug 527669
[ARITH] Thousands seperator and radix functionality is FUBAR
Last modified: 2008-07-17 08:47:47 UTC
As evident by the number of bugs relating to it... What's been going wrong (may not all be valid): - Pasting in numbers with thousands separators can cause problems - The lexer/parser don't seem to support UTF-8 but the separator/radix can be. - The lexer/parser doesn't know what the thousands separator is (no localisation) - The localize_number() function was designed for numbers, not expressions (which contain multiple numbers) - The numbers after the radix shouldn't have thousands seperators - The radix and separator get mixed up e.g. "1,234.567.001" - Changing the menu setting doesn't take effect - The separator is hard coded to 3 digits (?) - separator is sometimes spelt "seperator"
The majority of these are now fixed in 2.22.2: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2072 Remaining issues: - Doesn't support UTF-8 (screws up in cs_CZ.UTF-8) - Still does 3 digits (but has stub function for changing)
*** Bug 300363 has been marked as a duplicate of this bug. ***
*** Bug 402473 has been marked as a duplicate of this bug. ***
*** Bug 516002 has been marked as a duplicate of this bug. ***
*** Bug 523349 has been marked as a duplicate of this bug. ***
*** Bug 524746 has been marked as a duplicate of this bug. ***
Updated to remove memory leaks and re-separate when editing numbers: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2072 Another ongoing problem - the cursor moves when the separators are added/removed
The fix makes gcalctool working again in cs_CZ.UTF-8 locale. But one minor issue remains: Type 1.5 or 1,5. Display shows: 1,5 Press Enter. Display shows: 1.5 Press Enter. Display shows: 1,5 Press Enter. Display shows: 1.5 I. e. decimal point periodically changes between "," and ".".
Patch to use correct radix when converting results to strings (fixes Stanislavs problem): http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2078
There are probably still radix bugs here: bob@alchemy2:~/svn/gcalctool-5.22$ find . -name '*.[ch]' | xargs grep "'[.]'" ./gcalctool/display.c: if (*optr == '.' || *optr == *lnp) { ./gcalctool/functions.c: if (v->pointed && !(strchr(v->display, '.'))) { ./gcalctool/functions.c: v->pointed = (strchr(v->display, '.') != NULL); ./gcalctool/gtk.c: if (strchr (lang, '.')) { ./gcalctool/parser.c: if (l == '.' ||
Fixed typo: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2079 Convert localized UTF-8 radix and separator characters into english equivalents since the parser is 8-bit and not localized http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2080 These two patches now mean cs_CZ.UTF-8 without any problems for me.
Still not correct. export LANG=cs_CZ.UTF-8 gcalctool Now type: 1234,56(1234,56+1234,56) Then put cursor between "6" and "(" and press "/". Expected result: 1 234,56/(1 234,56+1 234,56) Actual result: 1 234,5/6(1 234,56+1 234,56)
Sorry, I meant to say the crashing bugs are fixed but the separator bug is outstanding. It is fixed now... http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2085 ...but not in cs_CZ.UTF-8. This is due to Gcalctool using an internal ASCII representation and not handling the UTF-8 separator correctly. This will be fixed in 2.24 (bug 530532). Regarding the separation of 3, I can't seem to find how to get this out of nl_langinfo->grouping. Is it a POSIX standard? I plan to close this bug with a known problem with the cursor in UTF-8 locales. I will support a patch that fixes it but my time is best spent fixing it properly in 2.24.
another bug on lp: https://bugs.edge.launchpad.net/ubuntu/+source/gcalctool/+bug/224435 "Try entering 2e+34 and see what you get. I'll try to upload a screenshot if possible." result is: 2,0,0,00,,000,,00,0,0,00,,000,,00,0,0,00,,000,,00,0,0,00,,000
I think the most stable solution is to use the english separator/radix (',' and '.') if nl_langinfo returns a non-ascii string. I'll make this change for 2.22.2 and then close this bug. Support for non-ascii locales will return in 2.24 (via bug 530532). Clarifying: The Gcalctool head after revision 2085 (see comment #13) should work correctly for all ascii compatible locales including fixing the problem you have reported Pedro. Any independant confirmation would be most welcome :) After making the change mentioned in this comment non-ascii compatible locales should work but may not localize the thousands separator or radix. Correct behaviour: - Thousands separators are displayed in the correct position using the locale specific version if possible. - The GCalctool parser can process the display in all locales. - Thousands separators can be enabled/disabled. - Editing the display with the cursor not at the end causes the thousands separators to be updated correctly and the cursor to remain in the correct location. - Pasted text in the correct locale can be solved correctly.
Final fixes for 5.22.2: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2101 Also fixed in head: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2102 It turned out the big problem was the thousands separator would default to ','. In the case of a locale where this was used as the radix and no thousands separator was defined (e.g. cs_CZ) then both radix and thousands separator would be the same and confuse the gcalctool code. It now correctly handles no thousands separator being defined. Fixed and released.
*** Bug 538755 has been marked as a duplicate of this bug. ***