GLSL Formatting support

[jjant]

Hey, it'd be great if elm-format could format glsl blocks and style them properly.

Have you thought about this, @avh4?

[avh4]

Yeah, I'd be open to adding this, though the formatting of a C-like language has quite a different style than Elm code, I think, so it might be quite a bit of work to define what the formatting should look like. I also haven't looked as the GLSL AST in detail, so I'm not sure how many cases there are that need to be handled before the formatting would be complete enough that it could be trusted to never make a change that would break a valid file. If this were added, I'd also want to look at examples of real-world code from folks using WebGL in Elm, so that the formatting is something that makes sense to them.

Personally, I probably won't get to doing this, but if someone wanted to work on defining the formatting, comparing it to the current best practices that folks using WebGL in Elm use, and starting to implement it, I'd be open to supporting those efforts.

[jjant]

I'm starting to take a look at this... how would you feel about using an external tool like glslx?

I guess at the very least we could use that as a base, seeing how it formats existing glsl code in elm codebases and gather opinions.

[avh4]

Yeah, briefly playing with it at the link you posted, the format it produces seems like it's pretty inline with elm-format's philosophy (removes extra whitespace, no autowrap at a predefined column, keeps most linebreaks).

[avh4]

FYI, you should also do new work off of the recursion-scheme-format branch; it's a big refactoring that's going to be merged soon.

[gampleman]

One thing to note and I'm not sure how important it is, but generally shader code doesn't get minified by external tooling particularly well (since it's just a string), so there is some incentive to keep shader code potentially quite minimal (if not exactly minified, potentially without extra whitespace, etc)