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!
This may (or may not) give a nicer look and more clear understanding of
how the input was interpreted.
Looking for feedback from @mintsoft on whether or not this is actually
better. (Take a look at the test changes in particular to see the
effects.)
Also, minor updates to Conversions to make it work there.
NB: This is clearly not properly factored, yet! This is the first step
to get feedback and improvements from @mintsoft.
- Make number style stuff aware of how to deal with case-insensitive
expoentials.
- Produce consistent output of such strings.
The display format was chosen to be consistent with the output for
Calculator. Also, the parsing is not quite correct as you can't have a
mantissa in the exponent, but this won't catch that.
Should we also do "for_display" on the factors for consistency?
Any and all feedback or improvements are appreciated.
This also breaks the Calculator tests, but I will worry about fixing
those once everything stabilizes.
This one is much harder to hit, because the dotted quads must have 3
digits in each of the last 3 positions and they tend to start zero-ing
the mask earlier, but might as well cover this better, too.
Thanks to @mintsoft for the heads-up.
If we get a dotted quad, slash and a number in the range of 0-32, it
seems more likely this is talking about network addresses, than trying
to do a calculation.
I, personally, think it's unlikely we ever should be dealing with dotted
quads, but I want to leave in the possiblity of a pasted-in euro-style
value.
Fixes#541.
This regex overreaches a bit, because query_nowhitespace doesn't
guarantee we'll see word-breaks exactly where we might expect. This is
sufficient for now, but this triggering needs a general rethink.
Addresses some concerns in issue #517.
This is triggering very often, and it's probably best to limit the trigger word to "reverse text". It triggers with:
- "reverse dns 8.8.8.8."
- "reverse parameter sniffing"
- 'put car in reverse'
Matt Miller
Rob Emery
Jag Talon
Zaahir Moolla
DavidMascio
Usman Raza
gdrooid
jagtalon
David Wilkins