Where can I find the gofmt rules specifications?

[Florin Patan]

Hi,

I'm currently working on implementing a 1:1 copy of gofmt for the Go plugin for IntelliJ platform.

I've searched a bit on the Internet, and maybe I did a poor job at it, but I couldn't find any place where I can actually see the specifications for how gofmt formats the code.

Also, if I understand correctly from the formatter test, the test is performed on the file itself and then it has some other special tests and that's it. Am I missing something?

Could anyone please point me to the right direction where I could find some specs / rules for gofmt?

Thank you.

Kind regards,

Florin

[Ian Lance Taylor]

[ +gri ]

As far as I know nobody has ever written down any rules for gofmt.
Although there are multiple implementations of the Go compiler, there
has (until now) been only a single implementation of gofmt. So this
is a case where the implementation is the spec.

There are tests for gofmt in the directory cmd/gofmt/testdata.

Ian

[wkharold]

Use the source Luke, use the source. A cursory glance at gofmt.go leads me to believe that most of the action takes place in the printer.go Config structure's fprintf method.

[rni...@gmail.com]

On Monday, February 23, 2015 at 5:52:07 PM UTC+1, Florin Patan wrote:

I'm currently working on implementing a 1:1 copy of gofmt for the Go plugin for IntelliJ platform.

Maybe I'm missing something here, but why reimplement it when you can just call gofmt? AFAIK other editor plugins are doing it this way too. Or isn't this practical in IDEA? 

[andrewc...@gmail.com]

it seems a bit crazy to me too.

[Florin Patan]

Ian, would it be possible to have the implementation translated to actual

specifications somewhere? How could I  contribute with a documentation

to provide this?

I guess it could be useful for people new with the language as well as for

third parties.

Thank you.

Florin

[Florin Patan]

We currently rely on gofmt / goimports as well to format the source code but....

For example, the IntelliJ platform provides the infrastructure to create a

language formatter that formats the code as you type rather than on save.

Another example where this is useful is that IDEA can format the code

even if  the sources are broken, gofmt doesn't.

People used to any of the IDEs or language plugins for the platform would

definitely benefit from having this functionality available to them so I don't

see any problem with reimplementing this. Especially that we want to create

the best experience possible to edit go sources (for example, please check

this blog post about how you can customize the highlighting to suite your

needs).

However, regardless if people want to reimplement gofmt or not, it would 

still be beneficial to have a standard reference for it as it could point people

to a place to look at when they wonder why their source is  formatted in a

way or another.

[Ian Lance Taylor]

On Wed, Feb 25, 2015 at 12:42 AM, Florin Patan <flori...@gmail.com> wrote:
> On Monday, February 23, 2015 at 6:42:04 PM UTC+1, Ian Lance Taylor wrote:
>>
>> As far as I know nobody has ever written down any rules for gofmt.
>> Although there are multiple implementations of the Go compiler, there
>> has (until now) been only a single implementation of gofmt. So this
>> is a case where the implementation is the spec.
>>
>> There are tests for gofmt in the directory cmd/gofmt/testdata.
>

> Ian, would it be possible to have the implementation translated to actual
> specifications somewhere? How could I contribute with a documentation
> to provide this?

This is Robert's question to answer, but I don't see that ending well.

The basic approach is straightforward, and is, for example,
implemented in emacs go-mode
(https://github.com/dominikh/go-mode.el). There are probably other
editor plugins that partially implement the formatting; see
https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins . The idea
is simply to format as you type, imprecisely, and format precisely
using gofmt on file save. Usually the differences will only be with
things like indentation of struct fields. Note in particular that
full gofmt support as you type means that earlier lines will be
reindented as you type later lines, which I think many people will
find confusing.

Ian

[kortschak]

Out of curiosity, why does gofmt not keep the last comment in the []byte aligned with the others in this snippet: http://play.golang.org/p/sx1B9grRsd (click format).

[Egon]

On Friday, 20 March 2015 00:35:51 UTC+2, kortschak wrote:

Out of curiosity, why does gofmt not keep the last comment in the []byte aligned with the others in this snippet: http://play.golang.org/p/sx1B9grRsd (click format).

It doesn't seem to align those comments at all

http://play.golang.org/p/bWRYId8CNG 

[Dan Kortschak]

On Thu, 2015-03-19 at 15:55 -0700, Egon wrote:
> It doesn't seem to align those comments at all
> http://play.golang.org/p/bWRYId8CNG

That would be to logical conclusion. Make that the question now:

"Why are comments in this context not aligned?"

[fatdo...@gmail.com]

I'd like to see more tools reimplemented under the gpl umbrella, and definitely not tied to the google golang CLA. I'd even help with tools reimplemented under the Simplified BSD that is not tied to a shady CLA.

I've started a project with a small group to implement a golang frontend for the gcc under the GPL 2.

[fatdo...@gmail.com]

It is about control. releasing a spec for gofmt under any other license but the same used for the golang spec( creative commons) would raise eyebrows, however releasing a spec for gofmt under the creative commons would set golang on a path to a truely open project.

gofmt is an artifact of a poorly designed lexer.

Luckily, the spec is all that is needed to reimplement the tools and fix these glaring flaws.

Just saying...

[Ian Lance Taylor]

On Thu, Mar 19, 2015 at 5:54 PM, <fatdo...@gmail.com> wrote:
>
> I'd like to see more tools reimplemented under the gpl umbrella, and
> definitely not tied to the google golang CLA. I'd even help with tools
> reimplemented under the Simplified BSD that is not tied to a shady CLA.

For the record, the Google CLA is not long, not hard to understand,
and gives up very few rights. It's not shady. Anyone who chooses can
read it for themselves at
https://cla.developers.google.com/about/google-individual .

Ian

[fatdo...@gmail.com]

The language used in definitions 1 and 2 is very dangerous.

[fatdo...@gmail.com]

*The language used in definitions 1,2,3 is dangerous.

On Friday, March 20, 2015 at 1:06:40 AM UTC-4, Ian Lance Taylor wrote:

[Ibrahim M. Ghazal]

On Fri, Mar 20, 2015 at 3:54 AM, <fatdo...@gmail.com> wrote:
> I'd like to see more tools reimplemented under the gpl umbrella, and
> definitely not tied to the google golang CLA. I'd even help with tools
> reimplemented under the Simplified BSD that is not tied to a shady CLA.
>
> I've started a project with a small group to implement a golang frontend for
> the gcc under the GPL 2.
>

Nothing stops you from forking and modifying the code in any way you
want without signing the CLA. The code is under a BSD license. The CLA
is only needed if you want your code to be merged back into the Go
project.

And reimplementing anything that is already BSD as a GPL project is
pointless. The BSD license allows you to release your modifications as
GPL if that's what you want (not that I recommend doing that). Even
the Gccgo documentation says the following (from
http://golang.org/doc/install/gccgo ): "The gccgo compiler is a new
frontend for GCC, the widely used GNU compiler. Although the frontend
itself is under a BSD-style license, gccgo is normally used as part of
GCC and is then covered by the GNU General Public License".

[nate....@canonical.com]

FWIW, I, too, wish that there was a spec for what gofmt does.  If for no other reason than to better understand what it does and why.  However, it seems as though there's no reason someone couldn't simply read the code and/or watch its behavior to create such a document.  gofmt won't change its formatting rules in the future, because then all go code in existence would get reformatted.  So.... yeah, if you want to write it up, I'm sure it would be really valuable, and very much welcomed by the community.