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

go/printer: Strange indentation behavior/ broken output under some circumstances #5946

Closed
gopherbot opened this issue Jul 24, 2013 · 9 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@gopherbot
Copy link

by tobias.schwerdtfeger:

What steps will reproduce the problem?
http://play.golang.org/p/MmaG6179Zk

Inside an ast.Block with a leading comment and at least 2 following "Nodes" (I
don't know how to call it correctly, e.g. X int  or  CallFunc()  etc.), the, beginning
from the second Node is indented wrong. This issue only happens, when
Mode:printer.SourcePos and a Tabwitdh greater than 0 is set in printer.Config{}.

Increasing the Tabwidth will result in smaller indention and vice verse.

Fix:

Delete both:
p.output = append(p.output, tabwriter.Escape)
surrounding:
p.output = append(p.output, fmt.Sprintf("//line %s:%d\n", pos.Filename,
pos.Line)...)
at file printer.go in method:
func (p *printer) atLineBegin(pos token.Position)

This will fix the issue with the indention, but has probably unwanted side effects.

---

In case of struct { ... } as seen in the example above, the indention between the 'X'
and 'int' or 'Y' and 'int' is false too. (This is unrelated to the issue described
above). Changing the Tabwidth to 0 will result in broken output => 'Xint' instead of
'X int'.
Example:
http://play.golang.org/p/pKlx5IZT89

Which version are you using?  (run 'go version')
go version devel +84cafba689b1 Wed Jul 24 17:48:13 2013 +0900 linux/amd64
@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 1:

Labels changed: added priority-later, go1.2maybe, removed priority-triage.

Owner changed to @griesemer.

Status changed to Thinking.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 2:

Labels changed: added feature.

@robpike
Copy link
Contributor

robpike commented Aug 29, 2013

Comment 4:

Not for 1.2.

Labels changed: removed go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 5:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 6:

Labels changed: removed feature.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@lukechampine
Copy link
Contributor

I am also observing this behavior. Here's the smallest case that I was able to reproduce: https://play.golang.org/p/2eixeOb1i8

Using printer.RawFormat seems to fix the problem, which makes sense if the tabwriter is responsible.

Since this is low-priority, is there any downside to using printer.RawFormat?

@griesemer griesemer added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed Thinking labels Jan 10, 2017
@griesemer griesemer modified the milestones: Go1.9Maybe, Unplanned Jan 10, 2017
@griesemer
Copy link
Contributor

I cannot reproduce this anymore at tip (note that the playground will be updated once Go 1.9 is out). This may have been fixed indirectly as part of the fix for #5945.

(Also, please note that if you want to see the comments in your examples, you need to set the parser.ParseComments mode when invoking the parser. But this is orthogonal to this specific issue).

Feel free to re-open if you still see a problem.

@golang golang locked and limited conversation to collaborators Jun 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants