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 danielgackle@gmail.com 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 parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel