[AceJohnny2]

"Amazingly, surprisingly, counterintuitively, the indentation problem is almost totally orthogonal to parsing and syntax validation. I'd never have guessed it. But for indentation you care about totally different things that don't matter at all to parsers. Say you have a JavaScript argument list: it's just (blah, blah, blah): a paren-delimited, comma-separated, possibly empty list of identifiers. Parsing that is pretty easy. But for indentation purposes, that list is rife with possibility!" -- Steve Yegge, 2008 [1]

That really struck me back then, and I've kept it in mind whenever I hear about code beautifying/indenting.

[1] http://steve-yegge.blogspot.com/2008/03/js2-mode-new-javascr...

[sklogic]

And yet, the best place to add your pretty-printing and indentation hints is parser. Hints are attached to the grammar, so it makes sense to merge the two things, and then generate two different tools out of the single source. Three, actually - an AST pretty-printer, a textual code formatter and, finally, a parser itself.

[eltaco]

There's an issue for a CST (AST with whitespace, comments, etc) in the estree repo [1]. JSCS is planning on using https://github.com/mdevils/cst for future autofixing rules.

[1] https://github.com/estree/estree/issues/41

[sklogic]

The beauty of this pretty-printing solution (merging it with the parser) is that you don't even need any parsing tree to be constructed. The parser will simply walk the stream and annotate it with the pretty-printing instructions (pushing an popping the indentation context, adding the weighted break candidates, etc.).