FWIW when this conversation comes up, the reasoning is almost always that an IDE or otherwise can handle the display, or that changes in a build.zig can fill the gap in other ways.
It seems to me like there’s a hole to be filled by a simple repo that explains the details of how to set that up. Can that be filled in by the community? It would seem valuable and appreciated by those with accessibility needs.
If you want an alternate formatter, there are several around, including ones that allow for 2 space indent.. The Zig team isn’t against people using other formatting styles and formatters if they want, except in the Zig codebase.itself. They aren’t going to make the Zig fmt command configurable, but nobody forces you to use it.
Time to bring up zift
Customizing indents is about the main thing it does. There’s a AI-assisted fork in the comments that does a lot more.
Dyslexic here. To be honest, I very much prefer “cuddled else”, so it’s:
if (cond) {
// ...
} else if (cond) {
// ...
} else {
// ...
}
The way, every non-indented line is a condition.
I’m genuinely calmer with cuddles elses, so I don’t know if dyslexia matters here, or if it can go in either direction.
The argument isn’t that all dyslexic people want it a certain way, it’s that for some of us having control over formatting is essential for usability.
Outsourcing accessibility is not something that should be shrugged off. Indentation is just the tip, there’s a lot more that is expected if they are baking in a formatter.
I can’t rely on third party formatters to stay updated and usable, I don’t even understand how to use zift and it is lacking a lot currently. I won’t be able to rely on a formatter being usable next year.
Rejecting formatting for accessibility reasons from the official formatter is interpreted as being told that we’re doing it wrong, and because it’s what we need to do then we are wrong, our disabilities are wrong, don’t be disabled and use the default formatting.
Accessibility should not be seen as an inconvenience that is acceptable to avoid.
Consider this for a moment: Zig is inaccessible to people who don’t speak English, because all language keywords and builtins are in English, and the standard library and documentation is also in English. If you can’t comfortably read/write in English, you will have a much more difficult time using the language. Additionally, if your native language uses characters other than ASCII letters and digits, and you want to name identifiers in your native language, you need to use the cumbersome @"" syntax, which might be discouraging enough that you decide to use less readable unaccented or romanized identifier names instead.
Arguably, this inaccessibility is even more hostile to the user than the one you bring up, because unlike zig fmt which is a completely optional component that isn’t forced upon the user, the ability to read/write in English is a fundamental requirement in order to comfortably use Zig. It also affects several times more users; if we quickly check with current statistics from Wikipedia, about 80% of the world’s population don’t speak English, compared to the estimated 3-20% who are affected by dyslexia or dyslexia-like symptoms.
People absolutely hear you and sympathize with your situation. But when it comes to zig fmt, a judgment has to be made: is it more important for it to be opinionated without any configuration options so that all users and projects who decide to use it settle on one unified style, or to be a helpful tool for users with accessibility needs? zig fmt decided to go with the former. This shouldn’t be read as “people with disabilities are wrong and zig fmt doesn’t care about them”, it should be read as “there is an infinite variety of preferences, disabilities and accessibility needs that users can have and it’s simply impossible for zig fmt to be of meaningful assistance to them all, so it’s better if you use a different dedicated tool designed specifically to provide the maximum amount of help for your specific needs”.
Yes, there is an infinite variety and it makes sense for the zig language team to focus on English and single standards for things.
Also for Ziggit participants who share these problems or have relevant skills to address them, what’s the best way to work on these new independent solutions?
(It’s not my area of expertise, but it feels important and I wanted to invite more discussion of what these individuals need - and to separate it from a discussion about what the zig team should do.)
That is true, but formatting is something that can actually be solved without creating brand new variants, although it is something that does exist. I have not provided any input on this prior and fail to see how it is an apples to apples comparison.
You should check out the formatting that JetBrains products offer, it’s not impossible to do something similar.
I’m not feeling heard, I’m feeling like because it doesn’t affect people that they can’t see why it would be so important. I don’t know how to properly communicate the importance to people who would not benefit in any way, and who may actually be “worse off” because they might see non-standard formatting in someone’s personal projects.
I’ve dealt with strawman arguments, false equivalence, and bean soup here. So it doesn’t feel obvious that I feel heard, I feel like people probably think I’m annoying going on about something they don’t need, and that I might be spoiling an orderly ecosystem. I feel like I hear and sympathise with those who want to keep things how they are.
There are a number of options already discussed to get the outcome you want:
Auto formatting to a standard format across all projects is something that regularly saves time in PR review and removes a whole class of back-and-forth when working in a team. This happened overnight at our work when we started autoformatting a few years ago. It also avoids style arguments in open source contribution. And I think the zig team has made the right call in supporting a single, nonconfigurable format, and it will save many, many hours of time down the road in larger projects. It feels to me when reading back here that you may not have considered the benefits and assumed it’s just an opinionated preference with no utility. But there is value in the restriction as well, and building a widely used toolchain is about making these tradeoffs and not pleasing everyone. The fact it is open source means anyone has the power to patch in things they want.
I appreciate your situation and it honestly sounds difficult. But I think you could be drawing a false equivalence yourself between a specific solution to a need caused by your disability and implying the Zig project sees “accessibility as an inconvenience that it is acceptable to avoid”. I haven’t seen any evidence of that as a general statement and I think implying that is the case takes away from the discussion of how to best solve this need for someone who needs it.
I appreciate your precise wording of what is and what’s felt.
After some digging, I found what @andrewrk had to say about the matter in Oct 2023. Although its specifically referring to tabs vs spaces, I think it generalizes.
https://github.com/ziglang/zig/issues/17723#issuecomment-1783685137
I don’t buy the accessibility argument.
To be clear, I think empathy towards those with [a disability] is certainly warranted, however, let’s try to analyze the problem like engineers. A programming language’s job is to give semantic meaning to a source file. If a programming language led to ambiguity about whether something is indented or not, or whether it is a keyword or a function, that would be a problem for accessibility. …
Now, I think it is totally fair to argue something like, “I don’t care about in theory how it should work, I care about results. Just make it better for people who have trouble [with X problem].” Now that’s an attitude I really identify with. However, no matter which angle we look at it from, this one, or the previous paragraph, the accessibility villain is clear: the text editor.
It is trivial to know what is indentation in a source code file, especially in Zig. Text editors are already the ones providing the font size options, and it’s absurd that they are not also providing the indentation size. …
So, please redirect this accessibility shaming at your text editor - the app that you are literally looking at.
I agree with this argument, and I think it generalizes to issues like for example, spacing around an if statement if ( foo ) ... (disclaimer IANATED (i am not a text editor developer) something something tree-sitter). I’m not aware of any text editors or plugins that implement something like this though, so it does sort of feel like kicking the can down the road.
But in a later comment he does say,
I reserve the right to change my mind on this topic before 1.0.
The thing here is, text editors already DO provide the ability to configure the indentation size since a LOOONG time. It’s called tabs. (Nearly) every editor I know of has a way to specify how much a tab should be in indentation.
But with spaces you specifically ask to NOT have that configurable. That’s what tabs are there for.
It’s as if somebody would want to run an if multiple times if the condition continues to be true. Don’t change the if, use a while instead.
This is the same thing.
I don’t think this needs to be true. Some people (in this thread) would like to configure the length of 4 spaces, whether that be by making zig fmt have 2 space indentation or by visually making 4 spaces look like 2 spaces.
Maybe that’s impractical and everything would be simpler if we just all used tabs. I don’t know.
This is assuming a world where if means run something once if a condition is true. The other thing is assuming a world where 4 spaces means visually showing 4 spaces. Those things could be false, although the if one is a little silly.
Ok, so it turns out I do have a criticism of the Zig team after all, oops.
I also don’t know of any IDEs that do anything like what Andrew described; so accessibility has been offloaded onto a made up technology that has no precedence and is unrealistic beyond indentation widths. Even though other languages either don’t have an official formatter and therefore community formatters are relied upon enough you can rely on them to continue and to be feature complete, or they come with one and they’re either configurable or not accessible, and I’m not aware of others blaming IDEs.
Hopefully it’s revisited before 1.0 then.
Relax cowboy. Try googling a bit before each answer. This tech is out there and it’s getting really good:
Problem is that people are really rooted in existing tools and companies have no incentives to refactor their entire IDEs.
There’s no need to be condescending. I was also not aware of this. It does look pretty cool and seems to be capable of what we’re talking about.
i don’t think the intention was to be condescending, but the emotional “edge” to the message is probably in response to the line “a made up technology that has no precedent”, so i think it can be forgiven 
Fair perhaps I’m a cowboy as well
I tried to run this and it just decided to use a core at 100% without loading…
Anyway, does this editor actually allow you to edit in the AST renderer or is that just a visualisation? If it’s the latter it’s only a half solution to the problem here.
You want something for indentation and for alignment.
Two different purposes.
Sure, one could differentiate one by checking if the space is at the beginning of the line or not, but why not just use tab stops which were invented for this purpose?