avh4 / elm-format

elm-format formats Elm source code according to a standard set of rules based on the official Elm Style Guide
BSD 3-Clause "New" or "Revised" License
1.31k stars 145 forks source link

Multiline strings don't line up #219

Open ghost opened 8 years ago

ghost commented 8 years ago

screen shot 2016-08-03 at 15 28 47

avh4 commented 8 years ago

Do you have a suggestion for how this should work?

In your example, the content of the string is <newline><space>. elm-format does not change the contents of the string, (and rightly so, I believe). Is there a way we can format this better without changing the content of the string?

ghost commented 8 years ago

This is what I typed (no space, just newline):

screen shot 2016-08-19 at 09 31 01

I think elm-format should move them both over, rather than just the top one.

Janiczek commented 8 years ago

What @avh4 said (or, maybe, wanted to communicate) is that moving them both over would change the contents of the string.

string1 =
  """
  """

string2 =
    """
    """

These two aren't the same.

string1 == "\n  "
string2 == "\n    "
ghost commented 8 years ago

Okay, I didn't know how multiline strings work. How does moving neither over sit?

ghost commented 8 years ago

Here's a real example. I've pasted a multiline string in:

screen shot 2016-08-19 at 11 25 07

Then I've run elm-format (on save):

screen shot 2016-08-19 at 11 25 21

It aligns the first line of the string but not the rest.

Janiczek commented 8 years ago

tl;dr: elm-format shouldn't change the values, that's why it'll rather leave the """s unaligned than mess with them


I think there is no safe way to align both the same way everytime.

In your case it could be OK to deindent the spaces and not lose information (and the program would look nice):

query =
-    """
-        SELECT ?cause ... {
-          wdt:P1542 ...
-        }
-        """
+    """
+    SELECT ?cause ... {
+      wdt:P1542 ...
+    }
+    """

but generally there's no guarantee the user won't interpret the spaces somehow. Then elm-format would change what the program does, not only how it looks!

ghost commented 8 years ago

I think what I should have said is that I think it should preserve the alignment.

Janiczek commented 8 years ago

So, either:


align to self

let
    abc =
        "normal indentation"

    def =
            """
            whatever the user types, first quotes dictated by the last quotes

            + automatic
            + aligned to self
            + doesn't change string contents

            - misaligned to other definitions
            """
in
    1

align 4 spaces

let
    abc =
        "normal indentation"

    def =
        """
            indent the first quotes 4 spaces

            + automatic
            + aligned to other definitions
            + doesn't change string contents

            - misaligned to self (OCD person - aren't we all - would change that afterwards)
            """
in
    1

Other than that, just a practical note, the multiline strings most likely don't look that nice. More like:

myMarkdown =
    """
# My heading

Some text with [link](http://google.com) and whatnot.
"""

That would make the "align to self" decision align it this way:

myMarkdown =
"""
# My heading

Some text with [link](http://google.com) and whatnot.
"""

which I'm not even sure is legal syntax.

ghost commented 8 years ago

I prefer align to self, but I still don't understand why elm-format can't do align 4 spaces then correct the misalignment, as I would do myself. Perhaps I don't understand how elm-format works. I've noticed that once I've corrected the misalignment, elm-format doesn't misalign the string again.

avh4 commented 7 years ago

The problem is that if elm-format does the alignment automatically, then that means that if someone wants to have a literal string that elm-format thinks is misaligned, then there's no way for the file to represent that exact string. It would be nice if elm-format could do this alignment, but I don't see a rule that would make that possible that also wouldn't make certain other strings impossible to have in your source code.

I think the auto-alignment fixing would be a feature that could be implemented in IDE plugins, so that the user could choose when and when not to perform the realignment.