Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Special-case trimIndent? #389

Open
kevinb9n opened this issue Mar 2, 2023 · 7 comments
Open

Special-case trimIndent? #389

kevinb9n opened this issue Mar 2, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@kevinb9n
Copy link

kevinb9n commented Mar 2, 2023

This might be an easy close, not sure.

But following an ending """ with .trimIndent() is arguably an inherent part of the language idiom for many many use cases, and I wondered if those could feasibly be kept together on the same line, as a special carve-out.

Current

    loader(
        """
        Foobar
        ${decl.joinToString("") { "$it\n" }}
        """
            .trimIndent())

Seems nicer

    loader(
        """
        Foobar
        ${decl.joinToString("") { "$it\n" }}
        """.trimIndent())

Eh?

@davidtorosyan
Copy link
Contributor

There's two ways to getting this I can see:

  1. Better multiline string handling: Not really possible, see discussion in Force-break an indent qualified expression rooted on multiline strings #343.
  2. Special casing for trimIndent: We try not to special case any particular functions.

Leaving this open to see if others have thoughts, but I think this is unlikely to work.

@kevinb9n
Copy link
Author

kevinb9n commented Mar 2, 2023

  1. Special casing for trimIndent: We try not to special case any particular functions.

And I do think that's the right way. The case to make here would be that this function is just about as close to a language feature as a thing could be. Like, it's more that it is a special case than that the tool is making it so. Again... "Eh?"

(I mentioned in another issue that I still sometimes guiltily counteract what the formatter does in my code, so I feel some certain responsibility to file those things for consideration, but don't feel too invested in what happens to them after that.)

@att14
Copy link

att14 commented Mar 13, 2023

This is a duplicate of #251 I believe.

@kevinb9n
Copy link
Author

I don't believe it is; that one seems to be about reindenting the actual string contents using the signal of trimIndent as a way to know that is safe. This is about how to format the trimIndent call itself.

@att14
Copy link

att14 commented Mar 13, 2023

Ya, your right, sorry I misread.

@hick209
Copy link
Contributor

hick209 commented Jun 5, 2024

This here is what Google Java Format does

➜ cat Test.java
class Test {
  public static final String msg1 = """
      foo asfasf asdf asf asdfasf asdf.
      bar asdf sf asdf asdfasdf as.
      baz asdf dsaf asdf sfd .
  """.trimIndent();

  void foo() {
    loader(
        """
        Foobar
        %s
        """.formatted(decl.joinToString(""))
    );
  }
}

➜  java -jar google-java-format-1.22.0-all-deps.jar Test.java
class Test {
  public static final String msg1 =
      """
          foo asfasf asdf asf asdfasf asdf.
          bar asdf sf asdf asdfasdf as.
          baz asdf dsaf asdf sfd .
      """
          .trimIndent();

  void foo() {
    loader(
        """
        Foobar
        %s
        """
            .formatted(decl.joinToString("")));
  }
}

Since we inherit from GJF, maybe we should request for the capability to handle exceptions for text blocks in there.

Could you open an issue in that repo (https://github.com/google/google-java-format) or link an existing one to this issue?

@hick209 hick209 added the enhancement New feature or request label Jun 5, 2024
@autonomousapps
Copy link

I would add trimMargin() to this. It is similarly at the level of "core language feature", like trimIndent().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants