Did you guys want to format languages.toml?

[lalala-233]

I want to contribute something (like using deno lsp for js and ts, supporting liquid), but I found there is not a unique style in languages.toml.

I think it is bad to have multiple styles in one file.

whitespace between args and =

strange:

helix/languages.toml

Line 67 in 1cbad94

haskell-language-server = { command = "haskell-language-server-wrapper", args = ["--lsp"] }

normal:

helix/languages.toml

Line 76 in 1cbad94

jsonnet-language-server = { command = "jsonnet-language-server", args= ["-t", "--lint"] }

whitespace between = and "

strange:

helix/languages.toml

Line 5463 in 1cbad94

indent = { tab-width = 8, unit=" "}

helix/languages.toml

Line 3086 in 1cbad94

name ="esdl"

normal:

helix/languages.toml

Line 5482 in 1cbad94

indent = { tab-width = 4, unit = " " }

helix/languages.toml

Line 326 in 1cbad94

name = "rust"

format or not?

strange:

helix/languages.toml

Lines 325 to 341 in 1cbad94

	[[language]]
	name = "rust"
	scope = "source.rust"
	injection-regex = "rs|rust"
	file-types = ["rs"]
	roots = ["Cargo.toml", "Cargo.lock"]
	shebangs = ["rust-script", "cargo"]
	auto-format = true
	comment-tokens = ["//", "///", "//!"]
	block-comment-tokens = [
	{ start = "/*", end = "*/" },
	{ start = "/**", end = "*/" },
	{ start = "/*!", end = "*/" },
	]
	language-servers = [ "rust-analyzer" ]
	indent = { tab-width = 4, unit = " " }
	persistent-diagnostic-sources = ["rustc", "clippy"]

normal:

helix/languages.toml

Lines 4622 to 4631 in 1cbad94

	[[language]]
	name = "circom"
	scope = "source.circom"
	injection-regex = "circom"
	file-types = ["circom"]
	roots = ["package.json"]
	comment-tokens = "//"
	indent = { tab-width = 4, unit = " " }
	auto-format = false
	language-servers = ["circom-lsp"]

---

But, formatting such a large file (~5511 lines) will result in lots of changes. It may be a bad idea to shadow others' edits.

I try to format, then I get 715 insertions(+), 359 deletions(-).

So, what should we do?

[David-Else]

YES! It has been bugging me for a very long time, but I just assumed that the PR would not be accepted. Maybe now before the big new release is a great time to do it :)

Regardless of the specific formatting choice, the project should use a mainstream, supported formatting tool to ensure long-term maintainability. Unfortunately the 2 main obvious choices have problems, https://github.com/tamasfe/taplo is as good as dead, and https://github.com/tombi-toml/tombi seems very sloppy and vibe coded with a new release every 5 minutes. Maybe https://www.npmjs.com/package/prettier-plugin-toml is the way to go.

I don't really care too much about the spaces around =, but much prefer:

[[language]] 
 name = "rust" 
 scope = "source.rust" 
 injection-regex = "rs|rust"

To the example you call normal with the excessive spacing added.

It goes deeper than just the formatting:

• Items under [language-server] were once alphabetically sorted, now some deviants have added rouge server names that are not sorted, it needs sorting again

• There are two competing styles of entry in language servers, for example the following is currently included:

[language-server.ansible-language-server]
command = "ansible-language-server"
args = ["--stdio"]

Which should have been added at the top under [language-server]:

ansible-language-server = { command = "ansible-language-server", args = ["--stdio"] }

These cases need correcting to standardise the style and make it easy to read.

[the-mikedavis]

I wouldn't really care for a formatting change to languages.toml. I think that the benefits of formatting are questionable for such a straightforward nearly-text document. Enforcing formatting adds a hurdle to the contribution path - you need to ensure your change satisfies the formatter - and I don't see much concrete upshot like I do for Rust formatting (i.e. that you never need to argue about how the code should be laid out).

languages.toml changes are fairly often very minor drive-by like changes, and you don't need much project context to make the change. I think that formatting would punish those kinds of changes.

Separately I really disagree that using spaces to align items on either side of equals signs is a good idea, like you suggest with rust vs. circom in the original post. Adding a new key then might mean reformatting the entire block, making a noisy diff. I don't see it as a good tradeoff since the upshot seems to be purely cosmetic and the downside is noisy churn. All language formatters that I am aware of avoid this trap.

And overall I see us deleting this file as we work towards coalescing config.toml and languages.toml options and moving them into scheme. Requiring the scheme to be formatted seems alright to me, but I'm not so convinced about formatting for TOML.