Tabulation character (0x09, \t) is always rendered with a width of 8 spaces, but many projects use 4 spaces for the width of tabs. It is important that when code is rendered in GitLab the tab sizes are consistent with how it is viewed in a local editor so that the code is easy to read.
Not sure if this is Firefox's default or if the highlighter sets this (Chromium does the same). Couldn't find a configuration for Gitlab (gitlab.rb, GUI or even CSS from 'rouge' library) nor for Firefox.
We should provide per-project configuration for tab width.
Proposal
We should use the established EditorConfig file to reuse the settings that are likely already in the repository and supported by major editors.
If a .editorconfig file is present in the repositories root, use the indent_size and tab_width to render the source code.
We need this for our MR reviews so after searching a bit, it seems the tab-size CSS value controls this. A simple workaround was to add that CSS value to GitLab's stylesheet.
Here are the steps I documented locally to change this CSS value on our GitLab server installed through omnibus on Ubuntu 14.04:
Tab Size
By default, browsers will use a tab width of 8 spaces. This means that, since we use tabs instead of spaces in the code, code browsing and diffs viewing will show tabs as the equivalent of 8 spaces while we use a tab width of 4 spaces instead. This makes looking at code confusing.
GitLab does not expose this setting; it's a Firefox/Chrome default of 8 spaces. To change, CSS need to be explicitly set. The simplest would be to use:
*{tab-size:4;}
to set the tab-size CSS value of every elements.
GitLab has pre-compiled CSS files called assets. Sass is used to preprocess .scss files into .css files (see some info here).
So to set the tab size to 4, append at the end of /opt/gitlab/embedded/service/gitlab-rails/app/assets/stylesheets/application.scss the following content:
The problem I am having now is that in GitLab 8.4 any changes I make to css or scss files does not show up on the site. I tried the recompile assets commands as mentioned above. I even cleared my browser cache and nothing. Any idea if I am missing something. I even did a search on the css code and did not even find "tab-size". Also I am using GitLab Enterprise edition which should be same.
Hey! It's been at least 2 weeks (and several releases of GitLab) since we heard from you. I'm closing this issue but if you still experience this problem, please open a new issue (but also reference the old issue(s)). Make sure to also include the necessary debugging information conforming to the issue tracker guidelines found in our contributing guidelines.
@mattl I'm not sure I understand your comment. That issue has been present for many months and is still present. It's not a complicated thing (just a css rule missing/not implemented?). I'm not sure I can provide any more information to this issue (except that it's still present...)
In the end it depends on if GitLab wants to implement this or not, which is another question altogether.
+1 on this, the 8 spaces that my browser uses for tab sizes makes code look blatantly ridiculous.
There is the argument that this is a browser setting, but here is no easy way to change such a setting! Without this being easily available to change in the browser, my 2c is that GitLab should provide a setting to change it.
I use two spaces in my editor and everything looks uniform (nothing exceeds the 80th column), but when I upload it to gitlab none of my code is uniform any more and it looks like crap.
I don't see any reason why we shouldn't make tabs the width of 4 spaces by default. From a quick search, I haven't found any editor with 8-space tabs. Right now it looks weird:
@markglenfletcher I wouldn't make it user configurable but rather repo configurable through .editorconfig. This preserves the project's consistency and respects the author's intent. For now, I would scope this issue to changing the default through CSS and create an issue for .editorconfig support.
@pedroms I disagree. The very reason that my project at work is using tabs is that we each prefer our own unique tab widths. This should be configurable per-user. Perhaps use .editorconfig setting by default, but that is overridden by user in settings (default settings value "same as project").
@pedroms Was there ever an issue raised to implement .editorconfig support? Or is there WIP or merges seheduled in a future release? There does seem to be large support for the idea on this here, and on the mentioned GitHub issue (they have implemented it some time ago now), but I couldn't find anything relevant by searching.
Is there any movement on this? It's been a year and we're still having to edit a css file by hand every time we update gitlab.
Could there really be no way to allow the setting of the tab-width property for how things are displayed? Or for gitlab to support a per project .editorconfig file.
Agree, it's all about the little things. This is a huge QOL feature and implementing it probably won't take more than a few hours (just a CSS rule and a way to apply it, either with a button/combobox/checkbox/whatever in the code view or a user setting)
I was able to address this issue in Chrome by installing the Stylish extension, and creating a site-wide CSS stylesheet for gitlab.com which applies the following:
* { tab-size: 2;}
This is nice because the style is applied automatically for any gitlab page; no bookmark click required.
@pedroms, can you take another look at this issue when you get a chance? Sounds like there is some further feedback on your proposed solution. Would be nice to get this one wrapped up.
For GitLab it could do the same or it could store the value in user preference or in local browser storage. After that the JS needed to make it effective is simply document.body.style.tabSize = '4';
Just moving to gitlab from github.
In github,there is a .editorconfigfile per repo, By adding several lines of code into it as follows,i can custom the tab width:
@DouweM I think this is likely gitlab-ce~24926493 since we'll need to parse the .editorconfig file and apply the correct settings when rendering the blob/diff. Do you have any concerns about making an additional Gitaly call when rendering the blob, which could bring the total number of calls required to render the blob to 3 (blob, .gitattributes, .editorconfig)?
As mentioned by @DouweM in a call today, it should only be one Gitaly call because we can request the three paths for the relevant SHA in a single Gitaly request.
Can we have it as a setting at account level? Because .editorconfig doesn't fix the problem when we are viewing files from projects we don't have control.
@dmz_ I'm afraid you argument is irrelevant. The issue is about having options to viewing files. What I expect is that a viewer should always have the option regardless of having control on a repo.
Please indicate what users need to do to fix this.
Because you can edit files directly - your webIDE Button - its kind of critical vs the other guys (where they use .editorconfig). Please fix this, Please.
@jramsay Any ETA on this issue? I believe the best approach would be to set the default to 4, then overwrite it on project level if there's .editorconfig and maybe allow users to overwrite it in the profile settings.
I totally agree that tab width should be a profile preference in exactly the same way that syntax highlighting theme is.
Tab width is purely a presentation preference just like font size or syntax highlighting theme.
Authors that want to stipulate an indentation size typically use spaces.
It is acceptable and often preferred to leave certain EditorConfig properties unspecified. For example, tab_width need not be specified unless it differs from the value of indent_size. Also, when indent_style is set to tab, it may be desirable to leave indent_size unspecified so readers may view the file using their preferred indentation width.
This feature is available in Github (use ts=<width> in the URL), I'd love to see it in Gitlab as well (using .editorconfig for defaults). Hopefully, this issue will get some attention if people comment or like it, although it has a gitlab-ce~2936416 label.
Guys thanks for making GitLab available free and open source. 8 spaces is a bit of a ridiculous default, it would be awesome if it could be set server wide, I can't imagine a scenario when someone would actually want it to be 8 spaces.
@Jigsik no, it may not.
If a projects is coded with 4 spaces per tab in mind, then it must be viewed as such by all users regardless of browser or gitlab defaults.
That’s why supplying this value with editor config is essential.
@dbogatov Actually, I work with a group where the lead says "code in tabs so each of us can display with his/her preferred indentation." So, for this specific need, having a per-person configuration would be best.
To be clear, I'd like to have this ability, but I doubt any solution we could come up with would meet everyone's needs, or even perhaps the majority of users' needs.
Pushing this back on the browser is wrong. Sure I could set my browser to have smaller tab sizes (via extensions), but that would affect other pages as well.
All we care about right now is how to display tab character on gitlab.
Project should specify what they're using, but individuals/users need to be able to override.
I think best solution is something like following these rules. The largest numbered rule taking higher precedence than lower number rules.
Default 2 (or 8 as it currently is)
Respect tab-width of .editorconfig
Respect tab-width of gitlab specific configuration files in repository (I don't think this exists. Just an idea)
@dbogatov In the absence of editor config having a global config or a browser level config may be (and likely is) enough for most users. I'd say it is preferable to have both, but having any is much better than nothing (and is enough for guys like me).
Also IMO it is a good practice to show invisible chars to recognize spaces/tabs if such is possible.
@dtgriscom For this specific situation the values may be overridable by user.
However, there are some projects where the number of spaces per tab is essential for readability.
In my case it is Latex tables.
I rely on 4 spaces per tab to make huge tables readable, so that they look like tables in the code itself.
My tables are not viewable in gitlab at all.
@megaksa@dtgriscom One of the solutions may be to not specify tab width in editorconfig if the project is tab-width agnostic.
Editorconfig supports rules per language (or possibly folders?) so that we can for example say that .tex files must be 4 (or pick your number) spaces per tab while other files will inherit the value.
Our company has around 200 repositories in gitlab. Adding a editorconfig file into each repository is insane. Setting the tab-width on group-level or user-level would be perfect and sufficient for us. Sure a editorconfig could additional exist, but should be overwritable by group-level or user-level settings.
@anton.bessonov.public why the downvote?
If repo owner has a preference they can put in a editorconfig which will have priority (maybe still overridable somehow). Otherwise user setting will kick in and take effect.
I ask you very carefully: What's the problem to implement tab-size as a Gitlab configuration? Ok, tab-size is a browser issue (*1). 8 spaces for a tap is ridiculous. It's about 2 miles out of the screen. Idk what the developer has thought. But anyway. It's simple to implement this as configuration in Gitlab, isn't? Use CSS and / or JavaScript. Set it to tab-size: 4 or 2 by default. In my cause I use 2. And I recommend it.
(*1) Btw. tab-size of 8 by browser is not really a browser issue. It's a style option like width, color, font-family, etc. The client / website has to set it. - Any problems?
The order of config application (setting in a later config overrides previous ones):
IDE level settings (with defaults)
Project level settings
.editorconfig
To have similar functionality in GitLab, spaces need to be controlled on the server side (e.g. tab-width is computed and set for some element(s), or tabs are replaced with computed number of spaces or with visible elements representing tab character). The configs may be done this way:
GitLab global defaults (set by admin e.g. in GitLab config)
User level preference (applied globally for all projects): "Tab Width" (number or not set), "Show Whitespaces"
If the code/text has a tab character, it should be presented as a tab character (not replaced with spaces on viewing). This is a requirement for proper copy/pasting and to be a faithful reproduction of the original.
Tab CSS can be dispatched on a per project basis or set via JavaScript right?
I don’t think it needs to be server side translated to spaces that would be actually changing the source prior to viewing (if you copied it, it wouldn’t match what was saved).
@megaksa's idea looks as the best.
And GitLab should not translate tabs to spaces, but set CSS property for each presented file according to described logic: (i repeat) 1)editorconfig, if not than 2)user preferences, than 3)GitLab config.
Can everyone agree that we should at minimum have project based tab settings (I'm considering adding it in a month when I have time, my merge request may not be accepted though). The number of years this has taken is silly, and its not really a surprise as scope bloat has taken over.
.editorconfig
I want to get this done in its minimal acceptable implementation. Adding more and more things and options just makes this task bigger and bigger and less likely to make it into an upcoming update. We can add further functionality on top of that later. Hopefully @megaksa's idea can be added later.
Also, when indent_style is set to tab, it may be desirable to leave indent_size unspecified so readers may view the file using their preferred indentation width.
Tabs should not be used for alignment etc where a specific width is required - that's a perfect use for spaces.
I agree with @hrobertson that a user preference for tab width is preferable.
If tabs are used correctly (Indent with tabs, align with spaces) the user preference is the "better" feature, because it allows users to view files with whatever indentation width they like.
However in code files which incorrectly use tabs for alignment purposes, a project based tab width setting is actually necessary to read the files without getting headache.
So what is more important:
Add a feature to view files according to ones own preference or
add a feature to view (IMO broken) files that use tabs for alignment.
I really fail to see how a tab setting can be a personal thing on projects on a site like GitLab, which is aimed at collaboration between devs in projects. For personal repos you are right, but when a project decides to put a .editorconfig file in their repo and put tab related settings in there, why would you ever want to override those?!? The source code is formatted with those settings, so they are important to properly read the code. When you want to contribute you most like need to obey those settings for any contribution to get in. That is what the project decided to go with. They may have used tabs for alignment, simply because they decided on a width for them. If you want to join the project or use their code that is what you have to deal with.
@ffes Frank, I believe the issue here is tab appearance when viewing files on the GitLab website, rather than editing exactly (I appreciate this is a fine difference).
Just as we can set our IDE's to display tab characters at different widths such that each person can set it to what they find most easily parsable, shouldn't we be able to do the same when looking at it on GitLab?
For example, double tab (8-space) indentation seems excessive to me such that I find it hard to read, yet others such as Linux kernel devs are probably quite comfortable with it (IIRC it is part of the style guide for the kernel).
Obviously, just as with the mentioned IDE option, this need not affect the contents of the file when editing.
Either way, .editorconfig or user configuration; both are better than the current, fixed, display.
Tabs are used for indentation, not for alignment. If the tabs are used correctly, it does not matter whether the user likes 1 or 16 spaces - the code will always look right. So, I do not think there would be any valid use-case to specify indent_size in the code and I prefer the ability to override this setting.
But like many others, I really do not care if indent_size or user settings are used. Please, just make it configurable.
@ffes If tab width is specified in .editorconfig, then I think that should take precedence over a user preference.
However, of the repos that use tabs for indentation the vast majority either do not have an .editorconfig file at all, or do not specify indent_size. Therefore the implementation of a user preference would benefit a far greater number of GitLab users and I believe should therefore be first on any list of what to implement first.
My comment was in response to @Sepps who was suggesting the minimum implementation be respecting .editorconfig. My opinion is that the minimum implementation should be a user preference as this will effect the most repos and the most users.
I fully support the addition of respecting .editorconfig later.
Ultimately, a user's preference should always have the option to be the highest precedence. I don't care that every single other dev uses 8-character wide tabs (or whatever). I have my preference and I am going to use it. I can deal with whitespace merging issues if I want to.
However in the interest of getting some support for this sooner, I'd vote for supporting .editorconfig's tab-width first and have a plan to override it later. A close second is adding a URL option.
To reiterate a slightly unrelated point, I 100% agree with "Indent with tabs, align with spaces". I wish more tooling supported this.
@kyb I disagree. Users should be able to easily override a project's presentation if they so desire.
Not sure what you disagree with. I do agree that users should be in control of the project presentation. If they own the project then probably everything is set up right and coding style is in agreement with the team. The most complex case IMO is someone else's project where one doesn't want to do any commits to view the project in the desired way.
The proposal allowed tab width override by the user. The only question is should .editorconfig be ignorable or not. As .editorconfig contains multiple settings for different files, we have few options.
Give up on user preference and allow .editorconfig take over, assuming that someone thought well and set it correctly. (my original proposal).
Add an extra option to ignore .editorconfig globally. This typically would be off but may be useful for some screwed up projects.
Instead of single tab-width user preference, add user .editorconfig, which would override project level .editorconfig (i.e. both will be mixed with preference given to user .editorconfig items).
To elaborate option 2 (order of application, later overrides former):
global tab-width
user tab-width, option to ignore project .editorconfig, option to show whitespaces
project level .editorconfig
Option 3:
global tab-width
project level .editorconfig
user preference .editorconfig, options to show whitespaces
Option 2 looks the best to me and satisfies all the needs mentioned so far. Option 3 is more flexible but is probably overkill.
Implementation wise (for option 2) I'd do in that order:
global tab-width (assume this is easy and some kind of global default is needed anyway)
user level tab-width
option to ignore .editorconfig + project level .editor-config (should come both to not lose user control)
@megaksa, I disagreed with "1)editorconfig, if not than 2)user preferences, than 3)GitLab config." which allows a project's settings to override a user's viewing preference.
To clarify, I've been using the term "user" as a synonym for "viewer", regardless of if they have write access to the repository or not.
To put it another way, even if a repository has been setup fully "properly" with tab-widths and such, a user (viewer of the files) should still be able to override what they see. If we want to relegate this functionality to 3rd party browser extensions, that's an understandable solution but I don't see why it doesn't make sense to have this feature as part of gitlab CE.
You bring up a good point with regard to "showing whitespace". I agree this should be controllable, possibly in the same way as tab-width. However a problem here is that .editorconfig does not support such a setting and thus another file/place would be required to enable this feature. While I think these are related problems, I think adding an option to "show" whitespace is a different "issue" and should be implemented generally separately.
An easier "punt" might be to support a new file like .gitlab/display.conf which controls a repository's default display options (including, but not limited to, tab-width and display-whitespace) and to completely ignore .editorconfig for display/viewing purposes. However why would this make sense over a setting it in the repository's options? Different branches could them have different default display styles... Is that desirable?
@cinderblock First sync: I used the term "user" as "Viewer" as well. I also found 3rd party browser extensions a bad solution: 1) extra requirements from users so only a subset of users would benefit 2) Users won't get all the possible benefits, e.g. online editing which take the params into account 3) harder to implement 4) fewer possibilities to do it right as extension does not have access to internal data.
Let's use the term "Viewer" for our actor. "User" would mean actor doing both viewing and editing.
As far as I see it, .editorconfig defines the editor behavior when transforming the text (source code). I.e. how the text representation (bytes) change when Editor (user editing the text) does typical transformations: adding/deleting/editing the lines, indenting etc. At the same time, .editorconfig is a good source for tab-width value, if Viewer wants to see the project as the author saw it.
I'm somewhat confused on your proposal of submitting .gitlab/display.conf. Everything submitted into a project should be done in collaboration. So there is no reason for tab-width in display.conf to be different from tab-width in .editorconfig. If author edited text with specific tab-width in mind there is no reason for them to intend Viewer to see in with different tab-width. I can easily forsee .editorconfig can grow into "Coding Style Config". As for "View Whitespaces" I've never seen the case where this had to be set per project. It's representation only as does not affect text transformation on edit. Typically user either wants it everywhere or they want it nowhere. While I prefer and recommend it always on, I'm totally fine to have it off by default.
Particularly GitLab is handling 2 use cases: viewing particular revision (similarly comparing two revisions), and editing revision online.
Viewing. This is the major case I and arguably most of the users care about.
Here Viewer cannot submit anything, and their only option is changing own preferences. When I referred to user preferences or user .editorconfig, I meant Viewer clicking Settings then Preferences (or currently non-existing View/Edit), then configuring Tab Width checkbox, Ignore .editorconfig checkbox, and Show whitespaces checkbox. Alternatively, this section can contain Show whitespaces checkbox, and Personal .editorconfig multiline edit box (format in the bottom). This would allow fine-grained custom user settings (e.g. tab-width and tab/spaces per language) and would affect both viewing and editing online. This is analogous to global per language IDE settings which exist on your local machine only and does not affect other project collaborators.
Typically user global own preference. I.e. "Would I use tabs or spaces and how many if I was going to start my own new project in specific language". Here preference may be per language.
If an existing project uses only tabs for indentation, User has a choice of tab-width and will probably use global own preference specified above.
User may be forced to work on an existing project with mixed tabs/spaces without .editorconfig. For viewing purposes, it may make sense to apply settings to the specific project only (e.g. pick tab-width for particular project or projects matching regex).
Same for an existing project with mixed tabs/spaces with .editorconfig. For viewing the above solution would work. I.e. order of application:
Global tab-width
User global .editorconfig
Project .editorconfig
User .editorconfig rules with regex mask matching the current project.
Editing seems to work as well with the above approach. The only caveat I see is a project with .editorconfig having the personal masked config for it. Then User would probably (optionally) edit project .editorconfig and then exclude the project from the personal .editorconfig mask.
While above would be flexible, it's harder to implement, and may be confusing for some users. User .editorconfig format is an open topic. 'yml' format may be better suited for that:
indent_size:4rules:-glob:'*'end_of_line:lfinsert_final_newline:true-glob:'*.{js,py}'charset:utf-8-glob:'*.py'indent_style:spaceindent_size:4-glob:Makefileindent_style = tab-glob:'lib/**.js'indent_style:spaceindent_size:2-glob:{package.json,.travis.yml}indent_style:spaceindent_size:2repos:# could be named projects-name_regex:apache/incubator-.*indent_size:2-name_glob:apache/hadooprules:-glob:'*.java'indent_size:3
I am very anti the idea of a .gitlab/display.conf file.
@dustwolf As you can see, there is disagreement about what the best behaviour would be. Anyone is free to submit a PR - this issue has the Accepting merge requests label - but it's a sign of a healthy community that ideas are discussed rather than people just implementing their own preference. That way we hopefully arrive at a solution that benefits the most users.
Hi. Discussions seem to overthink the issue. Simply set a global tab space/char (either hard coded or as an option), but always always respect project’s .editorconfig.
Other suggestions such as showing whitespace characters and user-defined .editorconfig rules with regexes matching project names should be separate issues.
In this issue I think we should limit ourselves to just two sources of display width: .editorconfig and user preference.
@dustwolf Assuming the issue is open for 3 years, elaborating the issue doesn't hurt.
@gsemet It doesn't hurt to have a long term vision and implement just part of it. I've seen a whole spectrum of tab/spaces combinations while working on different projects: tabs, 2 spaces, 3 spaces, 4 spaces, mixed (where coding style changed from tabs to spaces, but migration was incomplete), mixed (due to vendor code with non-matching style present in project). JetBrains products generally handled all these cases well enough.
Yes, .gitlab/display.conf was a crazy idea that I did not expect anyone to like, however it solves a bunch of issues with using .editorconfig (no support for whitespace control, has complicated rule structure that hasn't been fully replicated).
I think @hrobertson's mockup is the right direction.
I was thinking it would be helpful to also be able to change this setting on a per-viewer per-repository basis. However, looking at the existing UI/implementation, it doesn't look like there is a good place to store/display/control such settings and the use case is a little rare. Supporting overrides in URL query string is a sufficient implementation of this specific sub-use case.
Some wording changes I would consider:
"Tab width" -> "Default Tab Width"
"Override tab_width in .editorconfig if present" -> "Ignore .editorconfig"
@AlexWayfer let's not get into recommendations on how to style the code.
I agree with @fbruetting .
Some of us who use TABs would rather have an editor display the code properly, than change our style guides.
@AlexWayfer This works for me EVERYWHERE. No matter if I use Gnome Builder or Eclipse or Atom or gedit or Word or whatever there is, that can be used for text editing. SOLELY GitLab is not able to display tabs with the correct width, so don’t tell me I’m doing it wrong.
By the way: None of all the programs I ever worked with (except terminals and less) default to 8 tabs, it’s about just Linus who enforces 8 spaces wide tabs. So why does this have to be the default at all? Try it out with the above mentioned programs.
So I propose to just change the default to a width of 4 instead of 8.
4 spaces is best, simply because no one really needs 2 or 8 spaces for a real reason. When somebody really needs 8 spaces for differentiating, I’d propose buying glasses instead. Also the 2 spaces HTML developers just use 2 spaces because if they’d use more, none of their content would be inside the normal view. As they – for a reason I will never understand – rather use thousands of divs instead of doing proper CSS grid. So if they would code sane, I’m sure they’ll be glad being able to use 4 spaces.
@AlexWayfer let's not get into recommendations on how to style the code.
Let's not say what to do. I just brought another (popular) point of view.
Example: one of advantages of Tab is flexible width. If one of your developers want another width (for accessibility) — you deprive him of this opportunity.
I don't want to argue.
4 spaces is best, simply because no one really needs 2 or 8 spaces for a real reason.
Please, don't claim for everyone. If you don't know a reason — it doesn't mean that there is no a reason.
Also the 2 spaces HTML developers just use 2 spaces because if they’d use more, none of their content would be inside the normal view. As they – for a reason I will never understand – rather use thousands of divs instead of doing proper CSS grid.
I use width 2 for Ruby code, this is like standard for this language. So…
Hey @jramsay, I feel like the discussions in this issue have slowly devolved into tabs vs spaces or a tab-size of 4 vs tab-size of 2 debates. Can we get more direction from your team?
From what I have read, there is a general consensus on three points:
The default tab-size of 8, specified by browsers, is excessive
Users should be able to change the default tab-size on the user level
Users should be able to change the tab-size on the project level
On the grounds that most people agree to a default tab-size of 8 is excessive, would you be willing to consider accepting an MR that sets the default tab-size to 4 by implementing * { tab-size: 4; }? I can say with great confidence that there is someone out there who would argue that the tab-size should be 2, but I think a tab-size of 4 is less intrusive on the basis that a difference of 4 is less than a difference of 6.
Edit: I think this would be a quick fix to ease the minds of some before the larger feature is created.
On the grounds that most people agree to a default tab-size of 8 is excessive, would you be willing to consider accepting an MR that sets the default tab-size to 4 by implementing * { tab-size: 4; }? I can say with great confidence that there is someone out there who would argue that the tab-size should be 2, but I think a tab-size of 4 is less intrusive on the basis that a difference of 4 is less than a difference of 6.
Did someone try to change the default for browsers instead of each service (like GitLab)? I think, if there are actually "most people agree", then change browser default is simpler (from the perspective of thousands of services). And, finally, this issue not about defaults.
Did someone try to change the default for browsers instead of each service (like GitLab)?
Changing the default tab size across all browsers, one born out of the CSS 2.1 spec, is a significantly harder task to accomplish.
I think, if there are actually "most people agree", then change browser default is simpler (from the perspective of thousands of services).
You are right. I probably should not have assumed that "most people agree". The statement was influenced by the discussions, by languages historic use of 4 or 2 spaces/tab-size, and by my personal experience.
And, finally, this issue not about defaults.
My idea was to push for small, incremental changes to get this issue resolved insteading of debating for another three years. First, change the default tab-size to a more reasonable one. Then modify the value of that change on the user and project level implementations.
@milipili Thank you! I accidentally discovered layout settings because of screenshot earlier in this thread, it helped a lot, though it affects all of gitlab interface, not only code view. But it's a small price to pay.
Speaking of coding style -- it's a subject to debate what is "simpler" and in what terms. e.g. it may be heavy-nested but code flow is easier to follow and more resistant to changes. Anyways, I'm not in a position to choose coding style.
BTW to anyone using Stylebot etc to tweak the site's CSS, this works in both code view and diffs and is more specific than the "*" rule suggested above:
According to this stackoverflow comment this feature is present in GitHub from 2015.
I've just checked my calendar and it says it's 2019.....
Is there any chance this feature will be implemented in GitLab anytime soon?
Thanks.
Haha @AntonBabushkin you just made my day. I can confirm it is 2019 and would love to have this ability. 8 space tabs in the WebIDE is annoying when comparing diffs.
The GitLab CE repo is being merged into the EE repo. Gitlab-bot left an explanation on the CE issue but only after the move, so it didn't show in this thread. GitLab's broader explanation is here
@philbz that's the third paying customer I count in the lifetime (4 years) of this particular thread (there were preceding similar threads) on this subject to request this... So it's probably a good idea to tell this latest customer that this is unlikely to happen.
Since when do we implement features requested only by paying customers?
Sure, those features are prioritized, but do you imply that this whole discussion thread and almost two hundred upvotes mean nothing as long as only few enterprise customers explicitly request this feature?
I mean the exact opposite. That even with paying customers asking for it, it seems unlikely that it will be implemented. Given the threads history that you referred to yourself.
I see the current consensus is to implement tab width along with the set of rule in editorconfig.
It is reasonable, but with this pace we will never get there.
Maybe, it is worth implementing tab width alone for now and then integrate it in the editorconfig when it's ready?
Editor config is the most important part of this, user being able to change
it in the view is a nice to have since editorconfig can just specify the
correct settings by default
I would argue that editorconfig is less important because I suspect that most repos with tabs won't have an editorconfig file. And even if they do many won't specify a tab width. (after all the whole point of tabs is that they are flexible).
If you let the user specify it manually it will work for all tab files.
Update: tab width user preference was added in !22063 (merged), so if this feature makes it into GitLab 12.8, you'll be able to set your (per-user) preferred tab width. It will be applied globally across GitLab, basically everywhere but WebIDE and file editor, since these guys don't use real tabs and replace them with spaces instead.
Per-project tab width preference can be implemented next. Feel free to hack on it, I believe MRs are welcome.
I'm not sure. It's already in master and the corresponding release blog post is ready, so I think it should make it unless something unexpected and hard to fix is found during testing on Staging.
@jramsay, I believe only part of this issue is resolved. Some people here (including the author) proposed per-project configuration of tab widths with .editorconfig file, and this wasn't implemented yet. I think for now we should not close this issue. Or we should at least create another issue to address this specific .editorconfig thing and provide a link to that issue here.
I would prefer to track the EditorConfig integration in another thread; this thread has been too long. Please do link to that thread from here, however.
In addition, great thanks for implementing this feature for all of us, Alexander! Community members like you makes GitLab the best Git hosting software.
Isn't the act of creating/maintaining an .editorconfig file in itself a "per-project action as a user"? It may be an action you've already performed, and if Gitlab made a change to honor that file, it would require no further action on your part. But for projects that do not currently use EditorConfig, it would indeed still require a user action.
I think what @jake.stine meant (and I agree) is that the act of creating the .editorconfig can be done by a maintainer of the repository. Then there is no further action needed for regular users of the repository.
(.editorconfig might also be considered a somewhat agreed standard while a GitLab-specific action would be, well, GitLab-specific, so it's more likely repositories already have an .editorconfig, but I think that's only a secondary reason.)
I do see what you mean, but I think the same could be said about a project-level setting as well. Each user already has their user-level global setting for tab width, but then each project maintainer could, in theory, set the tab width inside the project-level settings that would then apply to any viewer of that repository.
But I can definitely see it both ways. Even though tab width is strictly a rendering concept, since the character is the character, Gitlab already does have certain rendering settings taken from project files, rather than project settings. For example, syntax highlighting rules defined in .gitattributes. However, being a Git platform, it makes sense to tie a setting to a Git-specific file. Whereas, EditorConfig is not strictly Git-specific. And EditorConfig seems to rely on plugins to enforce the rules on other platforms, which doesn't really mesh with how Gitlab operates.
I definitely see the value in both solutions, but I don't necessarily agree that a lack of EditorConfig support would be a failure to address the issue.