feat: add luaformatter formatter

[actionless]

No description provided.

[dbarnett]

The shiftwidth change should be a separate PR. Also looks like your vroom tests need to be fixed; they're failing in Travis CI. Besides that, LGTM.

[actionless]

do you have any idea why lines are not matching in the test?

[dbarnett]

@actionless Looks like it's just typos in the vroom. I see the same when running locally. I think you wanted :2,3FormatLines instead of :2,2FormatLines. Are you able to run vroom locally?

[dbarnett]

Unfortunate typo here.

[actionless]

i will commit fixes later today, thanks for finding the problems

but i also have another question -- how it would be better to handle shiftwidth in clang formatter -- i am thinking about changing default formatting style[1] to {IndentWidth=+&shiftwidth+} but could it be a behavior breakage then if using .clang-format file?

[1] https://github.com/google/vim-codefmt/blob/master/instant/flags.vim#L63

[dbarnett]

My naive preference would be to
a) Have a global (+local?) option for sending shiftwidth, textwidth, and other editor settings to formatters, and
b) Give custom .clang-format rules higher precedence.

The reason is that a lot of casual vim users don't configure shiftwidth, textwidth, etc. properly but will still expect codefmt to not cause formatting "regressions", like formatting based on their broken settings instead of custom project configuration.

OTOH, if you have the editor configured with different settings from your formatters, you're going to have a bad time… It would be nice to just make vim's settings canonical and maybe warn for discrepancies.

Side note: http://editorconfig.org/ looks interesting and I'm wondering if we can consolidate some configuration with that somehow.

[malcolmr]

(For a) above, see #27)

[actionless]

Side note: http://editorconfig.org/ looks interesting and I'm wondering if we can consolidate some configuration with that somehow.

i think it should be some separate plugin which will set vim shiftwidth and other params based on config file and codefmt plugin should use those params from vim itself, ie don't depend on any third-party plugin or config file

[dbarnett]

I wasn't suggesting an explicit plugin dependency, only that if https://github.com/editorconfig/editorconfig-vim is installed we should cooperate w/ it and avoid any conflicts, and possibly recommend editorconfig on our end to get sane default configuration. It may be as simple as inheriting vim's settings (#27) without needing to know how those were configured, but it's possible we'd also want to treat them as higher precedence if they came from editorconfig since editorconfig users are less likely to have config they don't expect/understand.

[actionless]

then i will rebase this one after #27 will be implemented

but i still can't understand what is the problem to use vim's &shiftwidth -- if someone is using editorconfig plugin then his shitftwidth will be set by it

[artasparks]

I'm going to close this commit since been outstanding for a long time. It appears to me that the problem was that the the PR tried to do too much: Add a lua formatter (good), change sw (seems reasonable), but they should be in separate PRs.

[dbarnett]

then i will rebase this one after #27 will be implemented

I don't see any reason you would block the luaformatter implementation on the shiftwidth change. Why not just remove that part of the change and follow up in #27, and here fix up the tests and get it submitted?

but i still can't understand what is the problem to use vim's &shiftwidth -- if someone is using editorconfig plugin then his shitftwidth will be set by it

Commenting in #27 about that. You are correct that shiftwidth would come from editorconfig for users that have it installed and configured. My problem is that for everyone else, shiftwidth adds a new way for users to accidentally get formatting wrong.