Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/gofmt: odd comment alignment #9064

Closed
cznic opened this issue Nov 5, 2014 · 5 comments
Closed

cmd/gofmt: odd comment alignment #9064

cznic opened this issue Nov 5, 2014 · 5 comments
Assignees
Milestone

Comments

@cznic
Copy link
Contributor

@cznic cznic commented Nov 5, 2014

What does 'go version' print?
go version 1.3.2 // According to fmt.Println(runtime.Version()) in playground.

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1.
Open http://play.golang.org/p/E22kYjkJpS

2.
Click button "Format"

What happened?
Comment at line 4 jumps to the right.

What should have happened instead?
Comment at line 4 should have probably stay where it was.

Please provide any additional information below.
My hypothesis is that gofmt wrongly computes the length of line 5 using also len() of
the string literal as if it was a quoted string; in an attempt to align the comments at
L4 and L7 as if they are adjacent. But the raw string literal has newlines embedded so
they are not.
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 6, 2014

Comment 1:

Labels changed: added repo-main, release-none.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 6, 2014

Comment 2:

Owner changed to @griesemer.

Status changed to Accepted.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Apr 4, 2018

@cznic I believe your hypothesis is correct. The following example https://play.golang.org/p/-4qfL0qblf7 exhibits the same problem and the alignment of the 3rd foo is based on the string length of the raw string on the next line (the "abc_0123456789_" has the same length). This is really done in the tabwriter package, but gofmt could perhaps do something about it.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Apr 5, 2018

The fix is probably to recognize newlines in escaped text sequences in the tabwriter and then flush the buffer contents up to the newline but keep the escape mode on: No matter the previous content, when the escaped text sequence containing a newline is written out, the resulting line break is going to break the existing formatting/column alignment.

This should probably only be done if enabled by a new flag in order to not break existing code that might rely on the current behavior.

go/printer then would simply have to set that flag.

Probably not too hard to do but requires thorough understanding of tabwriter internals (which is somewhat subtle).

Marking for 1.11 in case I find the muse to do it. Not urgent.

@griesemer griesemer modified the milestones: Unplanned, Go1.11 Apr 5, 2018
@gopherbot
Copy link

@gopherbot gopherbot commented Apr 6, 2018

Change https://golang.org/cl/105040 mentions this issue: go/printer, gofmt: handle raw string literals containing newlines better

@gopherbot gopherbot closed this in 70f5afa Apr 11, 2018
@golang golang locked and limited conversation to collaborators Apr 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.