feature request: regarding support for "func {foo=.., bar=..}" named args syntax

[bfredl]

We in the neovim project are using stylua for a great deal of our lua code and we look to expand to use it also for our test suite.

One issue with this is that our test code heavily makes use of the idiom of passing a single table to a function and interpret these as keyword arguments of the function. As an example of existing code:

    screen:expect{grid=[[
      {1: }                                                 |
      {4:~                                                 }|
      :edit xtest-foo                                   |
      {3:-- TERMINAL --}                                    |
    ]], unchanged=true}

Currently stylua would expand this to

   screen:expect {
      grid = [[
      {1: }                                                 |
      {4:~                                                 }|
      :edit xtest-foo                                   |
      {3:-- TERMINAL --}                                    |
    ]],
      unchanged = true,
    }

While we would like the original input to be the the canonical style enforced by stylua, i e avoid any extra linebreaks to be inserted here. Compare with how stylua already handle positional args with multiple line functions, i e

it('fooo', function()
  echo('this is code')

  echo('this is even more code')
end, 'baar')

will be preserved as such already. The different treatment of multiline closures and [[ ... ]] strings also play in.

So in summary:

• an option to use the same spacing rules for foo {args=...} as a positional function call foo(args...)
• if possible, avoid mandatory newline after ]], consistent with no extra newline after a closure arg.

For reference, our current config

[JohnnyMorganz]

For reference, the reason why we handle positional args like that is at https://github.com/JohnnyMorganz/StyLua/issues/276#issuecomment-937968657.

I'm not a particular big fan of it (makes the code for stylua a lot more complex, and affects formatting consistency), but it catered for a common pattern in the code I was working on. Probably unfair to support if for that case and not yours though :)

If I were to add it, it would have to be behind an option. I hesitate at options, but maybe I should just get over that personal objection now (#620)

[bfredl]

That's very good to hear.

W.r.t configuration I think there doesn't need to be separate options for every separate small thing but it would be good with an option which is "opinionated" towards either a compact style or a more expanded style (as used traditionally in stylua) for things like multi-line tables, were in declarative code which contains nested tables and functions in tables the "compact" style might be preferable.