Please see the discussion at https://github.com/avh4/elm-format/issues/210. A fixed indent size is a feature, not a bug. Making a single tool that everyone uses is so nice. No need to mess around with .eslint files or the like.
It might have been fine if elm-format had chosen better defaults.
Go chose tabs over spaces which are configurable in your editor, so everyone wins. Elm has other awkward style choices, like 'comma-first', and excessive line-breaks in-and-around statements. If they had less obnoxious defaults, people might be less bothered about this issue.
And honestly, as a dev you work at a company for what, 3 months minimum. How hard is it to setup a .eslint file, vs. having to always write code in a style you don't enjoy.
Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.
The interesting thing to me is that you highlight how priorities are different among different people/companies; to me, choice of indentation spacing is trivial. But to you and the sibling comment, it obviously is not. And that's the point: a developer should be respected to decide what is important for their work. In this case, we are talking about indentation flexibility. But this problem scales throughout on many other issues that I might find important but you do not. Most languages give developers more freedom, even if starting out with a consistent default that everyone can understand first.
Elm is an opinionated language. The framework comes built-in. The tooling comes built-in. A clever language designer once said "there is only one way to do it". Elm is that, but at the language level. Elm-Format is opinionated, and for people who love Elm, they also love that.
> It might have been fine if elm-format had chosen better defaults.
Subjective. This is a time old discussion. Please read the linked issue.
> Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.
> You assume the OP is not actually using the language?
I'm making generalizations based on their statements -- the stats and anecdotal evidence tells us things about how the community at large.
> And yet you yourself said in another comment that you do not use the language.
Can you link that comment? I think you've gotten me confused with someone else -- I'm a very active member of the Elm community and write Elm as part of my day job and have done for over 2.5 years.
I'm not really making assumptions about their use, but more rather commenting on the feeling of the community as a whole. I basis this on my deep involvement and the stats that we have to hand. I know that Elm format is not considered an issue by a large majority of Elm users. In fact, I can only thing of a couple of people who dislike it. So while they might personally use Elm and dislike it, it is not representative of the community -- it's important not to spread FUD, as comments on HN often tend to. The people who are most vocal about elm-format being negative are those who have not actually used it outside of short trials.
Go chose tabs over spaces which are configurable in your editor, so everyone wins. Elm has other awkward style choices, like 'comma-first', and excessive line-breaks in-and-around statements. If they had less obnoxious defaults, people might be less bothered about this issue.
And honestly, as a dev you work at a company for what, 3 months minimum. How hard is it to setup a .eslint file, vs. having to always write code in a style you don't enjoy.
Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.