Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arrays in inline tables break strangely #304

Closed
maltekliemann opened this issue Aug 19, 2022 · 7 comments
Closed

Arrays in inline tables break strangely #304

maltekliemann opened this issue Aug 19, 2022 · 7 comments
Labels

Comments

@maltekliemann
Copy link

The following inline table...

parity-scale-codec = { default-features = false, features = ["derive", "max-encoded-len"], version = "3.0.0" }

...breaks into:

parity-scale-codec = { default-features = false, features = [
  "derive",
  "max-encoded-len",
], version = "3.0.0" }

I'm not sure if this is expected behavior. I find this to be very difficult and confusing to read. Other auto-formatters (from other languages) that I'm familiar tend to do something like the following:

parity-scale-codec = {
    default-features = false,
    features = ["device", "max-encoded-len"],
    version = "3.0.0",
}

But I would be ok with just not breaking the array and keeping the line longer that it is normally allowed to be. So, depending on whether the current behavior is correct, I would very much appreciate either a fix or an option for preventing arrays in inline tables from being expanded.

@tamasfe
Copy link
Owner

tamasfe commented Aug 20, 2022

Unfortunately the TOML spec explicitly prohibits newlines in inline tables, so what you suggest is not valid TOML.

The formatter will still attempt to shorten the line if it is over the target, and the only way to shorten it is by breaking up arrays. I agree that probably there should be an option to ignore inline tables that are too long.

@nemethf
Copy link

nemethf commented Aug 20, 2022

One possibility is to convert the long inline tables to standard tables. Or maybe a new LSP code-action cloud covert between the two formats.

BTW, are the lsp-extensions documented somewhere? Thanks.

@tamasfe
Copy link
Owner

tamasfe commented Aug 21, 2022

One possibility is to convert the long inline tables to standard tables. Or maybe a new LSP code-action cloud covert between the two formats.

There used to be an implementation of this in one direction (#92) but it was rather limited and buggy, I'd like to move this functionality into taplo itself in the future and expose it via the LSP.

BTW, are the lsp-extensions documented somewhere? Thanks.

Right now all there is just type definitions here or here.

@tamasfe
Copy link
Owner

tamasfe commented Aug 25, 2022

I added an option for disabling the expansion of arrays inside inline tables, setting inline_table_expand (inlineTableExpand in vscode) to false should enable the behaviour you're looking for.

I'll do a release this week.

@maltekliemann
Copy link
Author

Yo, sorry I didn't keep up with this conversation, been very busy. But many thanks for getting this done so quickly. Very cool! 👍

@tipakA
Copy link

tipakA commented Sep 5, 2022

Unfortunately the TOML spec explicitly prohibits newlines in inline tables, so what you suggest is not valid TOML.

@tamasfe Actually, it would appear that the newlines in inline tables are permitted, per toml-lang/toml#904 (merged at the end of July this year), but that is indeed not part of the current 1.0.0 spec. In fact, I was quite surprised that the extension complains about example code taken from the current toml.md file.

While it would appear that there is no timeframe for the 1.1.0 spec version that was said to include that change, I believe that in the meantime there should be at least an option for this in the extension.

@tamasfe
Copy link
Owner

tamasfe commented Sep 5, 2022

This is a welcome update! I would not get ahead of the specification though as it might break compatibility with other TOML tools, even supporting it conditionally might open up a can of worms I don't want to deal with right now.

Supporting this feature by itself should not be hard:

  • there is no difference in parsing, currently new lines and trailing commas are explicitly denied for the sake of the specification
  • the formatter might require some work to properly format arbitrarily nested code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants