utf8::all bails out when autodie is < 2.11. Adding cpanm autodie will pull in the latest version and duckpan DDG should work for Perls 5.1 and 5.16 then.
Eval of '! + 1' returns an empty string, so we'll make it less likely
for that to happen (by not initializing tmp_result to an empty string)
and guard against it if it still does.
Of course, this shouldn't trigger on '! + 1', so that still needs to be
resolved.
Since these act like a command, it makes sense to have it at the start
only. This is also in line with the triggers for the very similar
lowercase IA.
Attempt to address issue #578.
This is a port of the previous tests for these functions, updated for
its new status as a role. I can be convinced that this is not the best
way to do this, but it seems well-enough to me.
Basically, we're only going to recognize negative numbers when they
appear at the beginning of an expression. Otherwise we assume we don't
needs to deal with them.
I'm sure this causes other problems, but resovles the testing issues for
now.
This allows for us to continue to style negative numbers, but to assume
that "embedded" `-` characters are atually operations.
It's quite an ugly hack.. and this whole quasi-state machine needs
revisited, but this gets everything working for now.
This uses Bit::Vector rather than presuming anything about the perl
support for 64-bit ints. This seems safer, even if it's a smidge slower.
This fixes issue #564 with test demonstrating such.
By extension, this also permits negative exponents.
Also breaks a calculator test with a crazy expression where we can't
differentiate between subtrction and negative numbers. Leaving it
broken for now, since the tokenizing is known broken, anyway.
This also required some additional changes to how number_regex is
computed. That was sort of overdue, anyway.
HTML styling is simply display styling plus super-scripted exponents, at
thispoint.
The major change is matching the exponentials more carefully. They only
count if they have <number>E<integer> otherwise they won't work.
Also include a suggested change from @mintsoft to better handle the
spacing of numbers and units in Conversions, by separating them using
our defined regexes.
All-in-all, much more resilient!