Remove unnecessary patterns

[jamesplease]

Weird testing artifacts

what?

A build system like grunt or gulp could help out here.

eval

Oh goodness... Eval is all over this library! Why!

[dpvc]

It is very valuable to us to be able to run both the unpacked and the packed code. For example, the packed version is all one long line, so browsers can't report the location of error messages very well, and we often ask page authors to run the unpacked version in order to obtain better debugging information. Also all the development is on the unpacked version, and it is much easier to run that than to have to perform the packing and combining after every edit before you can test it. The font information is common to both the packed and unpacked versions, and is not duplicated (since it is large); since the unpacked version is one directory level below the packed one, in order to access the web fonts, the unpacked version needs to use a different URL from the packed version. The two lines you point to are what make that possible, and are essential to being able to use the packed and unpacked versions interchangeably. They are not testing artifacts.

In terms of eval(), I think "all over this library" is a bit hyperbolic. There are three places that eval() is used: its primary use is to process the configuration blocks stored in the <script type="text/x-mathjax-config"> scripts. There is also an initial call to eval() to test whether it runs in the global namespace or not. Finally, it is used in callbacks that are given as literal strings, but MathJax doesn't use those internally, so that would only occur if the page author used that functionality.

So eval() is really only used to perform configuration code. In v2.3, we added the var MathJax = {...} configuration method to make it possible to do in-line configuration without eval(), so even that use can be avoided. In v2.4 (now in beta), the initial call to eval() is postponed until MathJax needs to perform an eval(), so you can use MathJax without any invocations of eval() at all.

If you are referring to the new Function() calls, note that these are all performed on string literals (except for two places, see below), so do not pose a security risk. See issue #256 for details about why this was done. The two instances that aren't string literals are for a configuration option that was never used (and is removed in v2.4), and in code that makes it easier to access the super class of an object; it turns out that this is never called by MathJax, so the only cases actually used are the string literals.

Finally, note that the new Function() calls have been replaced by function closures in v2.4.