A Prettier JavaScript Formatter

Post by Manishearth » Wed, Jan 11, 2017, 2:56 AM UTC

Strom wrote: post #108

pcwalton wrote: post #36

Earlier quoted context omitted.

gofmt doesn't solve the hard problem that this blog post (and Wadler's paper) is about. From the article: "There's an extremely important piece missing from existing styling tools: the maximum line length." gofmt's decision to not bother to require a line length may work somewhat for Go (which tends to encourage short lines by virtue of lacking expressiveness), but it doesn't work for lots of other languages, includi…

The fact that gofmt doesn't enforce some arbitrary line length is a blessing. I have a modern widescreen monitor and I use a maximized window text editor. I have no problem with 200 char length lines. I'm more easily annoyed by 80 (or 60, like in this case) char limits, as if I was viewing this code on punch cards.

Post by pcwalton » Wed, Jan 11, 2017, 3:04 AM UTC

Strom wrote: post #108

pcwalton wrote: post #36

Earlier quoted context omitted.

gofmt doesn't solve the hard problem that this blog post (and Wadler's paper) is about. From the article: "There's an extremely important piece missing from existing styling tools: the maximum line length." gofmt's decision to not bother to require a line length may work somewhat for Go (which tends to encourage short lines by virtue of lacking expressiveness), but it doesn't work for lots of other languages, includi…

The fact that gofmt doesn't enforce some arbitrary line length is a blessing. I have a modern widescreen monitor and I use a maximized window text editor. I have no problem with 200 char length lines. I'm more easily annoyed by 80 (or 60, like in this case) char limits, as if I was viewing this code on punch cards.

Post by flukus » Wed, Jan 11, 2017, 3:16 AM UTC

Manishearth wrote: post #112

flukus wrote: post #109

Earlier quoted context omitted.

Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space.

Theoretically, an editor could. I have yet to see one that does this well. Most do dumb wrapping, with no language sensitivity. I think it's just a matter of programmer habit now -- folks expect their editor to mirror the code without formatting tweaks. It gets confusing when you realize that programmers may insert their own indentation and wrapping, and sometimes you want to make this part of the actual file, and so…

Post by flukus » Wed, Jan 11, 2017, 3:17 AM UTC

pcwalton wrote: post #114

flukus wrote: post #109

Earlier quoted context omitted.

Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space.

> Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space. Because making the line wrapping nice requires deep syntax-aware editor integration. Most languages try to be at least somewhat plain-text-editor-friendly.

Post by masterj » Wed, Jan 11, 2017, 3:30 AM UTC

nailer wrote: post #55

This is awesome, but one request: can you please extend it into a real (ie, AST based) diffing tool? Current diffing tools all compare the text (which is basically an input format) rather than the AST, and hence end up focusing on formatting rather than actual changes.