#422 joe ignores fractional part of numeric literals in some locales
In all locales where the decimal point is different from a dot (".") character, joe ignores the fractional part of floating-point numbers in the "math" command.
The reason is a locale-dependent error how the function joe_strtod() in source file joe/umath.c parses floating point literals.
For example, if invoking joe as
$ LC_NUMERIC=de_DE.UTF-8 joe
assuming this locale is installed, then both of the following [Meta]+[m] math commands
=3.14:ins
=3,14:ins
will insert the string "3" rather than "3.14" or "3,14".
The bug is triggered as follows: joe_strtod() first tries to parse the digit string ignoring the locale and always expecting "." to be the decimal point.
But after successfully parsing a digit string like "3.14", it calls the strtod() function for converting it into a floating-point number.
However, strtod() does honor the current locale, and will therefore expect "," as the decimal point when using the beforementioned locale.
As strtod() does not find any "," in "3.14" and does not consider "." to be a valid part of a floating point number, it just parsed the "3" part and leaves the ".14" as unparsed text following the number.
I have attached a patch which fixes the problem in the least intrusive way I could figure out.
I'm trying to figure out if using "," in place of "." is a good idea even in locales where that's the norm. I guess the problem I have with it is that this is not done in programming languages so I'm not sure it's a good idea in JOE's "math". Hmm.. well I just tried it in Libre Office and it does use "," in de_DE.utf-8.
I don't think so.
This is why my patch does the opposite and allows to use "
." as decimal point even in locales where "," is normally the decimal point.The problem is that without the patch, the "
." does not work as a decimal point. In order to demonstrate what I mean, invoke joe as follows:Once
joehas launched, press[Alt]+[m]to enter Math mode and evaluate "sum".The result will be just "
3", not "3.14" as expected.With my patch, the result will be "
3.14" as if an English locale had been used although this is not the case.Exactly. Microsoft tried this once in Excel 4 or 5. In the German version one had then to write something like
instead of
This looks awful even for someone who is a native German speaker. Everyone is used to programming languages having English keywords!
Also note that using "
," as the decimal point required changing the comma as an argument separater also to something different, in this case to ";".It was a big mess and not helpful to anyone. Microsoft reverted to using English keywords with the next version of Excel.
Besides, translating English keywords to a familiar language is not as helpful as one might think.
There are only a dozen keywords or so in every programming language, and it is much harder to remember what the keywords actually do rather than how they are spelled.
Summing up, I think it would be best if
joecontinued to only support English operators, keywords and punctuation symbols in math expressions.A different question however is how to handle marked text in edit buffers which is processed by math operators such as "
sum".The easiest and a perfectly acceptable solution would be to not change anything (except for applying my patch to fix the problems shown above): In this case,
joe's math functions only work on numbers formatted according to an English locale.People can deal with that. Not every program supports
LC_NUMERICor locales at all.When using sum() on a table of numbers within a German document, one can use
[Ctrl]+[k],[\]to filter the table trough the external commandtr ., _.which would transform something like German "
1.234,56" into "1_234.56", then execute "sum", and then revert the changes made by "tr".It is a bit more work for the user, but quite doable.
Of course, the perfect solution would be if
joe's expression evaluator checked where the numbers came from.If they are a literal part of the math expression itself, the numbers should be expected to be formatted according to an English locale.
But if they are taken from the edit buffer by a function such as "
sum", the decimal point of the current locale should be replaced with "." and the thousands separator of the locale should be replaced with "_" beforejoe's math evaluator processes the numbers. This will convert the numbers from the edit buffer into the numeric formatjoe's expression evaluator currently does expect.Note that
joe's existing code does not need to be changed for the opposite direction: If evaluating "atan(3)" or "atan(3):ins", the result is already displayed or inserted according to the current locale. The C library functions used byjoefor formatting the result as a numeric string already take care of that.Also note that those changes would be beneficial even for users of an English locale. For instance, currently
$ echo 1,000.25 5.25 | LC_ALL= LC_NUMERIC=en_US.UTF-8 joe -returns "
6.5" as the result of the math "sum" function, because joe expects "_" as the thousands separator but the en_US locale dictates it to be ",".With the suggested changes of a "perfect solution", the result would have been "
1,005.50" instead.I also would suggest not to change the underscore as the thousands separator in
joe's math expressions, because I find it to be much more readable than ",".BTW, the difference between the numeric categories of the English and German locales is as follows:
So basically, "
," and "." have been exchanged, while everything else is pretty much the same.Because the "perfect solution" is not necessarily required and would require more changes in
joe's existing code, I would suggest to incorporate my patch (or functionally equivalent code) as the first step.This will
joemake work in all locales correctly with numbers formatted according to an English locale.In a later revision, the code might be extended some day to treat numbers from the edit buffer differently than numeric literals in math expressions, leading to the "perfect solution".
But this would clearly be a feature enhancement, while my current patch is just a bug fix.
Ah, OK, read too fast. Also, reproducing the bug didn't work for me initially (in Ubuntu 22.04)- I had to run "locale-gen de_DE.UTF-8" first (then it shows up in "locale -k LC_NUMERIC").
Anyway, I see some solutions involving uselocale, but unfortunately it's not universally available.
For the number format in the edit buffer, we probably need Ctrl-T options. What often happens with me is that inserted numbers with underscores are not often acceptable. Also, comma is bad news because it's often a separator.