tree 3d78180a5637b2a59a68fe1cb1f4390dc5a6316e
parent 990df02f290bd9277a4e2685ecdcd16ce723c956
author Bob Nystrom <rnystrom@google.com> 1706050863 -0800
committer GitHub <noreply@github.com> 1706050863 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJlsEUvCRC1aQ7uu5UhlAAAascQAAO5Hp4g97pgSA3I1nXcxx/l
 7wJQ+rpYOdUYZbQMc8xFIq/AYrIymTq2+ygJvtlmd5RbvMtwHzpj2n379QGSPH7r
 zuVNt52dBYNthYBGcM+0BjNxNGqgjJ6lnWvE2vhZY8yL3yptK7P0r5UbW0emm5+j
 W9RfuuakpKSCz+lpuoJodQOcuUeI6bXdcy6A5n2znmsat/1S6GSaiCMjbhdus6RL
 IbiA6XBOaPeGOu4mNPmEUGyIcXhbPr7o72OhJavWOZA8rs7jdyQENmOJkTta14Qh
 +TLNzXUCGghXQSggL7bs+5k2DpapvpgXNxk6WkHMVPocv8fI0E6DUEZ1rZ6TBCz8
 ZYiRQl3ilrA3Zq0ztykZtwVutp0UWuCe9wt9baKDoi4sZuistHv/TFTEQ739FqqB
 XnjifByzuq9uajfInFtCn8LV6j3WljTU4VjqgI4Jje/3pc/19uhLkVc1r9jEKrNP
 R8mq2T+S3C46iPsfdzc045lxg0y6je31XWcP/mCtGKjU+BrVzZ9lG7yR1OvU0ES2
 gabAxIGpy1WSgNYKMALUpqhD9rUIja9hsIiYvwSsLUk+lujSC8vAbgvZk+DMapUj
 /mfnVErk51d0O/AOFisp8TJ7MkciN0US8Pq+o1O8bzQ8ZVFIFPCOavHlGo2b/fC4
 agEhzlGVQDRUUoYw0pPM
 =t1gV
 -----END PGP SIGNATURE-----
 

Format adjacent strings. (#1364)

Format adjacent strings.

Most of this was fairly straightforward, but the two tricky bits are:

### 1. Deciding whether or not to indent

There are some rules around whether subsequent strings in the adjacent
strings get indented or not. The answer is yes in some cases to avoid
confusion:

```
var list = function(
  'string 1',
  'adjacent'
      'string 2',
  'string 3',
];
```

But not in others since it looks nicer to line them up when possible:

```
var description =
    'some text '
    'more text';
```

### 2. Handling `test()` and `group()`

It's really important that test functions don't end up fully split
because doing so would lead to the inner function expression getting
indented +2:

```
test('this looks good', () {
  body;
});

test(
  'this looks bad',
  () {
    body;
  },
);
```

Test descriptions often span multiple lines using adjacent strings:

```
test('this is a very long test description '
    'spanning multiple lines, () {
  body;
});
```

Normally, the newline inside the adjacent strings would cause the entire
argument list to split. The old style handles that (I think) by allowing
multiple block-formatted arguments and then treating both the adjacent
strings and the function expressions as block arguments.

The new style currently only allows a single block argument (because in
almost all of the Flutter code I found using block formatting, one
argument was sufficient). So I chose a more narrowly targeted rule here
where we allow adjacent strings to not prevent block formatting only if
the adjacent strings are the first argument and the block argument is a
function expression as the next argument.

I left a TODO to see if we want to iterate on that rule, but I think it
works pretty well.

### Other stuff

Unlike the old style, I chose to always split between adjacent strings.
The old style will preserve newlines there but if a user chooses to
deliberately put multiple adjacent strings on the same line and they
fit, it will honor it. That didn't seem useful to me, so now they just
always split. I don't think adjacent strings ever look good on the same
line.

I ended up moving the state to track which elements in a ListPiece out
of ListPiece and into the ListElements themselves. I think it's clearer
this way and will be easier to evolve if we end up supporting multiple
block formatted elements in a single list.