< 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
