Configurable tab size setting

Issue #11111 open
Zachary Davis
created an issue

Many users have requested a way to permanently set the tab size at either (or all of) the repository, team, or user level. This is a follow-on from #6207 which provides a query param for configurable tab size, but isn't sticky (meaning that it needs to be re-applied to each page view and doesn't follow the user through navigation).

Comments (30)

  1. Zachary Davis reporter

    I believe this makes the most sense at the individual/user level, because at the end of the day it's a display option and I don't think one user should be able to change another's display option (by setting tab size at the repository or team level).

  2. Eric Grubaugh

    @zdavis I think it still make sense to include configuration options at every level if you introduce an order of precedence for each setting. This way, you could check the most specific setting first, then gradually move up the chain until you fallback on the browser default. In other words, check for settings in the following order, and use the first one encountered:

    1. User profile setting
    2. Repo setting
    3. Team setting
    4. Browser default

    At the User Profile setting, in addition to specific tab sizes, you could also include options of Use repo default or Use team default. Same at the repo level, you could include a Use team default selection for the tab spacing. Does that make sense?

  3. Aaron Scully

    I like the idea of a repo setting, though I'm not sure about different people on the team being able to override it. The issue I would like resolved is that someone commits a file that used to have spaces for indentation and it now has tabs. I would like pull requests to show the files with only those changes as being identical and not having changed. For this, it makes sense to have a repo setting that treats tabs as X number of spaces (usually 4 for most IDEs I've used). If users could override this, then one person viewing the pull request would see something different to someone else.

  4. Brandon Smith

    Aaron, you suggestion is a good one. But I think that should be requested separately, since it's really a completely different issue.

    As for this particular request (and specifically in reference to @Eric Grubaugh's recommendation), I don't see a problem with this at all. The user's ability to override these settings locally should not affect any other users, if I am understanding correctly. It would simply provide user-level override of the broader settings for the team or entire repo (if the user has defined any such settings).

  5. Chris Wareham

    Making this and the option to ignore differences in whitespace (currently it's only available as a query string parameter ws=1) a persistent user option would be fantastic. A lot of legacy codebases have a mixture of tabs and spaces for indentation, and many people have their IDEs configured differently or to convert whitespace automatically on lines they modify. This makes code reviews awkward, as at present I have to add ?ws=1&ts=4 to the diff URL every time I do a code review.

  6. Reid Turner

    +1 Please implement a persistent, configurable solution.

    BTW, GitHub has a solution with their .editorconfig file where you can define tab size and line ending for various types of files. This is much better than adding &ts={whatever} because it's sticky and doesn't require new users to do anything special.

  7. Build Farm

    Allowing settings at each of the various levels (account/team/repo/user) would be very good. Most organizations have coding policies that dictate how one is supposed to do things, and allowing them to make their repositories match those policies (so that deviation from them stands out) would be useful. That being said, override at lower levels is always needed for the allowed exceptions (imported third party code that follows different conventions, for example).

    The editorconfig thing would work too, but it seems to me that fully supporting that would be significantly more work and I'd rather get tab width sooner than wait for a more comprehensive feature.

  8. Eric Tung

    This is bordering on the line of unprofessional. The ask is clear, the feature is simple.

    People have been asking for a real solution since as early as 2013. I am failing to understand why this is being ignored.

  9. Log in to comment