Community
Participate
Working Groups
Created attachment 278214 [details] annotated screenshot "indent on column" for binary expressions should align on the left expression, instead of the column of the outer context. See the example in the attached image. The green line shows where I would expect the operands to be aligned on. The red line shows the actual alignment, which is that of the outer context (the argument list).
I have doubts about this request. It effectively means the expressions would never get indented on wrap, so we loose the visual representation of the code structure, for example: callMethod( aaaaaaa + bbbbbbb * ccccccc * ddddddd + eeeeeee, fffffff); Maybe we should instead add a new indentation setting: "do not indent". At least it would be obvious what the effects are. I agree that in your example it doesn't make much sense that with "indent on column" the operands are aligned to whatever comes before the first operand. Here's an even weirder example: callMethod( aaaaaaaaaaaaa + bbbbb, ccccccccccccccccccc + ddddddd); But I'd be more inclined to align after the first operand, for example: callMethod( aaaaaaaaaa + bbbb * ccccccc * ddddddd + eeeeeee, fffffff); Though with your example it would result in a very deep indentation (which is always a potential problem with "indent on column"...). Any more thoughts on this?
(In reply to Mateusz Matela from comment #1) > [..] we loose the visual representation of the code structure [..] I don't think we lose any more than we do with call chains like o.foo() .bar() .baz(); If a visual like you describe is desired, there is still "default indent" and "indent by one" that will do that. If you indent "on column", isn't a column like your first example exactly what you'd expect? Aligning after the first operand like you suggest would defeat the purpose of breaking the line, since the line doesn't actually get shorter.
(In reply to Balz Guenat from comment #2) > I don't think we lose any more than we do with call chains like [...] Call chains are a simpler matter, there's nothing to loose. What I mean is the difference between the first and the last sample in comment 1. It's basically the same code, but with the latter it's much easier to tell at a glance what's related to what. > If a visual like you describe is desired, there is still "default indent" > and "indent by one" that will do that. If you indent "on column", isn't a > column like your first example exactly what you'd expect? Expectations may differ, the last example fits just as well IMO. With your approach I just can't see how the feature can be worth it with this kind of decrease in readability for any more complex expressions. I see it's worth it for you, but you may be an exception ;) > Aligning after the first operand like you suggest would defeat the purpose > of breaking the line, since the line doesn't actually get shorter. It still serves the purpose when there are more than two operands. Which is probably the most important as with only two operands it's more likely they will fit in one line anyway.
I see your point. You may close this bug at your discretion.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
