elm-format did something change?

[Rupert Smith]

I recently did a full upgrade and re-installed my whole system, including elm, atom and elm-format. I notice now that when I save files elm-format is giving a huge diff compared with what I had before, particularly around comments. A little example:

{-|

Username and password based login credentials.

-}

Changes to:

{-| Username and password based login credentials.

-}

Looking at the release notes, this is all expected. https://github.com/avh4/elm-format/releases

I am just wondering if I should update all public repositories that I maintain to match the latest version of elm-format? Otherwise we have to keep turning off elm-format-on-save to make nice diffs.

It also strikes me that working on multiple branches and upgrading them could also run into problems and potentially lose the ability to cleanly merge patches between branches. elm-format is awesome but big whitespace only diffs on mature codebases with multiple work streams are not.

[Rupert Smith]

On Tuesday, August 15, 2017 at 11:11:07 AM UTC+1, Rupert Smith wrote:

I recently did a full upgrade and re-installed my whole system, including elm, atom and elm-format. I notice now that when I save files elm-format is giving a huge diff compared with what I had before, particularly around comments.

Bugger. Latest (non-experimental) version also introduces compile errors...

> elm-make

Success! Compiled 11 modules.

> elm-format src/

...

> elm-make

 -- DOCUMENTATION ERROR ------------------------------ ./src/TypedSvg/Filters.elm



The following exports do not appear in your module documentation: blend
colorMatrix componentTransfer composite convolveMatrix diffuseLighting
displacementMap distantLight flood funcA funcB funcG funcR gaussianBlur image
merge mergeNode morphology offset pointLight specularLighting spotLight tile
turbulence


 3|>{-| SVG Filter Elements
 4|>
 5|>    Typical usage:
 6|>
 7|>        import TypedSvg.Filters as Fe
 8|>        import TypedSvg.Filters.Attributes exposing (..)
 9|>
10|>        Fe.filter []
11|>            [ Fe.blend [in InSourceGraphic, in2 InFillPaint, mode ModeMultiply] []
12|>            ]
13|>
14|>@docs blend, colorMatrix, componentTransfer, composite,
15|>convolveMatrix, diffuseLighting, displacementMap, flood, funcA,
16|>funcB, funcG, funcR, gaussianBlur, image, merge, mergeNode,
17|>morphology, offset, specularLighting, tile, turbulence
18|>
19|>
20|># Light source elements
21|>
22|>@docs distantLight, pointLight, spotLight
23|>
24|>-}

[Rupert Smith]

On Tuesday, August 15, 2017 at 11:18:23 AM UTC+1, Rupert Smith wrote:

On Tuesday, August 15, 2017 at 11:11:07 AM UTC+1, Rupert Smith wrote:

I recently did a full upgrade and re-installed my whole system, including elm, atom and elm-format. I notice now that when I save files elm-format is giving a huge diff compared with what I had before, particularly around comments.

Bugger. Latest (non-experimental) version also introduces compile errors...

Ok, was easy enough to fix. Just need to make sure that everything after a @docs is on one line, or use multiple @docs if multiple lines are needed. 

[Rupert Smith]

On Tuesday, August 15, 2017 at 11:11:07 AM UTC+1, Rupert Smith wrote:

I am just wondering if I should update all public repositories that I maintain to match the latest version of elm-format? Otherwise we have to keep turning off elm-format-on-save to make nice diffs.

I suppose the question is, is there a consensus on which version is considered to be the most 'definitive' for 0.18 code? 

Given that that whole thing is pre 1.0 and should be considered alpha, does it really make sense at this stage to distinguish between 'exp'erimental and alpha releases? That is, should I just go with 0.7.0-exp as the canonical formatter? Or do people think that it is better to go with 0.6.1-alpha?

[Francesco Orsenigo]

I suppose the question is, is there a consensus on which version is considered to be the most 'definitive' for 0.18 code?

The last one.
Other than that, or what you consider "last" there is no consensus and it's fine.
In fact, you don't even have to use elm-format at all or feel pressured to update your old code.
Readability will be very similar regardless, and in the end that's what matters.

[Aaron VonderHaar]

As I get closer to the 1.0 release, I've been trying to figure out how we can still get user feedback for future format changes.  So the plan is to have -exp releases that have features that may change or be removed before the next release.  I was trying that plan out with 0.7.0-exp to see how it worked.  My thought was that people with less tolerance for formatting changes and back-and-forth will want to stick to the stable releases, and those that are able to try out new features can use the -exp version.

However, for 0.7.0-exp specifically, all 4 of the experimental features will be graduating to the next normal release, and I have started working on a few remaining bugs before the 0.7.1 release (which will not be -exp).

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rupert Smith]

On Wednesday, August 16, 2017 at 6:49:25 AM UTC+1, Aaron VonderHaar wrote:

As I get closer to the 1.0 release, I've been trying to figure out how we can still get user feedback for future format changes.  So the plan is to have -exp releases that have features that may change or be removed before the next release.  I was trying that plan out with 0.7.0-exp to see how it worked.  My thought was that people with less tolerance for formatting changes and back-and-forth will want to stick to the stable releases, and those that are able to try out new features can use the -exp version.

I think its a good idea, and once you get to 1.0 it will really start to make sense. 

[Rupert Smith]

I think a 'canonical' format for source code is really helpful when working in teams. It basically removes wasting time on any debate about it (curly braces at end of line or on new line? remember that that from C/C++/Java days...). Once established it helps to keep patches clean and easy to work with.