code review 4119056: go/printer, gofmt: smarter handling of multi-line raw s...

go/printer, gofmt: smarter handling of multi-line raw strings

If a multi-line raw string is the first token on a line, it
should not be indented because the following lines (belonging
to the raw string) are not indented either.

Adjusted src of ebnf/ebnf_test.go manually as it now is formatted
as expected.

gofmt -w src misc

Fixes issue 1072.

[gri, 2011-02-05 00:41:17]

Hello r (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[r, 2011-02-05 00:47:57]

LGTM

http://codereview.appspot.com/4119056/diff/8001/src/pkg/go/printer/printer.go
File src/pkg/go/printer/printer.go (right):

http://codereview.appspot.com/4119056/diff/8001/src/pkg/go/printer/printer.go...
src/pkg/go/printer/printer.go:853: // the opening quote (`) is on a line
preceeded only by
s/preceeded/preceded/ (it's often confused with the spelling of proceeded)

[gri, 2011-02-05 01:34:18]

*** Submitted as http://code.google.com/p/go/source/detail?r=d9b414fc9626 ***

go/printer, gofmt: smarter handling of multi-line raw strings

If a multi-line raw string is the first token on a line, it
should not be indented because the following lines (belonging
to the raw string) are not indented either.

Adjusted src of ebnf/ebnf_test.go manually as it now is formatted
as expected.

gofmt -w src misc

Fixes issue 1072.

R=r
CC=golang-dev
http://codereview.appspot.com/4119056

[rsc, 2011-02-22 18:12:22]

Because this change is content-dependent (multiline or not),
it makes it impossible to write consistently formatted composite
literals containing `` strings.  I'm not sure we should have
content-dependent formatting rules.

$ cat x.go
package main

var x = []string{
	`BIG
	STRING
	1`,
	`BIG STRING 2`,
	`BIG
	STRING
	3`,
}
$ gofmt x.go
package main

var x = []string{
`BIG
	STRING
	1`,
	`BIG STRING 2`,
`BIG
	STRING
	3`,
}
$ cat y.go
package main

var x = []string{
`BIG
	STRING
	1`,
`BIG STRING 2`,
`BIG
	STRING
	3`,
}
$ gofmt y.go
package main

var x = []string{
`BIG
	STRING
	1`,
	`BIG STRING 2`,
`BIG
	STRING
	3`,
}
$

[gri, 2011-02-22 19:18:30]

I was aware of these issues. Either way, I am not feeling strongly about
this.

It seems to me that most of the time when using multi-line `` strings, they
are used to write down "larger" pieces of pre-formatted text and the first
line is usually misaligned with the rest. It is true that in cases where the
`` contain white space that is irrelevant, one might be tempted to align
lines of `` strings such that they match the current indentation. In this
case:

cat test.go

package main


var x = []string{

`BIG

STRING

1`,

`BIG

STRING

2`,

}


gofmt test.go

package main


var x = []string{

`BIG

STRING

1`,

`BIG

STRING

2`,

}

arguably the result looks better. But if there were a single-line `` string
in the middle, it would not look good anymore.

This was an attempt to improve the formatting, but it's not clear that it's
obviously better. Happy to revert if people think it's better the "old" way.
Rob?

- Robert





On Tue, Feb 22, 2011 at 10:12 AM, Russ Cox <rsc@golang.org> wrote:

> Because this change is content-dependent (multiline or not),
> it makes it impossible to write consistently formatted composite
> literals containing `` strings.  I'm not sure we should have
> content-dependent formatting rules.
>
> $ cat x.go
> package main
>
> var x = []string{
>        `BIG
>        STRING
>        1`,
>        `BIG STRING 2`,
>        `BIG
>        STRING
>        3`,
> }
> $ gofmt x.go
> package main
>
> var x = []string{
> `BIG
>        STRING
>        1`,
>        `BIG STRING 2`,
> `BIG
>        STRING
>        3`,
> }
> $ cat y.go
> package main
>
> var x = []string{
> `BIG
>        STRING
>        1`,
> `BIG STRING 2`,
> `BIG
>        STRING
>        3`,
> }
> $ gofmt y.go
> package main
>
> var x = []string{
> `BIG
>        STRING
>        1`,
>        `BIG STRING 2`,
> `BIG
>        STRING
>        3`,
> }
> $
>

[rsc, 2011-02-22 19:21:00]

I ran across this in a real program over the weekend.
The `` strings were SQL commands.  You don't care
about white space there but they had been consistently
formatted & indented but now cannot be.

Russ