One of the issues with our formatting engine is that it isn't really extensible. This is because we've done the following:
Most of these decisions were motivated by the fact that we wanted configurability of the formatter to be simple and inderstandable. Thus we thought of the UI and used that to determine how to architect the feature. However, the two needs are not mutually exclusive. It's quite possible to have a good simple UI that handles 95% of all cases, which still having a flexible core architecture.
Anson and i were thinking about how to support that kind of model. It seemed like a Cascading Style Sheet model might fit the bill. For example, say we have the following grammatical construct:
class-declaration: attributesopt class-modifiersopt class identifier class-baseopt class-body
One could see that modified (with some bastard form of XML/CSS as)
class-declaration: attributesopt class-modifiersopt <whitespace class=”single_whitespace”/> class <whitespace class=”single_whitespace”/> identifier class-baseopt <whitespace class=”no_whitespace”/> class-body
The idea being that you could mark every whitespace token between two tokens in the grammar with the default formatting rules you watned right there. The API would then allow for prorgammatic access and overriding of each of those rules. Now, when we did the UI and added the option “place open curly on new line” then that would actually end up affecting all of those atomic whitespace token rules specified in the formatting grammar.