Cannot change tabulation size
albanx opened this issue · 49 comments
Hi There
Is there a way to set the tab size to 4 spaces instead of 2 of the new generated files?
Cheers
Alban
In the .editorconfig set indent_size = 4
Already done, but this does not affect the Angular CLI
The CLI doesn't provide this kind of functionality for scaffolded code, but you're more than welcome to format your code however you please.
But this way one has to format the code every time he generates a new file. I will contribute and add this function.
I agree that it is frustrating to have to reformat every file the cli spits out just so you can have the tab spacing you are chasing. Could the cli not reference .editorconfig when creating new files @filipesilva?
For Sublime users this setting in your Syntax Specific settings may help change the tabs to 2 spaces for ts files but not your other files.
https://forum.sublimetext.com/t/set-tab-size-for-different-file-type/6807/4
I don't think there's a way to do that at the moment, but haven't investigated it much.
@DesHorsley I can confirm that the CLI is not referencing the editorconfig for any code format
Why is this ticket closed? It seems like a logical feature to have and I don't see any other issues mentioning this functionality.
+1 for "why is this closed?" Two-space indentation is just.. ick.
+1 I find this frustrating as well. I use WebStorm, and while I've got Webstorm setup to use 4 spaces for tabs, it also tries really hard to honor an existing file's pattern for tabs. This lack of capability in angular-cli makes me have to fight my editor whenever I use angular-cli, which I think goes against the whole point of the cli to begin with.
Just want to throw in my +1 on having this option, reading from .editorconfig.
Additionally, it would be great to be able to use tab characters instead of spaces.
+1 for bumping this issue.
+1, having to change every file manually is tedious
+1, seems like a fairly reasonable PR candidate
+1, great tool but this problem is very frustrating
+1, this would be really useful
+1 for me as well!
+1 for this. Very frustrating to edit the generated file every time for 4 spaces.
Why the ticket is closed btw?
+1 for me as well, I'm not happy to reindent each newly created file.
+1. Would be very happy if CLI could read from either .editorconfig or the angular-cli.json.
Please consider reopening this issue. I have configured VSCode to not detect current file settings so that I can go in and auto-format each generated file, but it would sure be nice to skip this step.
+1 seems good and option in angular-cli.json 👍
+1 Please implement this.
+1. Not familiar with anyone use 2 spaces for indenting...
+1 Our team also uses 4 spaces and it's slightly annoying needing to go in and update them.
Could there not at least be a CLI option to set the number of spaces to tab when generating files?
If this feature is not going to be implemented near soon, at least consider to change the default indent to 4 spaces. It's the default indentacion in WebStorm and most editors.
+1, we use 4 spaces wide tabs for indentation... 2 spaces feel strange...
+1
This feature would be great. Or atleast change it to 4 spaces as that is the most common indentation setting from what I can tell.
+1 I would like to have that feature
+1 for Tabs. 2 spaces just makes the code ugly.
+1 for indentation. Can't stand 2 spaces!!!!!
Is this not something the team cares to add, @filipesilva? Seems to be a good bit of interest, yet the issue remains closed.
Tabs vs spaces (and number of spaces) is one of those heavy, contentious issues in the JS community.
It's not a matter of functionality, but rather of style. On matters of style we usually defer to the style guide. The style guide has no recommendations on tabs vs spaces but almost all of the examples internally are in 2 spaces, so we default to 2 spaces.
There are other style issues where we take action, but those are usually motivated by consistency (to minimize confusion and to make it easier to reference docs) rather than any kind of preference.
There is a fair amount of interest, yes. But there is also a very trivial workaround - format your code however you like. The amount of effort to offer this customization isn't well understood, but spending time looking into it is effort as well.
So as far as functionality is concerned, resolving this issue has zero impact. It's just not important enough to take up resources that would be best spent elsewhere.
Sure it would be easier for users to just throw a flag into generators, but I find it hard to justify to myself the development time. Should I fix broken functionality, or should I cater to the eternal tab/spaces struggle? That's an easy decision for me to make. It's also an easy decision if I'm talking about important features instead of bugs. It's very, very low on the totem pole.
We're looking at a new blueprint system and it should be much easier to make these style decisions there. The best I can say is that I'll keep that in mind at the time. But it's just not worth it to try and retrofit the existing system to support this kind of customization.
So that is why this issue remains closed.
Cool. Thanks for the feedback and reasoning, anyway. Guess it's safe to Unsubscribe to this one.
PS - 4 Space Tabs 4 Life!
@albanx No, tab characters that are 4 spaces wide. I knew I'd mess up saying it. o_O
Right, which is why the feature in this issue was requested in the first place. So that individual devs and teams don't have to conform to what the community prefers as a whole. I'm not saying my preference is "right", but it certainly isn't wrong.
I think most of community is against that, because the tab characters has
proven to be problematic in different platforms
What are the problems? I've never encountered an issue with tabs that wasn't a result of a developer misusing them. Not arguing; I'm genuinely curious what the issues are on other platforms.
really? then you're too young...
Quite a rude assumption. I've been programming for about 15 years, thanks.
open it on github or bitbucket it will break all formating (at
least a tab will be spaced probably 10 spaces)
Right, by default, GitHub displays tabs larger than most (as 8 spaces, not 10). That's configurable to something sane like 4 or 2, just like any text editor is able to do. Does 8-space indentation make things harder to read? Yes, for me and I'm assuming for most people. But it doesn't "break all formatting" unless the author misused tabs. As long as the "tabs for indentation, spaces for alignment" mantra is followed, I've never seen a case where this was an issue.
Space has consistency, 1 space is 1 space everywhere, tabs are not.
Yes, and that's the issue with using spaces for indentation, not the advantage. You may prefer 2-space indentation, while I prefer 4-space indentation. With tabs for indentation, every developer gets to work on code in whichever style is most readable to them. If your code looks terrible when the indentation length varies, you're mixing up your indentation with your alignment, and that's your fault as a developer.
Issues is you have to configure every editor to have the same tab length
spaces not.
No, you don't. There is no reason to do so. If you've read what I said or have enough experience to have experienced it firsthand, you'll know that it's unnecessary for developers to have matching indentation lengths, so long as they don't mix up indentation with alignment. That's the advantage of tabs.
Any case I am not going to argue on this since it is not the topic of this
conversation. If you're looking for flamewars go on stackoverlow you will
find a lot of topics this.
Who's looking for a flamewar? You opened the conversation with a dismissive insult after I asked for an example to back up your claim.
really? then you're too young...
Please do not cry now... pardon me if you felt insulted... .
Teenager confirmed. Let's continue this conversation when you're an adult with some real-world development experience. Until then, by all means, continue cargo cult developing with no understanding of the points you're arguing for and against. 😄
@albanx and @Josh1billion please refer to our Code of Conduct and adhere to it during ALL interactions related to the Angular project. This thread has clearly reached the end of its useful life, and @filipesilva's answer isn't going to change in the forseeable future. Locking.
This should be available soon-ish via automatically running TS Lint fixers on generators. This is being tracked in #6272.