Sorry, changed "spaces" to "columns".

... and the only reason for it to be four columns is that you personally find it hard to read, or do you have another, more compelling argument against using 8 column tabs?

Personally, I find 8 columns to be an incredible waste of horizontal space. I frequently place editor windows/panes side by side, and using 8 columns or spaces wastes valuable screen real estate.

But this isn't just a reaction rooted in practicality. To me, this looks and feels absurd. It kind of hurts to read. Again, this is just my personal take.

I prefer scope indentation of any kind to render as 4 spaces, but I'm okay with 2 as well.

I agree. For me, I want enough indentation to make the structure obvious. 8 columns is way overkill in that regard.

I'm kind of surprised that 8 column tabs is even being discussed, I thought 2 or 4 were the normal values?

> and the only reason for it to be four columns is that you personally find it hard to read

Yes, it was just a personal opinion.

But not personal enough not to be the basis for an argument about what github should do to display Go code.

What are you arguing about exactly? Am I not allowed to think Github should display them as 4 columns?

I don't think gofmt assumes any width for tabs. It, prints `\t` for indentation, and that's all.

It has the -tabwidth option, defaulting to 8. I have yet to figure out what it's used for, but presumably there is some case where it is used for alignment.

> It has the -tabwidth option, defaulting to 8

It was only used when you invoked the other option to use spaces instead of tabs. Both options are now removed. gofmt doesn't care how wide your tabstops are.