Discussion on: Use Tabs For Indentation

[Ben Sinclair]

I don't see a problem with having spaces, and enforcing that with a .editorconfig file. I think your IDE should handle loading and saving and indenting according to those rules, and if you have a different requirement, the IDE should handle that, too.

Like, say if someone wanted to merge a commit with tabs into some Python, and I was editing in Vim, I'd have it :retab on load and save, so I'd see it using my preference regardless of the file's origin and when I did save, all the mismatches would be automatically fixed. I'm certain you can do that in IDEs too, right?

[Yufan Lou]

Accessibility means the code looks different according to different needs, instead of the same everywhere. So first of all we need a culture change.

If you read the post, what you propose is what the people with visual difficulties have had to do.

these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing

It still counts as "serious problems" for them! It's not just this one problem. To learn how to configure your IDE you need to read the document, to Google for help, and every step is much harder for them to take than for us. I usually do not prefer Golang, but I recognize that it is designed to solve Google scale problems, and I suppose they hire enough people with visual difficulties to use tab by default.

[Ben Sinclair]

I understand what accessibility means, I also understand what was written in the post. What I'm saying is that presentation of the code is the responsibility of the IDE - it already will allow you to specify tab widths, it should understand indentation widths and do the transformation automatically.

IDEs already do this with things like line endings. The accessibility problem is in the software not the format of the file.

[Yufan Lou]

Let's go through what the workflow of someone who needs to transform the file from tab to space might look like:

1. They clone the repo
2. They open the file in their editor of choice, which transforms the file to their preferred indentation width
3. They do their changes
4. They save their changes along with the new indentation width
5. They transform the file to the indentation width preferred by the project
6. They commit their changes back to the repo

Problems:

• Step 2 and 5 might be erroneous, adding one step following them
• I have not seen IDE do step 5 automatically, maybe because it may be erroneous

What does the workflow look like if the project uses tab?

1. They clone the repo
2. They open the file in their editor of choice, displayed in their preferred indentation width
3. They do their changes
4. They save the file
5. They commit their changes back to repo

Indentation width of every developer of the repo is respected, without transformation.

I do not have a strong personal preference to tab over space, nor to a specific indentation width. But I have a strong preference to protecting the marginalized people and fairness. A project-wise indentation width can be formatted with either tab or space. Formatting with space incurs more work for those in need of a different width than not. Formatting with tab incurs the same amount of work for everyone regardless of which width they need.

I agree that IDE can help. An IDE which maintains both the user preference and the project preference and can transform between the two is probably sufficient for 90% of the use cases. But that's not 100%, and does not change the essence that formatting the indentation width with space ends up being not as fair as with tab.

[Ben Sinclair]

What's the 10% of cases where automatically formatting the document isn't sufficient?

[Yufan Lou]

I don't know yet. Right now such IDE capable of auto-converting formatting don't exist to my knowledge so they cover 0% of the cases. If I find IDE plugins with such feature out in the wild, then I can know what cases they do not cover from user comments.