The basic algorithm for the indentation level is to use the starting column position when the object is printed. I think what's happening is that gensym numbers are going to 2 or 3 digits: var foo1 = { blah: 1, foo: 2, }; var foo12 = { blah: 1, foo: 2, }; I don't think that's what's happening in your case though. There are two variables that control whitespace: *indent-level* and *column*. If *indent-level* was off, that would show up right away and be easy to spot, so it has to be *column*. If you can come up with a test case, I'd like to see it. Since there's no guarantees about whitespace and formatting changes, there is a function ps-test::normalize-js-code that normalizes all whitespace to single spaces for the output tests. You can use that for your test code. Vladimir On Sat, Sep 15, 2012 at 6:40 PM, Daniel Gackle <danielgackle@gmail.com> wrote:

There seems to be some state in the PS compiler that changes its mind about how much indentation to use when printing an object literal over multiple lines. That is, when I change some PS code and recompile it, the indentation in unrelated areas sometimes changes, and when I reload PS, it goes back to the way it was. This makes it hard to do regression comparisons on the generated JS.

I'm not quite sure how to formulate a test case for this, so am hoping the above description will trigger whatever insight is needed for a fix.

Daniel

_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel