Precedence of tab-stop configuration

[Alhadis]

First of all, thank you so much for finally supporting configurable tab-widths on GitHub. I've noticed that the previous kludge of using EditorConfig to configure tab-sizes no longer works. Granted, this was an unwelcome hack that forced many GitHub users—myself included—into setting an indent_size even for projects that use semantic indentation (as the browser default of 8 columns bothered many folks).

Regardless, forcing a specific tab-size is necessary or desirable in certain situations, such as when dealing with tabular data or legacy codebases that assume tabs will always be 8 columns wide (particularly common in C, old-style FORTRAN, and some assembly dialects). The chief benefit of using tabs is that everybody can read code at the indentation size they're most comfortable with. This added readability goes out the window if the file isn't indented semantically. For example, Apollo 11's source code becomes unreadable to users whose tab-size preference is anything other than 8.

On the topic of file-specific tab-widths, it'd be great if GitHub honoured Emacs and Vim modelines in addition to the EditorConfig approach. The order of precedence should be:

1. Vim or Emacs modeline (whichever appears first in the file).
2. EditorConfig tab_width or indent_size properties (unless set to the value of tab, tab_width should take priority over indent_size)
3. User's own tab size preference (8 by default).

Ideally, authors shouldn't have to specify a tab-stop size (since this defeats the purpose of using tabs in the first place). But if they do, it should be assumed it's for a good reason.

[Levi-Lesches]

...why can't users just adjust their preference to make the code look readable to them? Your assumption that the repo only sets a tab-size when absolutely needed -- and that it's reasonable -- is a strong one that's probably not true everywhere. The user, however, can always be trusted to set the tab size to what they prefer. Again, that is the whole point of using tabs. If a repo really wants to force their preference, they can just use spaces.

[Alhadis]

Your assumption that the repo only sets a tab-size when absolutely needed -- and that it's reasonable -- is a strong one that's probably not true everywhere.

@Levi-Lesches Users can always submit pull-requests to remove opinionated tab-sizes from EditorConfigs, but they can't adjust their preference on a per-file or per-repository basis. Moreover, some coding styles (notably the Linux kernel) assume tabs to be of a specific width, resulting in that godawful mix of tabs-followed-by-spaces. As rebarbative as these code-styles are, they become much more insufferable when code isn't aligned properly.

Much as I'd love to live in a world where everyone uses tabs correctly, I'm afraid the reality is much more different. Giving authors the benefit of the doubt seems wiser than assuming their code has been formatted correctly/semantically.

[Levi-Lesches]

Users can always submit pull-requests to remove opinionated tab-sizes from EditorConfigs, but they can't adjust their preference on a per-file or per-repository basis.

But you can still change your preference site-wide. If the tab size is so prevelant, then keep it. Otherwise, turn it back to whatever you really prefer after you're done checking out that repo.

It's much easier to edit your own preference than to submit a PR (and get it approved + merged) in every repo you visit.

[Alhadis]

But you can still change your preference site-wide. If the tab size is so prevelant, then keep it. Otherwise, turn it back to whatever you really prefer after you're done checking out that repo.

Temporarily updating one's preferences isn't a realistic solution, because

1. It's an annoying 4-step song-and-dance at best: open preferences, update tab-width setting, refresh page(s), revert temporary setting.
2. It breaks down if users are reviewing multiple projects at the same time,

It's much easier to edit your own preference than to submit a PR (and get it approved + merged) in every repo you visit.

True, but the latter has the added benefit of fixing repositories whose EditorConfig's indent_size was only added to override the 8-column default on GitHub; i.e., editors will benefit from such PRs as much as GitHub users will.

I should point out that a bookmarklet like the following offers an even easier way to override tab-sizes and gives users the last say in what size to use:

JavaScript: void (() => {
	const size = ~~window.prompt("Enter a tab-size", 4);
	if(size < 1) return;
	for(const el of document.querySelectorAll("*"))
		el.style.tabSize = size;
})();

[Levi-Lesches]

True, but the latter has the added benefit of fixing repositories whose EditorConfig's Indent_size was only added to override the 8-column default on GitHub; i.e., editors will benefit from such PRs as much as GitHub users will.

Now it kind of sounds like you're saying repos shouldn't be using EditorConfig just for GitHub -- submitting PRs to get rid of them is a good first step, but allowing EditorConfigs to override user preferences seems to be going in the opposite direction.

[Alhadis]

It depends on the author's intent. If the indent_size rule was added solely to override the default of 8 columns on GitHub—which is an unfortunate kludge many users have resorted to—then that's a rule that any accessibility-minded author shouldn't think twice about removing. On the other hand, if the author has their reasons for continuing to enforce a specific tab-size, then that's the sort of thing they can clarify in a discussion on said PR.

[diamondburned]

I have noticed that the .editorconfig tab size still works in the file editor built into GitHub. It just doesn't work in the code view. I think at one point during the migration, they probably didn't consider supporting it.

[Alhadis]

tab_size defaults to indent_width, and its usage really only makes sense if you're indenting with spaces (some ancient GNU projects indent with 2 spaces, but use hard-tabs for aligning comment columns, usually at the traditional tab-width of 8 columns).

That being said, it makes sense why GitHub simplified EditorConfig support like this.

[diamondburned]

It's not a necessity, but I think it makes more sense that GitHub's code view should make basic attempts at respecting repository-specific defaults like these. There could even be a toggle for users to override .editorconfigs for themselves.

Given that they still have the ability to parse .editorconfigs, I don't think it would be a lot of code to do the rest.