Yes, I am one of those people. I hate using spaces for my tab key as it forces everyone to use the same spacing. Some people might like three spaces, and others might like eight. With tabs, your editor can be set to make the tab spacing, or you can choose whatever you want. If you use spaces for your tab, you force everyone to view the code the same way, which we don’t all like to do.
As a result, I have noticed that when I’m in a zig file, everything keeps getting replaced with 4 spaces. Is there a way to turn this off and have it use actual tab characters instead? Or might something else be going on?
I would suggest keeping the zig fmt style of 4 spaces for indentation.
This gives the zig community a common code style.
Of course no one likes all the choices made for zig fmt, but these are choices that require no effort to adopt.
The go community, that pioneered using a common formatting, says:
“Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite.”
- The Go Proverbs
Thanks, and I understand; however, tabs don’t break that formatting. In fact, they allow any number of spacing options without actually changing the file itself. ie: If I want 4 spaces and you want 8, we both get what we want and the file itself doesn’t have to change. I’m also trying to see if I can work Zig into our company, which has nothing to do with the community of Zig, and all of our developers are used to being able to set their tab spacing however they want.
BTW: I hate google and the go formatter is the number one thing I hate about Go.
So where can I maybe change this option in zig? I don’t want to get into the age old debate about spaces versus tabs but a few minutes of consideration proves using actual tab characters allows for formatting the way people want without messing with the code base itself. Spaces force everyone to conform and is also why I don’t program in python.
I assume that is a neovim file somewhere? Do you happen to know where those are stored on linux? I’ve never messed with them before but this is worth figuring out for me.
It is not super clear whether tabs will continue to remain legal in Zig source code (in the past tabs were a hard compile error, currently they are (mostly) allowed but normalized into spaces by zig fmt) but judging by this comment it seems like they might be made illegal again in the future:
Couldn’t we just add an error like file uses tabs/carriage returns; run 'zig fmt {path-to-file}' to convert it to the canonical form. It would allow us to completely ban tabs/CRLF while also providing a pretty decent user experience.
Yes, I’m thinking along the same lines. Make it a hard error, just like unused locals, and then have --autofix (as well as zig fmt) make the compilation “just work” while modifying the source files to comply.
If you’re serious about writing Zig, I would suggest ripping the bandaid off and getting used to spaces sooner rather than later. The Zig compiler team has made their stance fairly clear that canonical Zig source code should use spaces and LF line endings.
Not sure what you’re sending me. I have notabs set as I don’t want spaces and I already have nowrap set. The issue is that zig replaces my settings and puts spaces instead of tabs in my files. I’m trying to stop that from happening. I don’t currently have any zig language files installed in nvim so not sure why this is happening.
Thanks for the update. That really does suck. It sounds like they are having issues with the compiler related to tabs. The entire thing seems odd. Sorta like the women baking the bread and cutting off the edges because that was the way their grandmother taught them to do it. When someone went back to the grandmother to ask her why she did it, she told them it was because her pan was too small.
I guess if they can’t make it work, I’ll have to deal with it, though. It’s disappointing because it forces everyone into one way of doing things that can never be changed.
You may want to check the nvim runtime modules that come with standard neovim. There are default ‘.vim’ files for zig that are in “compiler”, “syntax” and “ftplugin” directories.
TAB was always controlling command (ASCII code 0x09, not printable character) on “terminals”. Hence all these stupid wars about whether an indentation should be TAB or N spaces and if TAB is visually replaced by a text viewer/editor by N spaces, what a width of a TAB in spaces should be.
“zig” as a compiler (at it’s lexer step) does not replace nothing with nothing.
It may stop processing input at any UTF-8 entity that looks like ASCII TAB,
so what? It’s not eatable at all (like a bread baked by that grandmother )
I think forcing everyone to use spaces for indentation is like willingly shooting yourself in the foot. Rob Pike sums it up quite simply here.
When you use spaces, if programmer A wants 4 columns wide and programmer B wants 8 columns wide, you end up with two source files with different bytes. If you use tabs, they adjust their editors to suit their preference and both will produce the exact same bytes in the their source files. Oh, and speaking of bytes, they’ll be less bytes, given \t is less than \s\s\s\s or \s\s\s\s\s\s\s\s.
vim.g.zig_fmt_autosave = 0 # In lua
let g:zig_fmt_autosave = 0 # in vimscript
If you would like to align this configuration across your organization by committing the configuration to your repository, I would suggest exploring configuring ZLS via a json file as described in
As of right now, I am not aware of any configurable code formatters for zig. The zig team (which I am not a part of) has chosen to provide a formatter with minimal configuration, so you may need to wait for one to be developed (or develop your own!), could be a fun hobby project.
And finally, if you would like to have the best possible experience with ZLS, I suggest reading this post by @kristoff
Thanks for the info. I stick to the stance that there are literally zero defenses for opting to use spaces for standardization. I’ve read other peoples arguments on the subject and they make no logical sense. I hope the zig programmers don’t opt to outlaw tabs but I guess I will have to deal with it if they do. I hate go for this very reason so hopefully we don’t follow their direction just because.
Source code is smaller, more standardized and can be viewed by anyone, anyway they like without effecting the underlying code base. Spaces have none of that going for it.
Anyway, I have no zls installed atm. I have not included zls through Mason and have checked that it isn’t installed. However, if I vi a brand new file with .zig on the end, as soon as I hit tab, it inserts 4 spaces. If I do this in other file formats it does not. This includes go files.
I’m not sure where this is coming from but still looking. It is interesting that I am seeing zig errors when I save, so something is installed somewhere, just can’t find it. The spaces are being inserted way before any saves take place though so it must be deeper.
Thanks, it still doesn’t explain why files ending in .zig are immediately having tabs replaced with spaces though. I can take a brand new file named test.zig and it just inserts spaces as though that is my default. Every other format operates correctly. To my knowledge I have not installed anything that would do this.
are set somewhere? They are default behavior, even without installing any zig specific additional software.
As a kind of band-aid solution, you can also put // zig fmt: off
at the top of every file to stop undesired behavior.
