`zig fmt` with 2 spaces indentation

Help
1

I am quite amazed by Zig and decided to start using it, yet I am having some trouble with the code formatter.

I am aware that the document says Zig prefers 4 spaces for indentation. But I really want 2 spaces instead. It seems that the vscode extension will automatically format the code whenever I save (which I find it great btw), and during such reformatting, even if my code uses 2 spaces, every indention will be reverted to 4 spaces.

Is there any way to convince zig fmt (which I guess is what get invoked for auto formatting) to use 2 spaces instead of 4?

(Maybe it’s just me, but this is kinda driving me crazy…)

2 Likes
2

There is no way to do what you want. This is a conscious, explicit decision from the zig team; I doubt they will consider any suggestions to change this or allow for more / different configurations.

7 Likes
3

I see. If it is the case, I guess I will have to adjust my habit and try to live with their explicit decision.

(also just found 2 spaces for `zig fmt` instead of 4 · Issue #11107 · ziglang/zig · GitHub after searching Google with a slight different search term.)

4

My personal preference is to use 8 spaces for indentation (Rationale).
And zig fmt could have options to make everyone happy.
But actually adding any option to zig fmt would make everyone unhappy.
I really cannot read zig code using 2 spaces for indentation. I am so used to read zig code formatted using zig fmt that I cannot read anything that is not properly formatted using zig fmt.
The existance of zig fmt is about sharing code where everyone can read without mentally adapting to a different formatting style.

5 Likes
5

same here for me it’s 8 or nothing, but at the end of the day consistency is more important.

1 Like
6

The great thing about having a system wide formatter is that it keeps the kibitzing on the forum, and out of PRs.

Mine is that when I have a long run of definitions, I follow a policy of one comment per, at the end of the line. I strongly prefer to align the comments so they all start on the same column, but the formatter doesn’t like this.

There’s an open issue on changing that, which I hope lands someday.

8 Likes
7

O, yeah. I’ve been using this formatting style for all my C programs since I had seen this guide for the first time. And if someone’s C sources have something different I just run indent -linux over them. But if some language/community prefer lesser indentation I simply setup an editor so that pressing Tab inserts N spaces instead of a … well, tabulation, which was always 8 character long. For me personally 2 character cells as an indentation is too little.

1 Like
8

tabs help people who use assistive techs like screen readers understand code better. i think that should matter. people with dyslexia often have more problems reading ciode when there isnt enough spacing (eg, i do my ifs:

if( cond ) {
    // ...
}
else if {
    // ...
} 
else {
    // ...
}

but zig wants to shove all the else on the closing brace line and doesn’t like the extra spacing around the condition, and it can reading difficult.

if(cond) {
    // ...
} else if {
    // ...
}  else {
    // ...
}

And I’ve done APL so am used to very dense code, but for some reason APL density is much easier than C-like density.

4 Likes
9

Without going into the whole tabs vs spaces war, I think this issue of visual width of indentation is precisely an issue that tabs are better suited to solve. You could have the visual width of a tab adjusted to your taste locally and not affect anyone else’s view of the code.

So for example in a line of the source code we have exactly 2 tabs for everyone, but in my adjusted editor that’s 8 columns and in yours it could be 16.

3 Likes
10

I prefer elastic tabstops.
For indentation it is the same as tabs. The difference is that each tab creates a proper tabstop that aligns with all adjacent lines.

5 Likes
11

I don’t use tabs most of the time (I’ just too used to 3 spaces lol), but I’ve become more aware those using screen readers since I know a couple now, so I’ve tried to start getting used to it more and more out of concern for their usability.

1 Like
12

Tabs do make this slightly easier to implement, but indentation by a consistent number of spaces is no different from indentation by one tab: both can be translated by the editor to as many columns of indentation as you would like. This can only be done if the leading spaces per indent are consistent, which zig fmt provides.

Ease of implementation is basically irrelevant, since all editors I’m aware of are able to widen or narrow indentation, whether tabs are used, or whether a spaces-per-indent is defined for the format. It doesn’t matter at all. There’s nothing stopping any of you from changing your editor to display Zig indentation as 8 columns, or 2.

Similarly, given that spaces for indent are the more common modern style, I’m rather sure that screen readers designed for code can account for either style of indentation. If not, the developers are failing their users, and should fix that.

The reason I prefer spaces is because two invisible marks, one of them of variable width, has always been a rather awkward thing. The tab key is either a navigation and indentation button, or it is that but it inconsistently uses \t to provide that indentation, and I prefer the former.

But this barely matters in the last couple of decades, because editors can, and are, configured to handle this whole mess consistently.

There’s also the flip side of configurability: while editors can be configured to display either tabs or spaces however one would like, renderers, such as the one GitHub uses for fenced code blocks, frequently cannot be. Which is fine if you wanted your tabs to be eight spaces, but I personally find that excessive. With spaces, renderers display indentation precisely as the user intended it.

6 Likes
13

The two people I know say this is a problem. It is that spaces have a lot of repetition over just a single tab (this if you have to listen to every space, you would hate it too), but the problerm gets much much worse for braille devices that extremely limits display sizes and there the spaces waste a metric ton of “screen real estate”.

my tab key is literally remapped through qmk to alt on hold and backslash on tap (caps lock is control/esc), but I’m trying to be more aware if this. I broke my dominant wrist very very very badly a year ago and had to learn to use voice reg software for 6 months almost. Yes, you don’t realize the problems until you have to deal with taht shit.

3 Likes
14

mcedit wins
gs

1 Like
15

I did this in 0.15.2 starting with what Sumner did. Here’s 0.16.0 version, after around 3 hours going back and forth with public facing Google Gemini starting at google.com.

zig_fmt_2_spaces.zig itself is formatted with 2 spaces using the compiled zig_fmt_2_spaces.

16

When I started using Zig like almost three years ago, I came from the JS world and loved to indent with two spaces. zig fmt didn’t enable me to do so. And so I’ve started to appreciate the 4-space indentation.
Now, 4-space indentation is the kind of indentation I use almost everywhere (except for HTML).

17

The benefits of opinionated formatting are that it makes no one happy, but everyone consistent.
Other languages have proven the benefit of this, despite personal preferences

6 Likes
18

Exactly, I like to break things up into 1 thing per line and use more vertical space (and use more files), and Zig is just “nope, and here’s an indentation you aren’t used to too :fu:”.

I have dysnomia which makes it hard to recall the names of things, so I rely on scanning potential words to find the one I want, and formatting is so important for me to do it quickly both to keep names where I expect them and to give code a more distinctive shape as I can remember that better.

Indents being 4 spaces is enough of an issue I couldn’t use Zig if I had to use 4 space indents, and their other formatting rules that likes to squeeze everything together which is also a dealbreaker. It feels like the Zig team doesn’t appreciate that their opinions for what they think code should be is actively hostile against accessibility needs.

I’ve been forced to disable formatting entirely. So, because of the Zig team’s insistence on writing code a specific way now my code has no assurances it will be written in a standardised way, it’s entirely down to what I do in the moment, which seems like it’s about as far away from what the Zig team would want and they are responsible. Zig isn’t the first, I’ve had to disable formatting in Gleam too for similar hostile reasons.

I respect that if I were to make a PR or work in a team I need to use the standard formatting, but while I’m working I want to use my formatting.

2 Likes
19

It is quite the claim to use the term “hostile”.
I challenge you to provide a single shred of evidence that the Zig team is developing any aspect of the language or tooling with malicious intent towards anyone.

You may not like that the primary target is the 99.999% and they aren’t catering specifically to your niche issues at the cost of everyone else, but that doesn’t make it “hostile”. Using this type of hyperbolic language is immature, and is definitely not the way to get what you want. Don’t try to bully the Zig team into giving you want you want by insinuating they they have some nefarious dislike of “special needs” people.

Unless you can provide any evidence for you claim, a the right thing to do would be to recant your statement.

2 Likes
20

I didn’t say they were malicious, I said that their opinions on formatting (not the team) is hostile against accessibility needs. Malicious suggests an intent against someone/something, doing something that is hostile can be done innocently and completely unaware that it is hostile.

My evidence is that they refuse to allow for custom formatting to meet accessibility needs, it’s why I’m here.

You saying “99.999%” sounds like it comes from a place of ignorance, a lot more people have accessibility needs than you think, minority yes, but still a significant portion of users. You can’t just say “your needs don’t matter because you’re a minority”, that’s called ableism, people with disabilities should expect to get reasonable considerations to make things more usable - and control over code formatting is something that we should be able to expect.

I’m not, I read the guidelines which is clear about

But remember to criticize ideas, not people

So I’ve been criticising the idea of them dictating one way to format code, the Zig team seems to just be unaware and they will continue to be unaware until enough people mention it and to emphasise that it really is an issue. I don’t have any criticism of the Zig team.

I really don’t appreciate having my words twisted to a point they would break the guidelines.

6 Likes