There are a number of issues and PRs that would benefit from having a plugin architecture:

• Add support for Persian & Arabic alphabet in text and eastern-arabic numerals + Proposal Commit Add support for Persian & Arabic alphabet in text and eastern-arabic numerals + Proposal Commit #729
• single or double dollar sign as formula delimiter single or double dollar sign as formula delimiter #712
• mhchem extension support mhchem extension support #50
• Cursor Cursor #506
• Class Class #507

There are certain functions we could expose:

• defineSymbol
• defineFunction
• defineEnvironment

defineSymbol is used for adding support for new symbols or new languages, but if the new glyphs require new fonts currently isn't a way to specify metrics for the new glyphs. We'd need to provide a way to extend the data stored in fontMetricsData.js.

defineFunction is used for adding new commands. Commands that define implicit groups will be hard to deal and since there aren't that many of them we should probably ignore them for now. A bigger problem is that any new function will also require code in buildHTML.js and buildMathML.js to generate the correct markup.

Currently, buildHTML.js and buildMathML.js are loose conglomeration of functions. The only functions that should need to be shared are buildGroup and buildExpression. The rest could exist in their own separate files.

I would like to propose grouping the parse node generation functions from function.js with functions from buildHTML.js and buildMathML.js into separate files based on group type. As part of this, we'd expand the responsibilities of defineFunction to add entries to the groupTypes objects used by buildHTML and buildMathML.

We'll want to minimize changes to the parse tree structure once we publish a public plugin API so we should make changes before doing so.