elm-format (0.3.0-alpha)

[Aaron VonderHaar]

There are a lot of details to this release, so I'll start out with thanks to everyone who reported issues; to our new and continuing contributors @ento, @danyx23, @eeue56, and @mgold; and to the plugin maintainers @rundis, @benjick, @ajhager, and @Bogdanp.

And if you're in a hurry, here's the link: elm-format-0.3.0-alpha downloads and installation instructions

Elm 0.17 and 0.16 support

There are now two flavors of elm-format in each release: one for Elm 0.17, and one for Elm 0.16. You should download the one that corresponds to the version of Elm you are using.

But note that these two flavors are the same except that they have different default values for the new--elm-version argument. Downloading the correct flavor will make things easier for you, since your IDE plugins will work properly, but if you pass the --elm-version argument to elm-format, both flavors will behave identically. (This works because elm-format can parse both 0.17 and 0.16 files and can output either format regardless of which format the input was in.)

New features

• You can migrate your Elm 0.16 code to the 0.17 syntax simply by using the 0.17 flavor of elm-format
• You can validate the formatting of files with elm-format --validate (useful for CI scripts)

Changes and fixes

• 4-space indentation (see the next section)
• The first argument in function application is allowed to stay on the same line even if subsequent arguments break the line
• Decimal float and hexadecimal int literals are preserved
• The filename and line number is shown when reporting parse errors
• Added a workaround for an elm-compiler bug with escaping UTF-8 characters on Windows
• Newlines in function types are properly handled
• The commenting "trick" of having {--} and --} scattered around your file is not directly supported
• Fixes for comments
  • The contents of block comments does not indent itself further every time you format
  • Nested block comments are preserved
  • =-- parses correctly
• top-level declarations are now spaced properly in (hopefully all) cases
• All places = and : appear in the syntax are now formatted consistently

more details

4-space indentation

We've had several discussions of indentation width in the past, but the rationale for trying 4-space indentation again is here: https://gist.github.com/avh4/bc092cc2207230d044f73defdd46fd13

elm-format has been in alpha for a long time all ready, so apologies for drawing out this issue and making another significant change. If you have strong opinions in favor of 2-space indentation, I do want to hear them, but I would appreciate if you would first spend a few minutes considering 1) why you have those opinions, and 2) how you would convince someone holding an opposing indentation opinion.

Next up

If you have trouble installing elm-format to work with your editor, please file an issue or make a pull request to the elm-format README.

I'm hoping the next elm-format release will be beta-quality and ready to announce on elm-discuss. Thanks for all the feedback!

[Emilien Taque]

Just noticed from your gist that it doesn't change anything for html lists, so indeed that should be a painless change!

[ div
    []
    [ text "" ]
]

Great job and good communication on this (potentially trollish) subject, thanks folks.

[Peter Damoc]

Regarding the 4-space indentation. 

I have a preference towards 2-space indentation but I'm not attached to it. 
The main issue for me is consistency and I would love for my code to look like the one in elm-lang/core 
That code seams to use 2-space and I think that whatever the core uses should be the default. 

I'm bothered more by the fact that elm-format is using a default that's different from elm-lang/core than by de fact that it uses a default different from my preference.
I can switch to 4-space without much stress if that's the default in elm-lang/core

 

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAMZecXnpmrryB3fj-m-1GT4aka6YaFdBeANBoTZhJfb6%3D70xdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Gusztáv Szikszai]

I'm favoring 2 space mainly because every other language I use uses 2 space (Ruby, JS, Elixir). Is there a reason why this is not an option to choose with a default value? something like elm-format --spaces 2, it would really stop this discussion forever.

[James Wilson]

I'd never use 2 space indentation in JS - it's horribly hard to read imo - what indentation used in other languages is basically personal preference.

In haskell, I follow a style guide that tends to use 2 space indentation for things like let..in (and where) and 4 space otherwise, but I tend to be rather loose with my formatting as I often want to line things up etc, which is something I feel I bump into a lot more in haskell than most languages.

[ric...@ritsoftgh.com]

Having the same thought here. Can the number of spaces be specified as an option? In my case, 4 spaces is not an option.

[Aaron VonderHaar]

On Wed, May 11, 2016 at 1:43 AM, Peter Damoc <pda...@gmail.com> wrote:

I'm bothered more by the fact that elm-format is using a default that's different from elm-lang/core than by de fact that it uses a default different from my preference.
I can switch to 4-space without much stress if that's the default in elm-lang/core

Yes, I agree with this.  elm-format will need to be an accept for adoption by the official packages and the official documentation.  (Which currently is a mix of 2- and 4-spaces.)

[Aaron VonderHaar]

Hi Gusztáv,  can you say more about why having the same indentation width for all your different languages is important?

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/e2976d08-c054-4cca-a1d7-65395e52d2b7%40googlegroups.com.

[Aaron VonderHaar]

Hi Richard,  Can you say more about why 4-spaces is not an option for you?

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/ffcc0878-bb6b-41fc-a904-ce0548d3b6a9%40googlegroups.com.

[Nick H]

I too had a preference for 2 space indentation, but I read your gist and was soothed :-) Thank you for the well-thought-out explanation, and, of course, for all the work that goes into this fantastic project.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAMZecX%3DL_QFZOd%3DxTkLV1FC3s9pGrUre8BJGAKisdVyStrf41g%40mail.gmail.com.

[Simon Hampton]

I vote 4

[ric...@ritsoftgh.com]

Hi Aaron,

One has to do with the editor. It has been configured to map a tab to 2 spaces (office coding standard). This is for all languages. Once elm-format uses 4 spaces, editing the file becomes a bit unnatural. On the readability side, I've used 2-spaces for as long as I can remember (in javascript, typescript and F#). Only language currently using 4 space tab is C# but we're gradually moving away from it to F#. 4 space tab seems like a lot of empty spaces to travel to read code :)

-- very concise
view model =
  div []
    [ text "Something"
    , loginPanel.view model
    ]

view model =
    div []
        [ text "Something"
        , loginPanel.view model
        ]

That said, 2 space tab being the office policy does not mean it will be the same forever. It might be changed for a language or two if they feel the need to so it will help if it is a configuration. I can enjoy elm programming with 2 and move to 4 if need be.

[j weir]

2 v 4 – I have no vote. The most important thing is consistency.

And please, no configuration of the formatter.

Given the same blob of code it should always format it the same way.

This twitter stream on Rust's formatter might be enlightening: https://twitter.com/rakyll/status/720409803055435776

"Most people didn't like gofmt output either. It was no one's favorite. But time and growing familiarity fixed it" - Rob Pike

[Mike MacDonald]

2-space indents were chosen by popular vote, and I feel they improve scanability by keeping related things together.

Also, I do not understand holding consistency in quite so high a regard: I'd rather see a configurable formatter with a default of 2, than a formatter hardcoded to 2.

[Gabriel Florit]

I also prefer 2-space indents, but in my opinion this should be a configuration option.

[Nick H]

This isn't a vote. I don't know how people got that impression.

The pertinent part of Aaron's message, again:

If you have strong opinions in favor of 2-space indentation, I do want to hear them, but I would appreciate if you would first spend a few minutes considering 1) why you have those opinions, and 2) how you would convince someone holding an opposing indentation opinion.

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/e6b3dfc0-1b68-4403-a7ae-0c8d094c046d%40googlegroups.com.

[Franček Prijatelj]

Hi

IMHO discussion about  space indentation is pointless (everybody has it's own preferences),
So why don't you make it an option (like many other code formatting programs).
Maybe this way :

file settings.json :
{
   "space_indentation : 4,
   "optionx"   : "x"
  .....
}

BRGS
Franček

[j weir]

Having a canonical formatter which takes options makes it no longer canonical.

I like 3 spaces. You like 5 spaces.

We work on a project.

You format for 5.  I get your code, format it for 3, check it in.

No you say – use 5, format the code, check it in.

No I say – please use 3.

Now we have to decide what format to use. Our formatter has not solved a problem.

Having a single format, without options, sets this issue aside. 

We all use ElmFormat.  None of us love it, but we love it more than the alternative.

This is what 'go fmt' does.  No options – it works wonderfully.

[Petr Huřťák]

How about using tabs? With tabs you can set the indentation size in your editor without these problems.

[Brian Hicks]

Seconding j weir's opinion. The reason `gofmt` and other tools resolve conflicts is because they have a single unchangeable opinion—you either use the tool or you don't. The Rust community had a similar discussion recently, but I couldn't find a relevant link in a reasonable amount of time. For those thinking "surely configuration will solve this debate": no, it really won't. It's just pushing the debate from the people who have a considered opinion based on a lot of exposure to Elm to teams who are just adopting it, which could potentially harm their early usage.

As for the actual question at hand: at the moment, I use 2-space indention in Elm. I like it because it means my eye doesn't have to travel as much sideways, but I consider this a pretty weak argument in favor since I would certainly adapt to 4-space.

As a long-time Python user, 4-space indentation makes a lot of sense. If a file gets too wide, 4-space indentation gives off an earlier code smell that you're nesting too much. Consider also situations where you have a long case statement. With 4-space indentation makes it marginally easier to see when the current context changes, absent other syntactical clues. Of course you can see the next `case _ ->` but not always on a large monitor or in your peripheral vision.

However, I think the Go community did something right with tabs: they can be configured in your editor to display as whatever width you'd like, without polluting diffs the way other syntax wars typically go. Just an option to consider.

In the end, I think we should try and quickly resolve this and move on, even if we don't get 100% consensus. This really has the potential to be bikeshedded forever. For my part, I'm willing to defer to Aaron's best judgement as a library author and fellow user.

[Francesco Orsenigo]

Thirding.
No point at all having a tool for making all the code look the same if it doesn't make all code look the same.

Aesthetics is largely a matter of habit, of familiarity.
You like 2 spaces? Work 6 months on 4 spaces and you will start liking the latter more, and vice versa.
This is why consistency is important: so everyone gets familiar on the same thing.

[Gage Peterson]

I think this is a very good point. We largely like what we are used to. And if this is the case then the choice is arbitrary.

I also agree, no configuration!  The absolute best part of an auto formatter, I love a formater that rules with an iron fist essentially says, "All bikesheds must be blue!" and then we  can move on to the most important thing, making cool stuff. I really hope it gets stable enough that it can shipped with the compiler. That has worked out ever so well for golang.

[Irakli Gozalishvili]

Please do not allow configuration, I also prefer 2 spaces over 4, but would rather use 4 than have code using several styles.