Support tabs for indentation about prettier

[nschubach]

The great thing about tabs is that it doesn't matter if I use 4 and you use 2!

…

On Fri, Jan 13, 2017, 00:56 RangerMauve ***@***.***> wrote: I switch between 4 and 2. :D — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLmhsbPzKAB8kBj8QBN75spX-RimXYeks5rRxH8gaJpZM4Lfsc0> .

[RangerMauve]

I call BS on JavaScript using 2 spaces for indentation. I've read many code bases and there's a large variety of indentation styles out there. And not only with what they use to indent, but where they indent, and where they add extra whitespace between keywords. The language itself is so dynamic and used in such different ways that expecting there to be a "standard" style is a little near-sighted. I'll concede that most people use spaces (at least from the ones that vote on surveys) But between those there are splits between the number of spaces that they use. So even if it's a majority, that doesn't necessarily mean that the majority use two spaces.

[Vanuan]

I think what's best about this project is that it's opinionated but still roughly adhere to conventions in the JavaScript community.

The thing is JavaScript uses 2 spaces. Other languages, like Go, use tabs.
TypeScript uses 4 spaces.
General purpose languages, like Java and C++, use all sorts of indentation.

Maybe it's because JavaScript is gradually becoming a general purpose language, we see this departure from convention.

[jlongster]

Actually, tabs make this whole project pretty hard. The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there. We need to know how many spaces a tab takes up so we can accurately measure code.

Need to think about this a little more.

[defvoid]

Just remove --tab-width completely?

Why?

• Minimize options.
• print-width should be enough.
• Output is pipable through an end-spaces-vs-tabs-discussion-utlity.
• Editors/viewers should "fix" indentation using .editorconfig & co.
• Deep nesting 🤢

README states... opinionated 😊

[Alhadis]

+1 for tabs. "Opinionated" or not, forcing users into using spaces is a really, really stupid decision.

The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there.

From what I gather, this project's point is to programmatically enforce a project's coding style in a foolproof fashion. Or are you judging readability purely on line-length?

Actually, tabs make this whole project pretty hard.

How? Here's how I do it, and it's piss-easy:

1. Tabs to indent, spaces to align
2. Keep the two separate using non-whitespace characters, making an obvious exception for JSDoc
3. Avoid using tabs as an alignment device - if the indentation depth jumps by an unexpected amount, it indicates misuse. I've published a junk project to illustrate an example.

2 spaces for indentation is the default because that's what the majority of the community uses.

This is why I hate people. I wish more people would do as @suchipi does and not assume every reader's preferred indentation width matches their own.

Anyway, I'm not posting here to start a fight - I don't want anything to do with the JavaScript community, and that includes bikeshedding. But if implementation is difficult, maybe the way I handle tabs can point you in the right direction.

[rhengles]

Support for tabs in Prettier has been merged in #1026 🎉

[suchipi]

Am I the only person who renders tabs as two spaces? 🐑

[bakkot]

The Linux kernel (and many Linux projects, like GNOME) define tabs to be 8 characters wide; this is also the default for e.g. vim. So there's not universal consensus on 4.

[rhengles]

Actually, tabs make this whole project pretty hard. The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there. We need to know how many spaces a tab takes up so we can accurately measure code.

About this, I think it would be easier to add another option (indentWithTabs or something) and keep the tabWidth option, this way you would calculate the line size normally just like spaces but output tabs.

[RangerMauve]

Finally, a formatter that doesn't support tabs, is useless for all projects or teams that use tabs. I could see how having more configuration options for stuff like "put a space after function" would be redundant, but something as fundamental as all the indentation in a project seems worthy of having a flag. Especially given how heated the debate is on this particular topic.

[jdavisclark]

I might not support editorconfig unless you intend to support every potentially applicable editorconfig option. Partial support for the core default options confuses users.

@jlongster That said, supporting tabs is important. Spaces vs tabs is one of those timeless holy-wars; choosing a single side will just alienate a large portion of your potential userbase.

[jlongster]

As well, there's no guarantee that they can format back if the project isn't using this particular formatter

If the project isn't using this formatter, then you can you never use this formatter on that project. Once you make changes, how are you going to format it back? You can't format code on a project that doesn't use this because you'll have a lot of various styling changes. It doesn't make sense to use this formatter at all if a project isn't using it.

Since you don't want to add a new configuration option, why doesn't you make "tabs" the default indentation method?

Spaces are by far the standard in the JavaScript world. I very rarely come across a project that uses them. 2 spaces for indentation is the default because that's what the majority of the community uses.

Just like standard we are going to choose some options for you, sorry (keeping what we think is the most used options in mind). In the future we will see if it's worth making it configurable, but as said above, it's a lot easier to add options later than to remove them. Right now we are focusing on making sure we always output valid JS code.

That may mean you can't use this project right now. There are other formatters and hopefully you can find one that works for you!

I'm closing this for now because we aren't going to work on it. That doesn't mean we'll never do it, but let's give this project a little time to settle and then I'm going to revisit the tabs and semicolon debate.

[pie6k]

While all this discussion is interesting - why don't just let people decide how they want their project to be formatted? To use or not to use is simply endless topic.

[wmertens]

100% of my editors have tabs set to 4 ;)

…

[wmertens]

If you use post-processing for tab conversion (or semicolon removal), you actually have to parse the JS again since template strings and JSX can be multiline and should not be touched. So that means a fairly significant slowdown.

I agree with #34 (comment) - it's ok for tabs to be considered e.g. 4 spaces and then when I use a different setting, it doesn't matter that the right margin fluctuates a little. Just keeping the --tab-width setting for that seems fine.

@wiredearp Using editorconfig actually increases complexity, no? I mean, inferring config from it seems ok, but using it as the sole source makes its use complex…

[pie6k]

@rhengles I'm not a fan of forks here:

[wmertens]

@nschubach yes, that is one of the many advantages extolled in the article, but for prettier it matters because that changes whether to convert something to multiline or not. So by keeping the tabWidth setting and having a useTabs boolean, that can be configured.

[RangerMauve]

@jlongster Formatting an entire file to have a different tab width is a practice that's just begging for somebody to forget to revert the formatting back and commit their changes. As well, there's no guarantee that they can format back if the project isn't using this particular formatter (which they likely won't given the sheer number of them out there).

[jlongster]

I'm open to this, particularly because we have the --tab-width option and we can probably repurpose that. My goal is to have no more than ~5 options or so, but this one could be good. We could make --tab-width take an option like --tab-width tabs or something so that it just prints tabs.

[TehShrike]

I usually view code at 4 space indentation, but on smaller screens I've rolled with 3 or 2 spaces per indentation.

Then again, I'm also not very dogmatic on max line width. If I'm on a giant monitor I'll let the occasional line stretch long, and I'll leave it that way until I go read/edit it on a smaller screen.

:-x

[RangerMauve]

I second the idea of just assuming the most common setting of 4 characters-part-tab and having the actual size fluctuate if somebody has a custom setting. I doubt it would make too much of a difference either way.

Alternately, maybe tabWidth can be set to a negative number which represents hard tabs that are going to be rendered with -N spaces.

[danielbuechele]

I like @wmertens suggestion, because it only adds one additional config value, is compatible with the current config. So would a PR with this addition be accepted, or is more discussion needed before someone starts tackling this?

[jlongster]

@danielbuechele Not yet. I want to focus on making it completely stable with all JS constructs first before evaluating any more config options. "Only one additional config value" is always famous last words. It's way easier to add something later than it is to remove.

I'm seeing the value of tabs less when you can simply reformat a file with your preferred --tab-width and format it back. We want to make tooling that makes this super easy, so you can view any file from any project in your preferred settings and then simply format it back. In my opinion this removes the major advantage pitched for tabs.

[rhengles]

Ping @ALL! Please take a look on #908 and #920!

[TehShrike]

Output is pipable through an end-spaces-vs-tabs-discussion-utlity

I like this idea, but it only holds if authors don't mix spaces-for-indentation with spaces-for-alignment. If prettier trims spaces-for-alignment, then this would be fine.

Editors/viewers should "fix" indentation using .editorconfig & co.

This is only accurate if the file is indented with tabs. If the file is indented with spaces, editors don't generally offer any way to customize indentation display. Some do offer "convert to tabs", but that would get undone by prettier the next time it was run.

[rhengles]

@jlongster Since you don't want to add a new configuration option, why doesn't you make "tabs" the default indentation method? They are the logical and specific characters to indent text, spaces are meant to separate words. This way, users who prefer spaces would:

simply reformat a file with your preferred --tab-width and format it back.

Maybe, you could do without even the --tab-width option and use a fixed size of 4, for example, to calculate the total length of a line. Since it would not be a big difference anyway.

You already have an option to specify the width of the tab, which some people care about, but you don't have an option to use tabs, which a far greater amount of people care about.

[vladinator1000]

I think hard tabs = tab characters. I had a problem with my eslint config.

Changed this:

"rules": {
        "indent": [0, "tab", { "SwitchCase": 1 }],
        //...
}

To this:

"rules": {
        "indent": [2, "tab", { "SwitchCase": 1 }],
        //...
}

That fixed my problem.

[JonathanWolfe]

I'd be willing to bet that ~90% of all editors are set to show tabs are 4 characters wide. A quick couple of searches didn't turn up any formal analysis though.

[wiredearp]

If it must convert tabs to spaces, it suggest it should also do that within (JSDoc style) comments which now look like this:

  /**
	 * INDENTED WITH TABS (probably because comments are simply passed through)
	 * @param {String} key
	 * @param {function} base
	 * @returns {function}
	 */
  function getter(key, base) {
    return function() {
      console.log(key);
      return base.apply(this);
    };
  }

💁‍♂️ To minimize the amount of configuration related to supporting tabs, perhaps the relevant properties could be reduced to one setting editorconfig that points to an external file called .editorconfig as detailed on http://editorconfig.org/. This has bonus advantages:

1. Most code editors can be rigged with a plugin that automatically configures editors settings to conform (eg. to use spaces instead of tabs and set the tab-width to 2 and so on) so that anyone on the team will automatically adopt the settings.
2. The .editorconfig file can be placed in the root of a GitHub project to control the tab-width that users will see when they browse the repository. The browsers default width is 8 and this probably explains why many developers prefer spaces to tabs, but with this trick you can reduce it down to 4 or whatever you prefer.

In other words, your code editor and your GitHub repo and your Prettier command line tool would all consume the same settings with regards to tabs (or spaces), tab-widths and potentially also newlines.

[nschubach]

Actually, tabs make this whole project pretty hard. The whole point is that we can let the user specify a maximum line length, like 80, and wrap code there. We need to know how many spaces a tab takes up so we can accurately measure code.

About this, I think it would be easier to add another option (indentWithTabs or something) and keep the tabWidth option, this way you would calculate the line size normally just like spaces but output tabs.

Yup, This is how Sublime Text handles that:

// The number of spaces a tab is considered equal to
"tab_size": 4,

// If translate_tabs_to_spaces is true, use_tab_stops will make tab and
// backspace insert/delete up to the next tabstop
"use_tab_stops": true,

[RangerMauve]

I switch between 4 and 2. :D

[rhengles]

Thank you, and I understand your reasons. Just for reference for anyone interested, I already made a fork with this option, in the simplest way possible, without any new tests yet:

https://github.com/arijs/prettier-with-tabs

It works, but 5 of the 377 tests suites and 6 of the 1071 snapshots have broken, because of lines that were expanded and now are collapsed in a single line, and I don't know why, since adding this option shouldn't modify the default behaviour.

UPDATE: Solved it now, all tests pass. 😄

[jlongster]

@rhengles Cool, thanks. Please keep in mind that I think we should just think about it later, so I'm postponing the decision, not denying it. We could potentially even detect if the current file uses tabs. We're trying to stay really focused right now on the bigger bugs where we don't output correct JS though.

[bakkot]

@timpler that discussion has been had at length at #40.

[rhengles]

@timpler My fork aims to do just that - enable anyone to add whatever configuration option they'd like.

[rhengles]

@timpler You're entitled to your opinion, but as far as I'm aware, we're still at 2 and not at 15.

That is why I didn't simply switch the indentation from spaces to tabs - I made everything configurable.

[pie6k]

@rhengles are you going to maintain such fork to be up to date with prettier releases?

[rhengles]

@timpler I have been doing just that since I created it. And it is really really easy.

[vladinator1000]

Is it possible to use hard tabs?

[wmertens]

@savovs what do you mean? Prettier supports spaces and tab characters, what are hard tabs for you?