Enable DartFmt Options with g:dartfmt_options

[theniceboy]

With this PR, users will be able to configure DartFmt options with g:dartfmt_options. They can change the default line limit from 80 to any number they prefer. They can also make dartfmt fix issues such as optional new keywords.

$ dartfmt -h
...
Non-whitespace fixes (off by default):
    --fix                              Apply all style fixes.
    --fix-doc-comments                 Use triple slash for documentation comments.
    --fix-function-typedefs            Use new syntax for function type typedefs.
    --fix-named-default-separator      Use "=" as the separator before named parameter default values.
    --fix-optional-const               Remove "const" keyword inside constant context.
    --fix-optional-new                 Remove "new" keyword.
    --fix-single-cascade-statements    Remove unnecessary single cascades from expression statements.

Other options:
-l, --line-length                      Wrap lines longer than this.
                                       (defaults to "80")
-i, --indent                           Spaces of leading indentation.
                                       (defaults to "0")
...

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[natebosch]

If we merge this we wouldn't want to encourage usage of setting the line limit. Idiomatic usage for dartfmt is to accept the default. We might even want to leave it out of the README entirely since most users shouldn't care about it, and add a note to the doc instead. cc @cbracken - what are you thoughts on how much to put in the README?

I can see the value in supporting this for the --fix arguments, but I'm on the fence about it. I think we typically expect those to be used infrequently, rather than on every run...

[theniceboy]

Personally, I find the 80 line limit annoying, and it looks like there are other people who have the same issue (check out this issue from the dartfmt repo).

I did a search and found that ~35% of our organization's Dart projects (maintained by various independent teams) use a custom dartfmt line length of either 100 or 120 as opposed to the default 80.

Maybe we should explain it more and recommend the default 80 line limit.

For --fix, I find it helpful but it does increase the :wq lag by a little bit. I guess we want to make that clear.

@natebosch

[natebosch]

Maybe we should explain it more and recommend the default 80 line limit.

I think it's fine for folks to use dartfmt -h to discover the options, we don't need to call them out specifically here. We can mention --fix as the motivating use case in our docs.

I do think this should be reserved for the help docs over the README.

[theniceboy]

That makes sense.

[natebosch]

If you want to follow the links from the CLA bot and sign the CLA I can help out with getting this documented and merged.

[natebosch]

Maybe we should explain it more and recommend the default 80 line limit.

I think it's fine for folks to use dartfmt -h to discover the options, we don't need to call them out specifically here. We can mention --fix as the motivating use case in our docs.

I do think this should be reserved for the help docs over the README.

[theniceboy]

@natebosch I have signed the CLA with the same email like the one in this commit:

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[natebosch]

Hmm sorry to bikeshed further but now I'm wondering if it would be better to take this as a list instead of a string so we can let vim handle the escaping stuff. It might be breaking if we change this later so I do want to give it some thought up front.

@cbracken - what do you think?

[theniceboy]

I do think it makes more sense to pass this option as a list, but frankly, I'm not really familiar with vimscript to implement the escape handling stuff... Sorry about that... @natebosch

[natebosch]

I do think it makes more sense to pass this option as a list, but frankly, I'm not really familiar with vimscript to implement the escape handling stuff

No problem!

If you'd like I can push a change that switches it to a list.

[theniceboy]

@natebosch Yes, that would be great! Thanks!