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: struct fields not aligned when interrupted by a multi-line expression #31431
Comments
I don't see any difference between those two snippets. What am I missing? For |
The difference is in the second line
This looks like an intended change happened not long ago. |
See previously #22852 (CC @griesemer). |
Currently I have the source code (subject to change when I commit Argon2 cipher) here: Reconfirmed on Playground: https://play.golang.org/p/5cOTMOiihGx Let me know what can I contribute back. I'm currently working on a cryptography manager for my toolbox. p/s: Sorry for the late reply, I was hiking 2 mountains this morning. |
This is working as expected. The line length differences between 2nd and 3rd line are large enough for alignment to be (on purpose) broken. As an aside, what you were expecting to see seems also inconsistent since the 3rd line would have to be aligned as well; so your expectation is inconsistent anyway. Closing. |
The 3rd line is expected since we are breaking a long line unto multiple line and I'm currently using tab, not space. After all, the slightly indent and the OR bar indicates a multi-line. 3rd line doesn't need any amendment. The 1st line ( I'm okay if this is accepted expectation given the weight of the issue is very small (annoyance over malfunction). |
@hollowaykeanho Thanks for the longer example. Again, the algorithm looks at the current line (actually a statistical average of line lengths of lines formatted so far) and the next line length and then decides whether to maintain alignment or not. At a certain threshold, alignment is not maintained. The thinking behind this is that a single overlong map key in a long map shouldn't force every other line to be aligned the same, and then causing all keys to be moved far to the right (and possible out of sight, depending on how your editor is configured). It's a heuristic that sometimes fails. Your specific example could probably be fixed trivially, by simply turning the threshold knob (a hardwired constant) a bit. But then it will just fail elsewhere. Note that this happens every time your next entry is much longer than the one that's not aligned (inID = 0, 6, 9). Maybe the threshold should be dynamically determined, but that would require some look-ahead or analysis of the table which will slow things down. This is working fine most of the time; I'm not sure it's worth the complexity to make it work in all cases. You can look at that specific decision making code here. |
After briefly went through the source codes, I agreed with you: it's an
expensive cosmetic amendment.
I suggest when this issues got itself a bunch of +1 then only worth looking
at it. For now, let's keep the issue closed.
…On Sat, Apr 20, 2019, 01:47 Robert Griesemer ***@***.***> wrote:
@hollowaykeanho <https://github.com/hollowaykeanho> Thanks for the longer
example. Again, the algorithm looks at the current line (actually a
statistical average of line lengths of lines formatted so far) and the next
line length and then decides whether to maintain alignment or not. At a
certain threshold, alignment is not maintained. The thinking behind this is
that a single overlong map key in a long map shouldn't force every other
line to be aligned the same, and then causing all keys to be moved far to
the right (and possible out of sight, depending on how your editor is
configured).
It's a heuristic that sometimes fails. Your specific example could
probably be fixed trivially, by simply turning the threshold knob (a
hardwired constant) a bit. But then it will just fail elsewhere. Note that
this happens every time your next entry is much longer than the one that's
not aligned (inID = 0, 6, 9).
Maybe the threshold should be dynamically determined, but that would
require some look-ahead or analysis of the table which will slow things
down.
This is working fine most of the time; I'm not sure it's worth the
complexity to make it work in all cases.
You can look at that specific decision making code here
<https://golang.org/src/go/printer/nodes.go?#L224>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#31431 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABXMLNDRG2VESHNPMH7NZ23PRIATTANCNFSM4HFMT52A>
.
|
I'm getting a werid go fmt -w -s output. The line before a multi-line is not aligned properly in a struct list. In my case, my
inID
is way off the column alignments, consistently with the same patterns.What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yet to explore 1.12.3 just release
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
When applying
$ gofmt -w -s .
to the source code, the line before a multi-line was formatted into a weird, not aligning to the correct column. It is very consistent for all the lines right before their respective next multi-lines code.It happens when I was working on a large struct list for table-driven testing. No issue with execution.
What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: