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: extra indentations when adding comments #32480

Open
a8m opened this issue Jun 7, 2019 · 6 comments
Open

cmd/gofmt: extra indentations when adding comments #32480

a8m opened this issue Jun 7, 2019 · 6 comments
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@a8m
Copy link
Contributor

a8m commented Jun 7, 2019

I encounter an issue with gofmt, where adding a comment to the first line causes extra indentation to the rest of the lines.

For example, giving this block of code:

func main() {
	t1 := foo.Bar().
		Baz().
		Qux()
}

Adding a comment (//) after Bar() adds extra indentations to the lines below:

func main() {
	t1 := foo.Bar(). //
				Baz().
				Qux()
}

Playground

Same for this case:

func main() {
	t1 := foo.Bar(). // bar
				Baz(). // baz
				Qux()  // qux
}

Playground

Maybe I miss something, but I expect the formatting to be as follow:

func main() {
	t1 := foo.Bar(). // 
		Baz().
		Qux()
}

func main() {
	t1 := foo.Bar(). // bar
		Baz().   // baz
		Qux()    // qux
}
@agnivade
Copy link
Contributor

agnivade commented Jun 9, 2019

Yes, adding a line comment after breaking the first line adds an extra tab. But I am curious whether you discovered this in some real-world situation or in a different case ?

Note that gofmt sometimes breaks if the code is written in a weird way. Leaving for @griesemer to take a call.

For reference, this happens with 1.12.4 and also tip at go version devel +98100c56da Mon Jun 3 01:37:58 2019 +0000 linux/amd64.

@agnivade agnivade added this to the Unplanned milestone Jun 9, 2019
@agnivade agnivade added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jun 9, 2019
@a8m
Copy link
Contributor Author

a8m commented Jun 9, 2019

But I am curious whether you discovered this in some real-world situation or in a different case ?

Yes, this example just have dummy methods for simplicity. But in my real-world example, I have longer names for these methods that get parameters, and adding line breaks make the code more clear to me.
Sometimes, it's also useful for documentation. For example, see the elasticsearch example in its docs.

Note that gofmt sometimes breaks if the code is written in a weird way.

I'm not sure what are you referring a weird code. The comments or the line breaks?

My current "hack" to solve this is to change the code block below:

func main() {
	result, err := client.Search(). // create a search client.
					Index("twitter").                  // search in index "twitter"
					Query(elastic.NewMatchAllQuery()). // return all results, but ...
					SearchType("count").               // ... do not return hits, just the count
					Aggregation("timeline", timeline). // add our aggregation to the query
					Pretty(true).                      // pretty print request and response JSON
					Do(context.Background())           // execute
}

To this (adding line break between client. and Search():

func main() {
	result, err := client.
		Search().                          // create a search client.
		Index("twitter").                  // search in index "twitter"
		Query(elastic.NewMatchAllQuery()). // return all results, but ...
		SearchType("count").               // ... do not return hits, just the count
		Aggregation("timeline", timeline). // add our aggregation to the query
		Pretty(true).                      // pretty print request and response JSON
		Do(context.Background())           // execute

}

Playground

I would be happy to fix/change this, but let's wait for @griesemer input before.

@agnivade
Copy link
Contributor

agnivade commented Jun 9, 2019

Indeed, ES API is written this way. I was referring to the line breaks.

@griesemer
Copy link
Contributor

Looks like something we should try to fix.

@griesemer griesemer self-assigned this Jun 10, 2019
@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Jun 10, 2019
@gopherbot gopherbot removed the NeedsFix The path to resolution is known, but the work has not been done. label Jun 10, 2019
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 10, 2019
@a8m
Copy link
Contributor Author

a8m commented Jun 10, 2019

@griesemer, would you mind if I take it?

@griesemer
Copy link
Contributor

@a8m You're welcome to give it a shot. But to be fair, I should let you know that I won't have time to help with this or answer detailed questions through the end of July at least. Also any review will have to wait at least that long.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants