Editing Module:StripToNumbers/doc (section)

== Limitations (serious ones) ==
{{See also|Module:StripToNumbers/testcases}}
* '''When imput may contain a {{code|1=..=..}} character, use {{para|1|}} when calling the template.''' This never does any harm.
::So: when input is <code>a=70%</code> use <code><nowiki>{{#invoke:StripToNumbers|main|1=a=70%}}</nowiki></code> &rarr;
::{{#invoke:StripToNumbers|main|1=a=70%}}

* '''Otherwise,''' The input cannot contain the <code>=</code> character unless it is escaped as <code><nowiki>{{=}}</nowiki></code> or <code>&amp;equal;</code>.
** There may be other characters than <code>=</code> that must be escaped.

* At present, the module only does three things:
*# It finds the first contiguous number in the input string, which may be preceded by <code>-</code> (the keyboard hyphen-minus character, not the formal unicode minus <code>−</code>, and may contain a decimal; it throws away everything else. 
*# It checks that the result is a valid number (i.e. not something like <code>1.2.3</code> or <code>1-2-3</code>, nor null; this test may well be redundant code at this point, but better safe than sorry.
*# It optionally divides the number by two (in a separate function).
: Feel free to expand it to do more things (and to do what it does more robustly if you find a way to break it).  Please report problems on the talk page and ping regular editors of the module. It is safest in most cases to expand by adding functions rather than adding features to the <code>main</code> function.

* It will drop trailing zeros from the end of decimal.  It may be useful to add a feature to stop that behavior, so that it won't mess with currency formatting (this cannot reliably be done by removing the "is it really a number?" test, since invocation of the halving function will operate on the string as, and convert it to, a number not a string, and thus result in the truncation of mathematically redundant zeroes.

* It cannot handle <code>&#61;</code>-style character entities that are numeric (nor their hex equivalents), for obvious reasons, only named ones like <code>&equal;nbsp;</code>  This can be addressed in future upgrade, surely, but should be done in a separate function, as stripping such input down to the ASCII character numbers may well be the desired use in a particular instance.