Why are tabwidths and expandtab set?

[toastal]

As I’ve aged, 2-spaced code has become increasingly difficult to read. I have set my editor to a larger value for my personal readability needs. The language seems to have no issues with tabs (U+0009) as well. As such, what is the purpose of this editor plugin having an opinion on how code is indented? …Especially when this conflicts with values set in .editorconfig.

File in question: https://github.com/nickel-lang/vim-nickel/blob/84ec8782781c7ce6175171fadc233e5ad11cc794/ftplugin/nickel.vim

[yannham]

Setting those values doesn't seem to be exceptional, for example Rust and Scala plugins do it. I imagine the idea is to have consistent defaults for everyone out there, if the language's formatter or the accepted style favor 2 spaces over 4.

However it's an issue if it's not overridable, especially if it's a question of accessibility and not just taste. Would it solve your issue to guard this config behind a flag, such as in the Rust plugin, something like g:nickel_recommended_style ? This would be set by default but possible to disable.

[toastal]

It could work and would help as I’m currently needing to run a command to set these value larger, but I’m curious about whose recommended style it is? Is there an official formatter or some ‘standards body’ that set it (I recognize that this config language isn’t at that size)? Also, how can I RFC that body to suggest tabs (like gofmt, et al.) so indentation can be user configurable before formats get too solidified like the state Prettier is in? 😅

[yannham]

Nickel does have an official formatter, which is the (multi-language) Topiary. It'll be incorporated into the Nickel CLI itself soon, in the short term, as nickel format or something alike (tweag/nickel#1352). Topiary uses two spaces as a delimiter currently.

That being said, the point of having a formatter is that the machine takes care of it, so it's not out of the question to switch to a different option (that would make a big diff on existing codebase, but if it's for a better choice, such is life). I would like the official formatter not to be configurable though, in the line of thought of gofmt and other modern formatters (one consistent style everywhere).

I would advise to open an issue on either the Nickel repository, or the topiary repository, for an RFC. vim-nickel should mostly follow what the official formatter enforces, I think. For now, the most we can do is to guard those options behind the proposed g:nickel_recommended_style.