helix
helix copied to clipboard
Set auto-format true for toml
taplo has formatting built in, but auto-format has been off until now. I don't know if this was because it was broken in the past, an oversight, or a concious decision?
I notice that the Helix .toml files have not been formatted. If we turn on auto-format it sends the signal to contributors that the Helix .toml files should be formatted... with the default settings they look quite different. I have matched them approximately in a taplo.toml file. It brings much needed consistency to languages.toml. Shall I make a pull request with the settings file in Helix's root and some formatting applied?
EDIT: You can see the results of the formatting with an options file in the reverted [Add taplo.toml formatting options and format languages.toml](https://github.com/helix-editor/helix/pull/4991/commits/a1804d554418e9751064cd6f1aac81ed8ade9d66) commit. Please excuse my wrong way of using GitHub, I am still working it out!
I've tried this. Personally, I don't mind having default formatting options. Let's see what others think.
Default options would be fine with me too.
I'm hesitant to enable auto-format for any language that doesn't have a canonical (or at least very popular, like prettier) formatting style and it looks like taplo's style is custom. If you're working on another project and touch its Cargo.toml and introduce unrelated formatting changes, you end up fighting with the formatter and resetting any unrelated formatting changes before submitting a PR. And if we apply its formatting changes to our toml files, we would also want to setup a lint to reject changes that aren't formatted. But then contributors would need to install the taplo language server or CLI in order to contribute. I think that's fine for rust formatting and lints but feels unnecessary for toml files
@the-mikedavis
...and it looks like taplo's style is custom
There are only 2 formatters for TOML, taplo being one of them, the other has 11 GitHub stars so is not really relevant, I have not investigated if there are any differences in the defaults: https://github.com/toml-lang/toml/wiki#formatters
if we apply its formatting changes to our toml files, we would also want to setup a lint to reject changes that aren't formatted.
Why not just set the GitHub actions to format it for us?
As I understood @the-mikedavis voiced two main concerns:
auto-format = truefor toml- format
languages.tomlin this PR
For the first point, my opinion is that if LS for a particular language has a formatting capability, it should be enabled by default. This corresponds to Batteries included item in vision.md Besides, as @David-Else has mentioned there aren't any other alternatives to toml formatters.
For the second point, I feel like to force contributors to have taplo LS installed is overkill indeed. Then just formatting languages.toml manually once in a while should be fine. There aren't any major differences anyway and most of contributions will not require any additional formatting at all.
There are only 2 formatters for TOML, taplo being one of them, the other has 11 GitHub stars so is not really relevant
Even if there isn't much competition, taplo is hardly de facto. Without a popular de facto tool or an official style guide, enabling auto-format would lead to a worse experience for the average user IMO.
Why not just set the GitHub actions to format it for us?
Then we get extra commits just for formatting which muck up the log and the git blame.
if LS for a particular language has a formatting capability, it should be enabled by default
I like this reasoning but it doesn't work consistently: some language servers build in one (or many) flavors of formatting even if the flavor isn't official or very popular. If there isn't a de facto formatter for the language then this is still contentious. For example: Nix has many auto-formatters and different language servers use different formatters out-of-the-box. Or for another; Erlang has a few successful formatters but most projects are not auto-formatted so enabling auto-format leads to a bad experience.
Then just formatting languages.toml manually once in a while should be fine
If it won't be continuously auto-formatted then I don't see a reason to auto-format it at all: it's just extra work, it can mess up the git blame (formatting commits can be ignored, but again it's just extra work), and if the changes aren't substantial or don't really improve readability, there isn't much benefit.