Bad indentation in list comprehension

[brand17]

Issue created from fantomas-online

Code

[ for x in [] do yield 1 ]

Result

[ for x in [] do
      yield 1 ]

Problem description

Getting two excessive spaces added before yield - there are six instead of four.

Extra information

• The formatted result breaks my code.
• The formatted result gives compiler warnings.
• I or my company would be willing to help fix this.
• I would like a release if this problem is solved.

Options

Fantomas main branch at 1/8/2025

Default Fantomas configuration

[nojaf]

There are four spaces in regards to the for keyword.
I'm pretty sure this is a can of worms if we want to respect this from the opening [.
For your small example there is no problem, but for larger expressions I can imagine it can lead to indentation problems.

Are you interested to send a PR to investigate this?

[brand17]

@nojaf Sorry, I am not a professional developer. What does your last question mean?

Do you want me to investigate the scale of this problem? Not sure I can help with it because I just don't understand what should I do. But I actually had a large expression with two nested list comprehensions where such indents were a real trouble.

Or you want me to propose the changes to Fantomas source code? If so I think I can participate - I did similar things a couple of times in other open source projects.

[nojaf]

I cannot definitively say whether it is safe to preserve indentation relative to the [ for each expression. My assumption is that we currently do so to ensure formatted code remains valid.

A developer should investigate by changing the code and running the test suite to observe the effects; each test verifies whether the formatted code is still valid.

If this proves not to be a problem, we should raise the matter with the style-guide maintainers to determine whether the behavior can be formalized.

Do you want to do some digging?

[brand17]

ok, will do

[nojaf]

Thank you! Comprehensive documentation is available at https://fsprojects.github.io/fantomas/docs/contributors/Getting%20Started.html. Please do not hesitate to ask if you have any questions.

[nojaf]

/repo-assist investigate why the result is what it is.
My gut tells me we cannot easily fix this without revisiting a wider scope.

[github-actions]

🤖 This is an automated response from Repo Assist.

Root Cause Investigation

I've investigated why this produces 6 spaces instead of 4 before yield. The maintainer's instinct is correct — a clean fix would require revisiting a wider scope.

What's happening (with fsharp_multiline_bracket_style = cramped)

The writer events tell the story clearly:

Write "["
Write " "         ← content starts at column 2
SetAtColumn 2
SetIndent 2        ← Indent level set to 2 (the "[ " offset)
  SetAtColumn 2   ← atCurrentColumn in ExprForEachNode
  Write "for x in [] do"
  IndentBy 4      ← Indent = 2 + 4 = 6  (not 0 + 4 = 4)
  WriteLine       ← doNewline: writes 6 spaces
  Write "yield"   ← at column 6

The key interaction:

1. genMultiLineArrayOrListCramped calls atCurrentColumnIndent at column 2, which sets both Indent = 2 and AtColumn = 2.
2. Inside ExprForEachNode, atCurrentColumn is called — it sets AtColumn = 2 (unchanged), but importantly does not reset Indent.
3. When indent runs (IndentBy 4): since AtColumn(2) < Indent(2) + 4, the rule is Indent = Indent + IndentSize = 2 + 4 = 6.
4. On the next newline, 6 spaces are prepended.

Why it's hard to fix cleanly

The atCurrentColumnIndent in genMultiLineArrayOrListCramped serves a real purpose: it ensures multiple list elements align at column 2. Remove or change it, and multi-element cramped lists may break alignment.

The ExprForEachNode formatter (atCurrentColumn + indent) doesn't know it's inside a cramped list — it just sees the current Indent level, which happens to be 2 due to the "[ " prefix.

A targeted fix (e.g., resetting Indent to 0 inside ExprForEachNode for this case) would need to be applied consistently to all comprehension body expressions — for...do, while...do, if...then — inside cramped lists. Without that consistency, you'd get partial fixes and new edge cases.

The "wider scope" the maintainer alluded to is likely: cramped mode's indentation model is fundamentally at odds with absolute indent levels. Since content starts at column 2 (not a multiple of IndentSize), all subsequent body indentation is offset by 2. The aligned default avoids this entirely by starting content at column 4.

Current status

Since the default was changed to aligned in December 2025, this issue only affects users who explicitly set fsharp_multiline_bracket_style = cramped. The aligned output is:

[
    for x in [] do
        yield 1
]

which has consistent 4-space indentation at each level.

Generated by Repo Assist for issue #3181

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@828ac109efb43990f59475cbfce90ede5546586c. View source at https://github.com/githubnext/agentics/tree/828ac109efb43990f59475cbfce90ede5546586c/workflows/repo-assist.md.