[psteinroe]

Stacked on #893.

Follow-up to #884. Expanded CASE expressions lost their alignment when CASE started left of the current indent, and a broken WHEN condition continued at the WHEN column.

Alignment from where CASE starts

The renderer stored an alignment as an offset from the indent of the level it started at, and clamped a negative offset to zero. When the text on a line starts left of that indent, the offset is negative. That happens for select case once the select list has opened its indent, or on case in a join, and WHEN and END then drifted right:

-- layout: expanded, clauseBodyStyle: compact, indentSize: 8
-- before
select case
                when a
                        then 1
                else 2
        end
from t;
-- after
select case
               when a
                       then 1
               else 2
       end
from t;

An alignment now keeps the column CASE starts at together with the indent level at that point. A continuation line starts at that column plus one indent per level opened since. When the offset is not negative this gives the same columns as before, so the existing expanded CASE output is unchanged.

With indentStyle: "tabs" an aligned line is written as one tab per indent level and spaces for the rest, as before. When the column is left of the indent, it uses only as many tabs as fit before the column: \t when instead of \t\t when.

WHEN conditions are indented

A WHEN condition that breaks continued at the column of WHEN, so and read as a sibling of when. In expanded layout every AND/OR breaks, so this affected every multi-operand condition:

-- before
case
  when aaaa = 1
  and bbbb = 2
    then 'x'
-- after
case
  when aaaa = 1
    and bbbb = 2
    then 'x'

The condition is now one indent level in from WHEN, the same way a WHERE condition is. Fit layout does the same once the condition breaks. Expanded layout still breaks at every AND/OR in a WHEN condition. I left that alone because it is what expanded layout does everywhere else, and the reporter of #884 uses it that way.

Docs

docs/features/formatting.md now describes the expanded CASE layout and what tabs do to alignment: the columns only line up when the editor's tab width equals indentSize. A test checks that the example in the docs is what the formatter prints.

Tests and snapshot changes

New tests in case_layout.rs: CASE after on with indentSize: 4, select case with indentSize: 8 in spaces and tabs, the exact tab and space output after a leading comma, and WHEN condition continuation in expanded and fit layout. Two tests in comment_layout.rs now expect the AND of a WHEN condition, and the comment before it, one tab further in. The only snapshot that changes is expanded_case_expr_200, where the AND lines of two WHEN conditions move one level in.

Not covered

A CASE nested in the THEN of another CASE still moves right by about 9 columns per level in expanded layout. Twenty levels reach 184 columns at width 100. Three or four levels stay within the width, so I didn't change the layout for this.

Follow-ups: The nested CASE drift in expanded layout is fixed in #935.