First and foremost, this is a pretty printing problem, something that absolutely must reverse correctly. Initial implementations should focus on that more than the complexity of heuristics. Ideally it would not change any order of tokens as then it would cause reversal to be non-trivial. If the tool makes a line comment at end of line from comma last to comma first, it should not move the comment in terms of tokens. If it looks ugly from the pretty printer it is still significantly better than causing the chaos of errors in reversing pretty printing due to moving tokens.
As for the line break issue, if you are breaking lines up, the determination of where the lines end is a complex choice that can be determines after a basic algorithm is in place. Ideally all the possibilities you mentioned would end up as configuration options. Backtracking should not be terrible since lengths of subtrees can be examined rather than on a token level: x + (y + z) + 1 Could be configured to be treated as: x + a + 1 Still, the basic algorithms I mention are starting points. Much like JSHint, configuration is king in this area not having overly complex heuristics (unless you want to add that yourself plus the configuration options, in which case more power to you). On Friday, May 4, 2012 8:56:26 AM UTC-5, Thom Blake wrote: > > > > On Thursday, May 3, 2012 11:57:14 AM UTC-4, Bradley Meck wrote: >> >> AST Generation w/ Comments : http://esprima.org/ >> >> Awesome. Will check that out posthaste. > > >> Line breaks: >> - if indent < length >> - - indent or no indent on line break (configurable / amount) >> - - operator at end of line (to avoid ASI confusion / make the formatting >> easier to generate) >> - if indent + minimal text > length >> - - throw warning, treat same as above >> >> > One problem with this is that there isn't an obvious place to break really > long lines. For example, if you have a line like > apple().banana().carrot().donkey().elephant().frog().grape().hornet().igloo().javascript().kitkat().lemur().monkey().nero() > > , you might choose to recursively break it at the most parent operator > until the lines are short enough, in which case you have one really long > line followed by a bunch of short ones, or you might choose to recursively > break it at the most child operator, in which case you have a bunch of > short lines followed by one really long one, or you might choose to break > it in "the middle" of the text line (say, about 40 characters), but then > you run into problems if the operators are nested differently and you've > thus chosen an unintuitive place to break the line. For example, the > following seems to confuse order-of-operations: > > apple() * banana() * (carrot() + donkey() * > elephant() + frog()) + grape() > > Also, depending on indentation style, it might be difficult to figure out > how much to indent until you've actually broken the line, and so the > algorithm will probably have to try and backtrack a bunch of times to get > it right, unless information about indentation style can somehow be > represented as part of the main line-breaking algorithm. > > And insisting operators go at the end of lines doesn't work either, as one > of the style options I'd like to have configurable is whether operators go > at the beginning or end of lines. Personally, I'd default to beginning. > > >> End of line comments: >> - Place them at same place token wise. >> - Treat same as comments inside of lines. >> >> > There are a couple of problems with that. Since pretty-printing the code > might change the positions of tokens, the position of the comment might not > end up at the end of the line. It might be okay to just turn it into a > multiline comment and leave it in-place, but it strikes me as probably the > wrong thing to do in most cases. Also, there are some cases where they > obviously should *not* stay in the same place in terms of tokens. For > example, if you have comments after items in a comma-separated list, and > change from comma-first to comma-last or vice-versa, the obvious thing to > do is invert the order of the comma and the comment, so that the comment > stays on the same line as the list item. But since that's a special case > that breaks that rule, it's not obvious that there are not myriad other > special cases. > > You could solve this, as some do, by just not using end-of-line comments > like that, but that's a style restriction and the point of the tool was to > *stop* style bikeshedding. > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
