`Box2Text` formatting of `I` behaves unexpectedly

[toinehartman]

Describe the bug

The documentation states that

I is a V box that indents every line in the output with is spaces

However, format(I([V([...]))) does not equal format(I([...])), even when setting is=0 on some boxes.

Investigating further, I am surprised by the formatting of I on itself, which does not seem to be formatted like a V at all.

rascal>format(V([L("a"), L("b")]))
str: "a\nb\n"
───
a
b

───

rascal>format(I([L("a"), L("b")]))
str: "  a  b\n"
───
  a  b

───

rascal>format(I([L("a"), L("b")], vs=1))
str: "  a  b\n"
───
  a  b

───

To Reproduce
Some tests showcasing this behaviour (I think only one of IisVsugar{1,2} might be correct).

test bool iProducesNewline() =
    contains(format(I([L("a"), L("b")])), "a\n");

test bool IisVsugar1() =
    format(
        I([
            V([
                L("a"),
                L("b")
            ])
        ])
    ) == format(
        I([
            L("a"),
            L("b")
        ])
    );

test bool IisVsugar2() =
    format(
        I([
            V([
                L("a"),
                L("b")
            ], is=0)
        ])
    ) == format(
        I([
            L("a"),
            L("b")
        ])
    );

Expected behavior
Equal formatting, and/or a clarification in the documentation of when exactly (for what parameters) this is (not) the case.

Desktop (please complete the following information):

• Context: standard library
• Rascal Version: `0.41.0-RC55-SNAPSHOT

Additional context
This came up while experimenting with a box-based formatter for Pico (usethesource/rascal-language-servers#677). Currently, this code is probably not used by many people. Once we expose formatting for DSLs, this behaviour might start to occur for more users.

[jurgenvinju]

Thanks for the report! It looks like, against the documentation, an I box behaves like an H box rather than a V box.

The source in the Box2Text module confirms this:

private Text II([], Box _c, Options _opts, int _m) = [];

private Text II(list[Box] b:[_, *_], c:H(list[Box] _), Options opts, int m) = HH(b, c, opts, m);

private Text II(list[Box] b:[Box head, *Box tail], c:V(list[Box] _), Options opts, int m) {
    Text t = \continue(head, c, opts, m - opts.is);
    return rhh(hskip(opts.is),  hh(t, II(tail, c, opts, m - opts.is - hwidth(t))));
}

It's very strange that the indentation size is used as the horizontal separator size. That should be fixed anyhow.

The H interpretation of I seems specific for the Rascal port and the very last version of the ASF+SDF port. All other versions syntactically only allow a single box as the child of an I box.

The I box syntax was generalized such that it could be passed to the newest higher order boxes G (group) and SL (separated list) like any other box constructor.

I think it makes more sense as a vertical list, but horizontal could make sense as well. We could even add a (default) parameter?

Thoughts @toinehartman @PaulKlint @tvdstorm ?