I've pushed a patch that reverts pretty-printing except for object literals. Let me know if anything else looks weird.
Vladimir On Mon, Apr 2, 2012 at 10:37 PM, Daniel Gackle <[email protected]> wrote: > < What does everyone think of just trying to pretty-print object > literals with multiple members > > > Pretty-printing those and whatever JS calls its (foo(), bar()) > PROGN-like thing would be the sweet spot. I'd assume the printing > logic would be very similar in both cases. > > > > On Mon, Apr 2, 2012 at 1:09 PM, Vladimir Sedach <[email protected]> wrote: >> >> Pretty-printing is sort of hackish - there's not really any lookahead >> or backtracking, which is why the first example situation happens. >> >> Maybe that whole approach should be scrapped. What does everyone think >> of just trying to pretty-print object literals with multiple members? >> (Before, all the key:values were printed on one line) >> >> Vladimir >> >> On Fri, Mar 30, 2012 at 2:42 AM, Daniel Gackle <[email protected]> >> wrote: >> > I've been trying to upgrade our PS version and have some problems to >> > report. This email concerns issues with the changes to the printer in >> > commit 60154a. Accordingly, the code samples below need to be >> > formatted in a fixed-width font to be readable. Also, they're all in >> > JS rather than PS for obvious reasons. I can provide the corresponding >> > PS forms if desired. >> > >> > First, a simple for loop used to be printed like this: >> > >> > for (var n = 0; n < 10; n += 1) { >> > blah(n); >> > }; >> > >> > is now: >> > >> > for (var n = 0; n < 10; >> > n += 1) { >> > blah(n); >> > }; >> > >> > Not sure if that was intended, but it's so nonstandard that I can't >> > bear to look at it. If one were going to put line breaks in the for >> > loop declaration, surely there ought to be a line per clause rather >> > than an arbitrary break between the second and third. But three lines >> > is too many and anyway the whole thing is weird; it really belongs >> > on one line. >> > >> > Second, there seem to be bugs in how expressions in a comma-delimited >> > list are line-separated and indented. Apologies for the contrived JS >> > here, but I have to make the lines long enough to trigger an >> > indentation. Code that used to be in one line like this: >> > >> > var obj = (obj3433 = { }, (obj3433.foooooooooooo = >> > 'oooooooooooooooooooooooooooooooo', obj3433.baaaaaaaaar = >> > 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433)); >> > >> > is now being indented like this: >> > >> > var obj = (obj3433 = { }, >> > (obj3433.foooooooooooo = >> > 'oooooooooooooooooooooooooooooooo', >> > obj3433.baaaaaaaaar = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433)); >> > >> > I like the idea, but it seems the third (and any subsequent) lines >> > ought to be aligned with the second. >> > >> > Here's a real example of the same problem from our code: >> > >> > var bucket = (g4 = m1 - sol[label], >> > (g5 = m2 - sol[label], >> > (g6 = rcplus === 'col' ? rect3437[0] : rect3437[2], >> > (g7 = rcplus === 'col' ? rect3437[1] : rect3437[3], >> > rc === 'col' ? [g4, g5, g6, g7] : [g6, g7, g4, g5])))); >> > >> > There are other more complex examples of nested grouped expressions >> > that are coming out pretty strangely: >> > >> > var sh = ( >> > obj3439 = { markup : packIgrid(markup), tiling : >> > csh.tiling, >> > ultc : ultc, >> > ultr : ultr }, >> > ( >> > (g3 = (it = csh.coldeltas, it != null && it !== false ? xcopy(it) : >> > null), >> > g3 != null ? (obj3439.coldeltas = g3) : null), >> > ( >> > g4 = (it3440 = csh.rowdeltas, >> > it3440 != null && it3440 !== false ? xcopy(it3440) : null), >> > g4 != null ? (obj3439.rowdeltas = g4) : null), >> > obj3439)); >> > >> > It does seem like a good idea to not have all this on one line, but >> > it's far from clear what the indentation policy is. >> > >> > Similar inconsistencies afflict curly braces: >> > >> > queueMsg(brl, { >> > acknowledge : true }, mailbox); >> > >> > or: >> > >> > return ss.appointmentTicket = { col : c + (cols || 0), >> > row : r + (rows || 0) }; >> > >> > and here's a monster one: >> > >> > var REGRESSIONS = [{ type : 'js', target : 'ff', file1 : 'f1', file2 : >> > 'f2' >> > }, { >> > >> > type : 'js', >> > >> > target : 'ie6', >> > >> > file1 : 'ie61', >> > >> > file2 : 'ie62' }, { >> > >> > type : 'js', >> > >> > target : 'ie7', >> > >> > file1 : 'ie71', >> > >> > file2 : 'ie72' }, { >> > >> > type : 'js', >> > >> > target : 'ie8', >> > >> > file1 : 'ie81', >> > >> > file2 : 'ie82' }, { >> > >> > type : >> > 'js', >> > >> > target >> > : >> > 'safari', >> > >> > file1 : >> > 'saf1', >> > >> > file2 : >> > 'saf2' }, { >> > >> > >> > type : 'js', >> > >> > >> > target : 'chrome', >> > >> > >> > file1 : 'chr1', >> > >> > >> > file2 : 'chr2' }, { >> > >> > >> > type : 'js', >> > >> > >> > target : 'node', >> > >> > >> > file1 : 'n1', >> > >> > >> > file2 : 'n2' }, { >> > >> > >> > type : 'html', >> > >> > >> > target : 'ff', >> > >> > >> > file1 : 'hf1', >> > >> > >> > file2 : 'hf2' }, { >> > >> > >> > type : >> > 'html', >> > >> > >> > target >> > : >> > 'ie6', >> > >> > >> > file1 >> > : >> > 'hie61', >> > >> > >> > file2 >> > : >> > 'hie62' }, { >> > >> > >> > >> > type : 'html', >> > >> > >> > >> > target : 'ie7', >> > >> > >> > >> > file1 : 'hie71', >> > >> > >> > >> > file2 : 'hie72' }, { >> > >> > >> > >> > type : 'html', >> > >> > >> > >> > target : 'ie8', >> > >> > >> > >> > file1 : 'hie81', >> > >> > >> > >> > file2 : 'hie82' }, { >> > >> > >> > >> > type : 'html', >> > >> > >> > >> > target : 'safari', >> > >> > >> > >> > file1 : 'hsaf1', >> > >> > >> > >> > file2 : 'hsaf2' }, >> > { >> > >> > >> > >> > >> > type : 'html', >> > >> > >> > >> > >> > target : 'chrome', >> > >> > >> > >> > >> > file1 : 'hchr1', >> > >> > >> > >> > >> > file2 : 'hchr2' }, { >> > >> > >> > >> > >> > type : 'css', >> > >> > >> > >> > >> > target : 'chrome', >> > >> > >> > >> > >> > file1 : 'c1', >> > >> > >> > >> > >> > file2 : 'c2' }, { >> > >> > >> > >> > >> > type : 'css', >> > >> > >> > >> > >> > target : 'ie8', >> > >> > >> > >> > >> > file1 : 'ie1', >> > >> > >> > >> > >> > file2 : 'ie2' }]; >> > >> > I have some respect for how much harder this problem is than it >> > appears to be, having worked on similar issues for our Numen REPL and >> > not being too happy with what I came up with. That being said, these >> > changes to the printer probably make the JS less readable in our case >> > rather than more readable. It would be better to do less and have it >> > be consistent. At a minimum, I hope we can fix the more indecorous >> > areas. >> > >> > Daniel >> > >> > >> > >> > >> > _______________________________________________ >> > parenscript-devel mailing list >> > [email protected] >> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >> > >> >> _______________________________________________ >> parenscript-devel mailing list >> [email protected] >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > > _______________________________________________ > parenscript-devel mailing list > [email protected] > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > _______________________________________________ parenscript-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
