Potentially unwanted behavior for function calls assignment

[MunifTanjim]

Description

I'm not sure if this is intentional. If it's intentional, it sure looks odd. Behavior of v0.13.x was much nicer.

Input

  local height = math.max(math.min(#items, defaults(options.max_height, vim.o.lines - 7)), defaults(options.min_height, 1))

Output (v0.13.x)

  local height = math.max(
    math.min(#items, defaults(options.max_height, vim.o.lines - 7)),
    defaults(options.min_height, 1)
  )

Output (v0.14.x)

  local height =
    math.max(math.min(#items, defaults(options.max_height, vim.o.lines - 7)), defaults(options.min_height, 1))

[JohnnyMorganz]

This was intentional: #342 (comment)

But what you report seems to be an unfortunate side effect. A lot of the other cases now look nicer, but I also think it looks better here when it is expanded.

I wonder what kind of heuristic we can apply here

[MunifTanjim]

Prettier's behavior seems pretty reasonable.

[JohnnyMorganz]

I think the a potential solution to solve this is to implement some sort of "complexity" heuristic, to decide whether we should hang at equals or not.
For example, the expression mentioned in OP is quite hard to read, so should be multilined.

Some expressions which we potentially do not want to multiline?

diagnostic_cache_extmarks[bufnr][namespace] =
    vim.api.nvim_buf_get_extmarks(bufnr, namespace, 0, -1, { details = true })

local msg =
    string.format('method %s is not supported by any of the servers registered for the current buffer', method)

torso.CFrame =
    CFrame.new(torso.Position.x, torso.Position.y, torso.Position.z, 0, 0, 1, 0, -1, 0, 1, 0, 0)

local musicId, musicTime, responseTick, responseOffset =
    remotes.Server.GetSpectatorInfo:InvokeServer(player, sendTick, anotherArgument)

Are there other examples of potential "high complexity" expressions?

[MunifTanjim]

I'm not sure what "complexity" means in this context and how to decide it.

To me (merely a user of the formatter, I don't know much about its internals), Prettier's behavior seems more desirable in this situation, i.e. do not put the function identifier in a new line preemptively, only do it when the identifier crosses the line length limit, otherwise just put the arguments in new lines. 🤔

[MunifTanjim]

About the examples:

diagnostic_cache_extmarks[bufnr][namespace] =
    vim.api.nvim_buf_get_extmarks(bufnr, namespace, 0, -1, { details = true })

With v0.13.x

It was consistent:

diagnostic_cache_extmarks[bufnr][namespace] = vim.api.nvim_buf_get_extmarks(
  bufnr,
  namespace,
  0,
  -1,
  { details = true, another_key = "another_value" }
)

diagnostic_cache_extmarks[bufnr][namespace] = vim.api.nvim_buf_get_extmarks(
  bufnr,
  namespace,
  0,
  -1,
  { details = true, another_key = "another_value", yet_another_key = "yet_another_value" }
)

With v0.15.x

It jumps between keeping the function identifier on same line and new line:

diagnostic_cache_extmarks[bufnr][namespace] =
  vim.api.nvim_buf_get_extmarks(bufnr, namespace, 0, -1, { details = true, another_key = "another_value" })

diagnostic_cache_extmarks[bufnr][namespace] = vim.api.nvim_buf_get_extmarks(
  bufnr,
  namespace,
  0,
  -1,
  { details = true, another_key = "another_value", yet_another_key = "yet_another_value" }
)

[MunifTanjim]

With v0.15.x:

local msg = string.format("method %s is not supported by any of the servers registered for the current buffer", method)

local msg =
  string.format("...method %s is not supported by any of the servers registered for the current buffer", method)

local msg = string.format(
  ".............method %s is not supported by any of the servers registered for the current buffer",
  method
)

Based on the length of first argument, the function identifier:

• stays on same line
• jumps to next line
• jumps back to prev line

I would not expect the function identifier to jump around when clearly the first line has enough space to contain the function identifier.

---

Looks like this behavior can be replicated with all the examples.

[JohnnyMorganz]

I think you bring valid points in all these cases.

Going to look to see how to revert this nicely with minimal diff noise (but that may be inevitable). I'm hesitant, but maybe it could be an option