elm-format
elm-format copied to clipboard
avh4
Ignore extra commas
If a list, record, tuple, or module/import/exposing literal has an extraneous , at the beginning or end, it'll be a syntax error. Removing it will fix that syntax error.
Suppose I want to delete the first element in a multiline list:
[ foo
, bar
, baz
]
If I delete foo, my editor now looks like this:
[
, bar
, baz
]
Currently my next step is to delete the , by hand.
How cool would it be if I could instead just hit Save, and elm-format would disregard that extraneous comma and rewrite the above to this? 😸
[ bar
, baz
]
This could also fix the pain point where someone accidentally ends up with a trailing comma at the end of a list. Currently they get an error and have to fix it by hand. Would be nicer if it just magically got fixed for them!
Yes, this should be doable. It's not super-trivial because we have to handle comments and newlines around the extra commas, and there are also about 7 or 8 places in the grammar where this should be applied.
What if instead of this being a compiler error, allow leading delimiters? Then elm-format can put the leading brace on the same line as the declaration, and any changes to any line in the 'body' will be diff-friendly, including to the first or last.
(If this is the wrong place for such a proposal, I apologize in advance and will move it).
Background/Motivation:
This is my first ML language and the syntax formatting is quite strange coming from C-style formatted languages like Javascript, Perl, C++, Java, Python, etc, where they all encourage the opening brace either on the first line or new, with the body coming after. Rarely if ever have I seen the brace prefixing the first line of the body! (I'm sure there's some codebase somewhere that adopts this though, but it's definitely non-standard.) I'll be honest, I really didn't like it, being the creature of habit (and opinion) that I am. So I was writing elm using C formatting like
type alias MyRecord = {
looks: String,
like: Bool,
javascript: Int
}
Of course this makes it annoying to add new things to the end of such constructs, as is explained in the motivation for using the particular formatting style ascribed by the community/evan.
Anyway, finally I got sick enough of doing my own formatting and fighting the lack of automatic brace placement that my editor would normally do in other languages, that I bit the bullet and started using elm-format. And now I like it (It really helps that something else besides me has to format my file, because I don't really care enough to fight with it since it's doing all the work, like that roommate that is so fanatic about keeping the flat clean that he often puts your stuff away for you, but you let it go since he doesn't complain).
However, I noticed that there is a problem with this style: changing/swapping lines in constructs in the middle/end is easy, but now changing the first line is annoying. (Hence this ticket. Big problem in Html attrs and children lists). One thing that Babel for Javascript lets you do is have trailing delimiters in most multiline syntax, which eliminates the problem completely because now each line of your definition/usage has the same form.
So all of this rambling comes to the question: should this be an elm-format problem or should we push it to the compiler so we can write Elm like this:
view model =
div [] [
, foo
, bar
, baz
]
type Msg =
| Name String
| Password String
| PasswordAgain String
type alias Model = {
, name : String
, password : String
, passwordAgain : String
}
This hides that first brace even more and gets it out of the way of the diff should you change the first line. Also, all lines now look the same so the code is more uniform and easier to read, I argue. The delimiters still go at the beginning of the line because I agree that it looks nicer to have them all lined up rather than staggered randomly at the end.
(I won't go on to propose whitespace-significant syntax like Python/YAML that eliminates the brackets entirely (just yet)).
Ok, I've put myself out there and possibly proposed something hedonistic... flame away!
I agree on type - I just think leading pipes (what F# does) is better. No argument here.
I have a fairly wild idea when it comes to the other two.
What if you wrote this:
type alias Model =
{ name : String
, password : String
, passwordAgain : String
}
...and then you naively reordered it:
type alias Model =
, password : String
{ name : String
, passwordAgain : String
}
...and elm-format was just like "I understand what you wanted here" and rewrote it to:
type alias Model =
{ password : String
, name : String
, passwordAgain : String
}
That's probably really difficult for the parser to do, but it would be mindblown.gif if it worked. 😜
This is suggesting something even more interesting than simply fixing brackets. What if elm-format could go as far as being able to fix general small syntax errors that might crop up from moving code around?
+1 (did this ever get traction?) In my mind, both as teaching new programmers as well as a daily developer in Elm, the # 1 most irritating error generated 100 times a day results from moving html elements around and having to manually clean up commas and braces. This is such a frequent occurrence, and the errors so confusing for someone new.
section []
[ p[] [text "example 1"]
, p [] [text "example 2"]
]
Wanting to just move items, but then having to manually clean up (too many keystrokes involved, 100 times a day)
section []
, p [] [text "example 2"]
[ p[] [text "example 1"]
]
P.S. Love Elm, still.
