[matt-edmondson]

Fixes #179

What changed

WriteLine(string) and Write(string) pass their text straight to IndentedTextWriter, which indents only the first line. As the issue suggests, they stay as they are, and a new public method, CodeBlocker.WriteLines(string fragment), does the following:

• splits the text at \r\n, \n and \r, and writes each line at the current indent, ending it with NewLineString. An LF writer never ends up with mixed line endings.
• writes blank lines through NewLine(), so they carry no indentation.
• leaves a line break inside a verbatim literal (@"...", $@"...") exactly as written. It uses the same VerbatimStringScanner as SplitLines, so the literal's value never changes.
• leaves the last line open when the text has no trailing break, the same as Write, so isMidLine matches how the text ends. When it is called mid-line, the first segment finishes the line already under way.
• does nothing for null or "".

It does not reuse SpliceFragment directly, because SplitLines splits only at NewLineString. With an LF writer, CRLF input would keep its \r.

README's API table and CLAUDE.md now list the method.

Tests

WriteLinesTests adds 8 cases:

• the issue's repro, where every line lands at →
• \r\n and \r input on an LF writer
• a multi-line @"..." literal containing \r\n
• interior blank lines
• an open last line
• a call made mid-line
• null/empty (two cases)

With WriteLines reduced to Write(fragment), the 6 behavioural tests fail. The null/empty cases pass either way by design. With the change, the full suite passes: 257/257.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud