cmd/gofmt: remove -tabs and -tabwidth flags

[bradfitz]

Go indent style is tabs.

The gofmt command-line tool misleadingly advertises the ability to customize the ident
behavior with -tabs and -tabwidth, but then that is no longer gofmt'd code. The proper
Go style way to do this is to configure your editor's display of tabs instead.

I think we should remove those two flags from cmd/gofmt.  (not from the go/* packages)

The Go 1 compatibility promise excludes the tools.

Users who really care can write their own formatter binary using go/format or
go/printer, but it won't be gofmt.

[minux]

Comment 1:

I support this change.

[minux]

Comment 1:

I support this change.

[griesemer]

Comment 2:

Labels changed: added repo-main.

Owner changed to @griesemer.

[griesemer]

Comment 2:

Labels changed: added repo-main.

Owner changed to @griesemer.

[minux]

Comment 3:

another benefit of adjust editor tabstop setting is that other gofmt'ed code
automagically looks right, instead of just your code looks right to you.
if we make this change, we probably should add an FAQ entry about this.

[minux]

Comment 3:

another benefit of adjust editor tabstop setting is that other gofmt'ed code
automagically looks right, instead of just your code looks right to you.
if we make this change, we probably should add an FAQ entry about this.

[gopherbot]

Comment 4 by dskloet:

I'm only starring because I want to receive updates. Please don't count my star as
support.

[gopherbot]

Comment 4 by dskloet:

I'm only starring because I want to receive updates. Please don't count my star as
support.

[cespare]

Comment 5:

I have a patch at https://golang.org/cl/50600043. I'll mail if we reach
consensus.
Please count my star as support.

[cespare]

Comment 5:

I have a patch at https://golang.org/cl/50600043. I'll mail if we reach
consensus.
Please count my star as support.

[davecheney]

Comment 6:

Provided that the tabs functionality on go/fmt is tested, so we don't break it on people
who write their own code formatters -- that would be rubbing salt into the wound, then
SGTM.

[davecheney]

Comment 6:

Provided that the tabs functionality on go/fmt is tested, so we don't break it on people
who write their own code formatters -- that would be rubbing salt into the wound, then
SGTM.

[4ad]

Comment 7:

I support this. -tabs is pointless. Gofmt correctly uses tabs for indentation and spaces
for alignment, so Go code looks correct with any tab width setting.

[4ad]

Comment 7:

I support this. -tabs is pointless. Gofmt correctly uses tabs for indentation and spaces
for alignment, so Go code looks correct with any tab width setting.

[dmitshur]

Comment 8:

I support this change.
It has benefits of making .go files more uniform, and the flexibility of displaying
different tab widths is shifted over to the text editor (where it already exists, and
belongs).

[dmitshur]

Comment 8:

I support this change.
It has benefits of making .go files more uniform, and the flexibility of displaying
different tab widths is shifted over to the text editor (where it already exists, and
belongs).

[gopherbot]

Comment 9 by dskloet:

How would it make .go files more uniform?
It would just drive some people away from using gofmt.

[gopherbot]

Comment 9 by dskloet:

How would it make .go files more uniform?
It would just drive some people away from using gofmt.

[minux]

Comment 10:

always using tab is more uniform that some using tabs, and some using spaces (and worse
yet,
there are different settings of -tabwidth).
IMO, not using gofmt simply means driving away potential users of the package.
(I, for example, won't use a package if it hasn't been gofmt'ed.)

[minux]

Comment 10:

always using tab is more uniform that some using tabs, and some using spaces (and worse
yet,
there are different settings of -tabwidth).
IMO, not using gofmt simply means driving away potential users of the package.
(I, for example, won't use a package if it hasn't been gofmt'ed.)

[kisielk]

Comment 11:

I'm +1 for the change. The purpose of gofmt is to put code in to the canonical Go style,
which is indented with tabs. There's no reason to provide options to put it in to
another style, it just serves to confuse new users.
If someone wants to format Go code in to their own style, they can easily create their
own tool by forking the gofmt code.

[kisielk]

Comment 11:

I'm +1 for the change. The purpose of gofmt is to put code in to the canonical Go style,
which is indented with tabs. There's no reason to provide options to put it in to
another style, it just serves to confuse new users.
If someone wants to format Go code in to their own style, they can easily create their
own tool by forking the gofmt code.

[gopherbot]

Comment 12 by dskloet:

That may be true. But how does removing functionality from gofmt change that? You think
people who prefer space will suddenly change their mind because gofmt gives them the
finger?

[gopherbot]

Comment 12 by dskloet:

That may be true. But how does removing functionality from gofmt change that? You think
people who prefer space will suddenly change their mind because gofmt gives them the
finger?

[dominikh]

Comment 13:

Having the options suggests, to new users, that using them is fine and that they're
still following Go style even though they're not.
Not having them is more likely to get new people to adopt the correct style. The select
few who are stubborn enough to ignore the style are free to go through the hassle of
using their own fork of gofmt.

[dominikh]

Comment 13:

Having the options suggests, to new users, that using them is fine and that they're
still following Go style even though they're not.
Not having them is more likely to get new people to adopt the correct style. The select
few who are stubborn enough to ignore the style are free to go through the hassle of
using their own fork of gofmt.

[gopherbot]

Comment 14 by divoxx:

Yes, because gofmt is adopted and perceived by the community as a requirement. Most
people won't contribute to projects that are not gofmt'ed properly. Go programmers
*love* the fact that gofmt is the defacto standard and they follow it. Usually, people
that are doing something different are new to the language and too attached to their
other language's standards.

[gopherbot]

Comment 14 by divoxx:

Yes, because gofmt is adopted and perceived by the community as a requirement. Most
people won't contribute to projects that are not gofmt'ed properly. Go programmers
*love* the fact that gofmt is the defacto standard and they follow it. Usually, people
that are doing something different are new to the language and too attached to their
other language's standards.

[minux]

Comment 15:

they probably won't change their mind just because this change.
but I sincerely hope they change their mind at least for Go (and I know people
who did)
as I said in the mailing discussion, Go is a language optimized for read rather
than write, and having consistent formatting is just one aspect of it.

[minux]

Comment 15:

they probably won't change their mind just because this change.
but I sincerely hope they change their mind at least for Go (and I know people
who did)
as I said in the mailing discussion, Go is a language optimized for read rather
than write, and having consistent formatting is just one aspect of it.

[cespare]

Comment 17:

@Dave (comment #6)
If you're referring to the go/format package, that currently only provides functionality
for the canonical style (with tabs).
You'd have to reimplement gofmt using other go/* packages and turn TabIndent off in
go/printer. Looking at the tests for that package, it appears that it actually does not
use TabIndent for the test cases.

[cespare]

Comment 17:

@Dave (comment #6)
If you're referring to the go/format package, that currently only provides functionality
for the canonical style (with tabs).
You'd have to reimplement gofmt using other go/* packages and turn TabIndent off in
go/printer. Looking at the tests for that package, it appears that it actually does not
use TabIndent for the test cases.

[dsymonds]

Comment 18:

I don't think discussion on this bug is going to get anywhere productive. It's the same
viewpoints over and over again. Let's leave it with Robert.

Labels changed: added restrict-addissuecomment-commit, controversial.

[dsymonds]

Comment 18:

I don't think discussion on this bug is going to get anywhere productive. It's the same
viewpoints over and over again. Let's leave it with Robert.

Labels changed: added restrict-addissuecomment-commit, controversial.

[bradfitz]

Comment 19:

This issue was closed by revision 014f3dc.

Status changed to Fixed.

[bradfitz]

Comment 19:

This issue was closed by revision 014f3dc.

Status changed to Fixed.