I’m not sure why you bring up go. Is it the formatter in general? Because I thought Go likes tabs over spaces.
Yes, tabs are better than spaces, but using the standard formatter is better than caring about spaces vs. tabs. By orders of magnitude. Just stop caring and let the auto formatter do its job.
9 Likes
I wish that were true but it simply is not. Formatting files with spaces is just pure irritation. ie: if I want to tab and it inserts 4 spaces, not the 3 I have set as my default and then need to backup, I can’t just hit backspace, I have to hit it 4 times. That is only one example but forcing spaces has to be the most irritating thing I could think of forcing. I hope they don’t force this through the compiler at some point as it will probably be enough to force me to go back to go.
We are not all the same and attempting to force too much will only push people away. I understand standardization but tabs gives you 100% standard formatting without forcing anyone to view things your way. It also cuts the file size down drastically by getting rid of all of those space characters. Anyone arguing for spaces at this point just aren’t using their heads as there isn’t a single good reason for using them.
Glenn
I added those settings to my init.lua file but it has no effect on it. Still inserting 4 spaces. I’ve spent hours now trying to figure this out and nothing will stop it from doing this. I have no zig specific stuff installed and yet, any file with a .zig immediately adds spaces instead of tabs and ignores all of my settings. I don’t even have to save the file, it just does it.
Your setting to put at the top of every file doesn’t work either.
Thanks for the attempt though,
Glenn
Starting with a blank ~/.config/nvim/init.lua, I just added this line:
vim.cmd([[autocmd FileType zig set tabstop=4 softtabstop=4 shiftwidth=4 noexpandtab]])
and it seems to force tabs only. From there, you would have to see if this would still work with your other init.lua settings, maybe adding them piece by piece to see if anything makes it stop working.
That did it. I’m not sure why as I already had all of those options in my init.lua file but as opt values. Either way this fixed my issue.
Thanks again,
Glenn
1 Like
Believe me, I’m familiar with the argument.
The interesting thing is that this is purely incidental, there’s nothing essential about it at all. Indentation is indentation. We (meaning IDK, programmers, and especially the ones who work on editors) have decided that the display width of tab indents can be adjusted, but won’t extend the same courtesy to space indents.
It’s all code! There’s no reason whatsoever that the Zig-standard 4-space indent can’t be set to take up two columns, six, eight, whatever. It’s trivially easy to detect the difference between indentation and normal spacing.
We just… don’t do it. Who knows why. Perhaps the endless Tab Wars are too much fun. No idea.
4 Likes
In my case, I think my mental model evolved from the time I was in desktop publishing (kids: look it up.) Indenting with spaces and adjusting line / paragraph spacing with carriage returns was a cardinal sin. You’re using the wrong tool. Spaces are for inter-word separation and tab stops are for indenting and precise horizontal placement. Carriage returns will provide line or paragraph spacing according to the paragraph formatting rules you should have set up. So now in the world of code, I just feel like it should be the same.
It sure made the process of producing well-formatted and aesthetically pleasing documents much easier.
You know what, I’m gonna code in MS Word now. lol
1 Like
You wouldn’t be the first to do your programming in Word. (at least you get spell check).
1 Like
Is there a fix for VSCodium yet?
Spaces are a workaround for something I have yet to discover.
It feels like tapping w but getting vv, m but getting nn, " but getting '', …
Plus they look horrible when the renderWhitespace setting is on.
There is no ‘fix’, this is a decision by zig that is not configurable, whatever your opinions are, you either get used to it, change visible whitespace to be less annoying or don’t use zig.
Currently, zig accepts tabs in src, but that wasn’t always the case and may change in the future, if you don’t care to future-proof your experience you can disable auto formatting.
2 Likes
Why can your editor not display spaces at the start of the line any way you want? If it can do it for tabs, why not spaces.
2 Likes
You’re conflating the Zig programming language and its formatting tool. Telling me to stop using the language because I don’t like the tool is a non sequitur, similar to saying I should stop driving a car because I don’t like the adjustment of the driver’s seat.
1 Like
There was a time when tabs were not allowed in zig, so @vulpesx is not actually conflating the two, just warning you that such a situation may return.
2 Likes
It sounds silly to not use a language just because of the formatting, but multiple people have held that stance with zig specifically, so I was trying to express that you can have that opinion. It’s been a recent bad habit of mine to use far too few words 
as @Calder-Ty pointed out, I was also warning you that in the future, the compiler may not accept tabs in source code.
2 Likes
Technically true, but Zig is extremely opinionated. And here specifically formatting is brought INTO and made part of the language. So not using a language because of the formatting becomes understandable (unlike for most language) like with e.g. Python.
There are many people who don’t use different PLs because they don’t agree with certain decisions (rarely just one) and don’t have an opt-out.
While I personally agree with most decision of the core team and like what they are doing (and think that one core formatting is better than many options), I also accept that the highly opinionated Zig way will ensure that Zig won’t be able to replace widely used languages (like C; if all you care about is very wide usage, being highly opinionated without opt-outs is a drawback), even if publicly Zig often positions itself as a C replacement.
3 Likes
I understand the points made so far about personal preferences but I don’t agree about the impact on Zig adoption, if we’re talking about tabs or other issues that don’t have any real impact on the quality of the final program or the time to develop and maintain. The latter factors will almost always override those minor issues when making something that people will actually use and the project is serious. Personal preferences like that have to be lower priority when you get serious about doing something useful. And no matter what the language, there will always be things that aren’t to your personal liking.
2 Likes
As I wrote, it’s not one thing which is a problem but more like many small things which sum up.
We live these days in a time where we have more (seriously developed) programming languages than we know what to do with. This also means that teams have a wide choice and because of that can make a lot of things part of the decision making process.
3 Likes
In the specific case of tab indentation, though - as a couple of others have pointed out, it is surely not beyond the wit of man to write a text editor plugin that renders differently all spaces in a line that appear before the first nonspace. Wouldn’t this solve the issue?
1 Like
I disagree. When it comes to systems languages that provide maximum performance and do not have GC pauses, we only have C, C++, Zig and Rust as options. (You might also perhaps consider Odin, Nim and Swift.) When comparing these languages, there are many significant differences that are not related to personal preferences.
My guess (it is difficult to know) is that those who reject languages based on personal preferences are doing so out of hand, and will be back to reevaluate once the drawbacks and realities of their other options are well known. To really evaluate a language you have to do a significant amount of real work in it.