1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #6207 resolved

Fix tab size in source code viewer (BB-7488)

Jamon Holmgren
created an issue

All you need to do is add one line of css to the .refract-container .source:

.refract-container .source {
  padding-left: 73px;
  tab-size: 2; // Add this line

It doesn't screw up anything and makes tab-indented code look much better.

Comments (90)

  1. Ewen Wallace

    How about making it a user-option? or better yet, get it from the repo settings like KilnHg does for Hg. I'm referring to

    pager = less -FXRS -x4

    & / or

    core.whitespace = tabsize=4
  2. Kevin VanGelder


    That's an interesting idea but I use Git for more than one language. For RoR I use spaces as tabs but for PHP I use tabs (sized at two spaces). Setting a global Git setting would mess up one or the other language. Also, I'm not sure that a Repo host has access to my global settings...

    I think an option in the user's panel would be great but I would settle for either four or two spaces.

  3. Neil Kirsopp

    Some solution to this would be nice. I use tabs consistently (my editor shows them as 2 spaces for HTML, 4 for most code, etc...). 8 spaces makes reading things on the web unnecessarily painful in many cases.

    To be honest, I'd be happy if tabs were just rendered as tabs when viewing source - that way I can use a Stylish fix of my own. Currently that only works for diffs.

  4. Huu Da Tran

    I'm with Dave Stewart on this one. We should be able to see the difference between a [TAB] and spaces.

    Even custom, you would have to make it language-specific. So a custom option per language with the possibility to display the real TAB character would be the best feature.

    I hate to approve a Pull Request and only know later that it looked "nice" because it expanded TAB instead of showing me the actual TAB character.

  5. Leo Unglaub

    In the *nix world there is already a fix for that. I think it would be nice if BB would parse the file and look for something like that:

    # vim: syntax=php ts=4 sw=4 sts=4 sr noet

    So everyone could define the tab width for themself. Greetings Leo

  6. 13ren

    People expect tabs as 8 spaces. It's a standard! Therefore, a config option on the admin front page:

    Repository Details
      Language: ________
      tabs: _8_ spaces

    Just under (or adjacent to) Language, because it's the only other rendering option.

    EDIT Actually, it would make sense and be a very easy implementation to add a "2 tab" version for each language syntax. Then, just copy the syntax spec file, and add that rendering of tabs - no need to mess with the GUI at all. Easy! Easy and ugly.

  7. Phil Cook

    I have a temporary workaround for this issue until bitbucket are able to solve this for us.

    You will need to install a Chrome plugin called Stylish. Once installed you can use this small script and add to stylish. The script contains a simple CSS override and turns tabs into 4 spaces for the domain bitbucket.org. You can adjust the tab size as you like.

    Hope that helps until bitbucket gives us a solution to our woes.

  8. Anonymous

    The code view in the wiki and the repo is now broken. I have a usercss, which sets the tab-size to 2. But this bracked a few days ago. There is not even a config for the indentation in the user settings.

    Just make the code view work again, please!

  9. Leo Wandersleb

    I find it funny that the worst case mentioned is "a lot of indentation". I am annoyed for another reason: Screenshot from 2014-08-20 11:55:46.png

    I guess you can imagine how it looks in my IDE. Sure, this might be a use case for spaces actually. Still, in Eclipse the default is 4, not 8 spaces, so we are fine with tabs if it wasn't for bitbucket.

  10. Jamon Holmgren reporter

    Despite being a Ruby developer who uses spaced indentation almost exclusively, I still think tabs are superior. Except when you're dealing with crappy editors/code viewers who don't allow tab size customization....

  11. Sébastien Gautrin

    Leo Wandersleb this is a perfect example of how not to use "tab indentation": you are using tabs for formatting, and thus your perfectly aligned display fails as soon as your editor tab size is not as expected. Tabs should be used for indentation only, and never for formatting (to be noted that for me using spaces for indentation is an heresy).

    Jamon Holmgren crappy editors/code viewers don't matter much when you are using tabs for indentation only (and not formatting); it is only somewhat inconvenient (like Bitbucket) when it decides to use 8 spaces for a tab. The point of using tab indentation is that, given the proper editor/viewer (which BB is not in this regard as of today), you can select the size you're more comfortable with, without changing the semantics (which is why whether a team chooses tab indenting or spaces indenting - sic -, the first thing is to ensure the practice is coherent, which is obviously not that much spread considering how many people want #6024, as it should be a non-issue given proper practices)

    Personally I obviously find the "8 spaces for a tab" on BB inconvenient, but I'm much more bothered by the fact that BB doesn't visually distinguish between a tab a 8 spaces (for now, 4 or whatever they choose some day): when reviewing code on BB, it is quite important for me to be able to verify that the author actually respected our coding practices of using tabs for indentation; and with that in mind, considering we are recommend our developers to visualize tabs with 4 spaces and not 8 (and considering it's the default in most recent editors), this defect of BB of displaying tabs with 8 spaces is better than if they used 4 spaces, as at least with this behaviour I can easily spot developers who used 4 spaces instead of tab to indent (because it will be displayed as 4 spaces and not 8 on BB, and produce fubared code formatting unless done on the all file). If they were to simply switch that to 4 spaces or even configurable width (which we would set to 4 spaces so that it matches our usual display), I would lose this means of spotting bad indentation practice.

  12. Leo Wandersleb

    Sébastien Gautrin yeah, you are right, I could configure Eclipse to treat tab differently for that file yet as I mentioned in my post it works perfectly for the whole team of 5 as it is now, if there wasn't this small glitch when reviewing stuff on bitbucket and so I can only agree with Jamon Holmgren. Either let me do my thing, or try to convert me to "do it right". Any IDE allows me to define how many spaces should be used per tab, so why not bitbucket? It's a tool, not a religion.

  13. Ascari Gutierrez

    For now, you can inject the tab size yourself via a bookmarklet:

    4 spaces per tab

    javascript:(function(){ var style = document.createElement(%27style%27), styleContent = document.createTextNode(%27.refract-container .source { padding-left: 73px !important; tab-size: 4 !important; }%27); style.appendChild(styleContent ); var caput = document.getElementsByTagName(%27head%27); caput[0].appendChild(style); })();

    2 spaces per tab

    javascript:(function(){ var style = document.createElement(%27style%27), styleContent = document.createTextNode(%27.refract-container .source { padding-left: 73px !important; tab-size: 4 !important; }%27); style.appendChild(styleContent ); var caput = document.getElementsByTagName(%27head%27); caput[0].appendChild(style); })();
  14. Victor Engel

    I found a kludge to do it. Just create a regular bookmark, then edit the bookmark, replacing the URL with the script. I note that these scripts will not work for delta displays showing line numbers. The leading tab must be larger. An example, would be looking at the changes that go with a pull request.

  15. Chris White

    Is Bitbucket no longer under development? It's very discouraging to have features (bugs) this easy to fix that haven't been resolved, and no feedback from Atlasssian other than marking a similar issue as a duplicate. It makes me question using Bitbucket over Github.

  16. Zach Davis [out until 9/26] staff

    Hi all,

    Thanks for your interest in and feedback on this issue. We just deployed a change that allows tab size to be set via a query param when viewing source or diffs. For example, you can add ts=4 as a query param to any url to set the tab size for that page view to 4 spaces. This is non-persistent and needs to be set for each page view in order to apply. We are hopeful that we can provide a solution that allows this to be set through the UI in a more permanent fashion, but that will be separate future work.

    Supported tab sizes are any integer 1-8.

    Please let us know if you encounter any problems or have any concerns.

    Cheers, Zach

  17. Zach Davis [out until 9/26] staff

    Maxim Novikov Yeah, that's fair. I certainly debated whether or not to resolve this or just leave a comment. I guess my thinking was that the functionality is there now, is on-par with what Github provides, and that the UI component should be tracked separately (similar to the ignore whitespace stuff we did recently). But I can re-open until we deploy something that tackles the UI problem.

  18. Tri Nguyen

    Zach, I think it is fair to resolve the issue as a mark of feature completion. Why not just create another issue to track the work of the UI component and point the watchers of this issue to there? Personally I'd like to watch the issue for UI for the whitespace feature as well.

  19. Aaron Scully

    Tabs should be 4 spaces. This is the default for pretty much all the IDEs I've used. Better yet, though, have them as being configurable. Pull requests are a real mess when tabs are set to 8 spaces.

  20. Zach Davis [out until 9/26] staff

    Eric Grubaugh I've created issue #11111 to track the configurable setting request. I understand the downside of this is that it loses the votes and the context, but I believe it to be a somewhat separate issue. Feel free to leave any relevant feedback there.

    Aaron Scully 8 space default for tabs is a browser default, which we chose not to override. Understand that there are plenty of people (including many who have commented on this issue) that prefer 8 spaces. That widespread difference of opinion is why we created the query param override and is why we're also interested in creating a configurable setting in the UI.

  21. Niklas Brunberg

    Zach Davis [out until 9/26] "is a browser default" is a rather odd argument to make to avoid making CSS changes, after all the same could be said for just about every single line in the Bitbucket site CSS, consider:

    • Headings (h1 … hN) and paragraph (p, li, …) styles using a serif font family is a browser default and therefore we should not override it with a sans-serif font.
    • The body element has a webkit default margin of 8px, and therefore we should not override it.

    …and so on… I bet you get my point. The widespread difference of opinion however is a very valid reason to consider before/if implementing this request, however.

  22. Anonymous

    you can also write your own custom.css file and feed it in your browser. thanks for not overriding it and let us decide for ourself!

  23. Aaron Scully

    You could also write your own BitBucket competitor, but most people won't! Doing something non-standard and getting the rest of your team to do the same is extra work that BitBucket could do once and resolve for everyone. I also think to fix pull requests that more than just a CSS fix is required. Zach's new issue is a good start.

  24. Victor Engel

    Adding the ts=4 query argument doesn't work for me. I get back the same URL without it when I try it. Anyway, much easier to use a bookmark as described earlier.

  25. Victor Engel

    My mistake. That works. I must have fat fingered the URL or something. Still, having to add a query argument to a URL each time is too cumbersome to be considered a reasonable solution.

  26. Bram Bouwens

    I see that adding ts=4 to the URL parameters works. However, it would be nice if this would be passed to the next page when browsing the sources. And yes, it should definitely be doable to add it to some project setting.

  27. Sean Toru

    8-space tabs makes code harder to read, but not hard enough to justify copy/paste/refreshing the query argument for every commit I review (several dozen a day). Come on bitbucket this is an easy win.

  28. Vinay Bharadwaj

    +1 for settings. Some NodeJS projects are indented with 2 Spaces, most others are indented with 4 spaces. So it would be better to put it in the repository settings. Right?

  29. Zach Davis [out until 9/26] staff

    Thanks to those of you continuing to provide constructive feedback. I think the EditorConfig support suggestion makes sense, so I've broken that out into a separate issue (#13141). I would recommend watching and voting for that ticket if interested.

    Likewise, for a configurable tab size setting at the project or other level, there's issue #11111.

    I'm going to leave this issue resolved and would recommend any additional feedback be left on one of the two tickets above, or a new issue be created if it's not covered by one of those two.


  30. Log in to comment