Enforce indentation for multiline string and variants about fluent

[stasm]

I met with @Pike today to discuss this. We both liked the idea of removing the | syntax for multi-line blocks. @Pike also supported the idea of requiring some (non-homogeneous) indentation for everything that constitutes the contents of a message, i.e. the value and the attributes.

In general, when asked about his general feelings about what Fluent should do about white space, he responded "the more, the merrier." For instance, we could allow new lines around the = introducing the value and inside of placeables. We're already talking about allowing it inside of the call-expression in #17.

Thanks to the indentation we can remove the | syntax. Text values would be left-trimmed and the trailing subsequent new lines would not be part of the value. In order to put leading white-space into a value, one would need to use escapes (\ or \u0020). We would still need to define exactly how escaping works. We talked about supporting \ ( a space), \t, \n, \*, \[, \{, \u and \\ but the exact behavior of the \ would be defined later.

It also seems like we could remove the special behavior of quotes (") outside of placeables.

Lastly, empty new lines between text blocks should be considered part of the value, allowing multi-block values to be split into paragraphs. Only a non-white-space character as the first character in a line would start a new entry.

[stasm]

Could we go even further and require indentation for } as well?

new-messages = You have { $num ->
        [one] one message
       *[other] { $num } messages
    } in your inbox.

This would work well with #6:

lipsum
    .label = Lorem
    .accesskey = L

In fact, what if required that values and attributes always be indented under the identifier. Could we relax the white space rules around the =?

new-messages
    = You have { $num ->
        [one] one message
       *[other] { $num } messages
    } in your inbox.

    .title = New messages help text.

Lastly, as you note, the indentation makes it easy to find the next identifier and thus help the error recovery. Could we simply get rid of the | prefix for multiline strings?

new-messages =
    You have { $num ->
        [one]
            Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec et venenatis
            sem. Duis feugiat nisl sit amet ligula condimentum vestibulum. In id augue
            tempor, lacinia eros maximus, vestibulum ante.
       *[other]
            Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec et venenatis
            sem. Duis feugiat nisl sit amet ligula condimentum vestibulum. In id augue
            tempor, lacinia eros maximus, vestibulum ante.
    } in your inbox.

The \ could be used to escape special characters like [ which are part of the content and appear as the first non-white-space characters on a given line.

[zbraniecki]

I'd be afraid of indentation based multiline patterns because they can be any character.

Currently, if it's a new line it's fairly easy both for parser and human to know that if it's "*[" - it'll be a default member.
I would not resign from pipe, but I know you don't like it.

[stasm]

I find the pipe hard to write and even harder to edit. I also dislike the fact that it's not used throughout the whole height of a block: namely, it must be omitted before variant keys and before the closing } of a placeable.

Let's suppose we allow using \ to escape any character into its literal meaning (e.g. \a becomes a etc.). Could we then support the edge-cases when you really need [ and *[ as part of your content and otherwise start parsing a new variant?

[zbraniecki]

Let's suppose we allow using \ to escape any character into its literal meaning (e.g. \a becomes a etc.). Could we then support the edge-cases when you really need [ and *[ as part of your content and otherwise start parsing a new variant?

From the parsers perspective (and tools I believe?) the challenge becomes that you need to analyze the pattern structure, have a list of characters that you need to escape if they're the first non-WS in a new line, and all of that sounds a bit fragile.

But totally doable.