Refactor/parseutil

[zorkow]

Refactors the ParseUtil module:

• Makes a Map out of unit conversion mapping and exports it. This makes it extensible
• Adapts all other constants to use the extensible map. (This is useful for the IEEE where they have a custom unit pi).
• Does not (yet) combine length functionality with the util/lengths.ts module (see my email from yesterday).
• Removes namespace and adapts all import statements in modules using ParseUtil. This is the majority of files!
• Adds some tests for this for all the length methods, that I have used during conversion. Note, these already uses pnpm. To run the tests, do

pnpm -r install
pnpm test

The tests are in a separate commit and can be removed.

[zorkow]

Since the indentation has changed on ParseUtil.ts it is best viewed with ignore whitespace.

[dpvc]

Overall, a good move. I have a few comments in a couple of areas, however. See what you think.

[zorkow]

@dpvc I've refactored the ParseUtil into a single object. Have a look, if that is really what you want.

The UNIT_CASES is now a bespoke class that can be used for similar mappings in lengths.
And there are a number of temporary elements, that should eventually move into lenghts.

[zorkow]

Also should this here

MathJax-src/ts/util/lengths.ts

Line 130 in 8565f9d

if (Math.abs(m) < .001) return '0';

not return 0em. The rounding function below does that. Then it would be the same as Em in ParseUtil.ts

[dpvc]

See my comments below about the ParseUtil object.

[zorkow]

I've created the single ParseUtil object now, making sure that only the previously exported methods are contained. I've did some caml case renaming as well.
PTAL.

[zorkow]

@dpvc If I understand correctly, you want to be able to make changes to ParseUtil functionality from the configuration options. How should be deal with this when (or if) we combine ParseUtil with lengths.ts?

[dpvc]

If I understand correctly, you want to be able to make changes to ParseUtil functionality from the configuration options.

In the sense that it can be altered via the startup.ready() function, yes. The idea being that if someone needs to patch one of the routines, they can do so and the modified one will be used everywhere.

I have wanted to be able to do this with other namespaces (like the startup namespace in ts/components/startup.ts), but have not bee able to. That is the main reason I have to turning these into actual objects rather than namespaces.

How should be deal with this when (or if) we combine ParseUtil with lengths.ts?

I'm thinking that length.ts should also be an object as well, rather than individual functions. That would make everything mutable. Does that answer your question?

[dpvc]

Looks good. I have one suggestion for saving some characters, but otherwise, ready to go.