Bob Nystrom

Yeah, this is a limitation. I don't know if I'll do something smarter here, but I'm not opposed to the idea.

Another: ``` dart switch (match.group(0)) { case "\n" : return r"\n"; case "\"" : return r'\"'; case "\b" : return r"\b"; case "\t" : return r"\t"; case "\f" : return...

Yes, I think so! :) In fact, I even had it implemented when I added support for the other new Dart 3.0 features. Unfortunately, it: 1. Caused a performance regression...

Hmm, yeah, I'm guessing most uses of adjacent strings are intended to be on subsequent lines, though it would be good to verify that. I'm worried about how much churn...

@a14n, that's a really interesting idea. Definitely worth investigating. > Bob, I'm assuming this is a super tiny change. I *think* so, but it may be a little tricky getting...

Your wish is granted (admittedly after a long delay). The [forthcoming](https://github.com/dart-lang/dart_style/issues/1403) [tall style](https://github.com/dart-lang/dart_style/issues/1253) always forces newlines between adjacent strings. In other words, it has the principle that the only reason...

Good catch. I agree there should be a blank line in both cases.

I don't know why the old formatter was inconsistent in this example, but the [forthcoming](https://github.com/dart-lang/dart_style/issues/1403) [tall style](https://github.com/dart-lang/dart_style/issues/1253) isn't. It outputs: ```dart class A { A(this.name) : super(); final String name;...

Hey, @jacob314, do you remember anything about publishing dart_style to NPM? I've never done this and barely remember anything about when you first rolled in support for it.

Sorry, but we don't support publishing dart_style to NPM anymore. The one person on the team who knew how that worked is no longer on the team. You are certainly...