GNOME Bugzilla – Bug 402473
[ARITH] Problems pasting back value when using thousands separator
Last modified: 2008-04-12 08:05:14 UTC
This bug was filed in the Debian BTS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408940 This bug happens when using a locale with a space for thousands separator such as french or swedish. Type 10000, press calculate result. 10000 turns into 10 000. Copy the value. Press add, paste the value. Pressing calculate results in a warning about malformed expression. While trying to reproduce this bug, I found another similar issue. This happens when using en_GB. Type 10000, press calculate result. 10000 turns into 10,000. Copy the value. Press add, paste the value. Pressing calculate results in a value of 10,010, obviously wrong.
Bug confirmed.
Created attachment 81959 [details] [review] Patch to hopefully fix the problem. Sven, could possibly try the following patch and see if it fixes the problem for you please? You can get a source tarball for latest released gcalctool at: http://ftp.gnome.org/pub/GNOME/sources/gcalctool/5.9/ Thanks.
Hi, Seems to work great, both the bugs I described are gone and things works as you would expect. Thanks!
Thanks Sven. I've checked the changes into svn trunk/HEAD. There will be a new gcalctool release (v5.9.12) generated early next week.
I could still reproduce this bug in gcalctool 5.9.14. With LANG=de_DE, LC_MESSAGE=C: Enable Show Thousands Separator Enter 10000 Press = (result '10,000') Mark '10,000', copy it Press +, Paste '10,000' Press = (result '10,010') Mark '10,010', copy it Press +, Paste '10,010' Press = (result '10,020.01') This looks realls broken, gcalctool seems to be able to use both , and . as decimal point at the same time...
I installed German language files and reproduced the problem using the steps above in comment #5. Reopening bug. One slight difference. In the final step I got "10,020" as the bogus result.
I've verified that the get_proc() routine in gtk.c is returning the correct value with LANG=de_DE, LC_MESSAGE=C. This is only a problem in the Arithmetic Precedence mode. Transferring to Sami for further evaluation.
The problem basically comes from the fact that gcalctool parsing is based on flex and bison. There is no localization support in flex. That is what we would need in order to really fix these problems. I have currently no idea how we could get a tokenizer with localization support.
Created attachment 86869 [details] [review] Partial patch to fix the remaining problem. Just so this doesn't get lost. Sami sent me the attached patch with the following comment: "I might have a suggestion after all. The bug 402473 might get fixed with two steps: 1. Allow tokeniser to include spaces into numbers. 2. Allow MPstr_to_num function to identify numbers with spaces (for example "10 000"). I have done step 1 (see attachement). I am not familiar with MPstr_to_num implementation. Are you able to do step 2?" This needs to be investigated further.
I've merged all the thousands separator bugs into bug 527669 with a recent patch that appears to have fixed most of these problems. Thanks if you took the time to make a patch, I reviewed them but unfortunately none of them fixed all the problems simultaneously. Please test the patch and raise any issues in the new bug. Thank you. *** This bug has been marked as a duplicate of 527669 ***