-
Notifications
You must be signed in to change notification settings - Fork 45
Allowing full-message variants to end without indention #42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'd like to err on the side of consistency. Here's a linter rule that I would like to suggest:
The following valid FTL:
would pritty-print as:
|
It feels to me like it's the most pronounced papercut people have been encountering so far. It also is my personal aesthetic pet peeve. I find this:
over:
and I'd say that if cannot come up with a way to make what feels natural work (as per original FTL design approach we took), and instead require a quirk, that would be sad. |
As a first step, I suggest to only allow no indentation in values which start immediately on the line of foo = { $num ->
*[other] Other
} …and this: foo =
{ $num ->
*[other] Other
} …but not this: foo =
{ $num ->
*[other] All
} The last snippet suggests that it's okay to continue the multiline value without indentation, like so: foo =
Lorem ipsum { $num ->
*[other] dolor
} sit amet, consectetur
adipiscing elit. // syntax error |
I think it would be possible to allow this as syntax sugar (no changes in the AST) by something like:
…where |
By "no changes in the AST" I mean that the This allows to always assume that a message's value is a |
I opened #74 with the proposed implementation in the EBNF. Introducing this syntax sugar makes the parser more tolerant to input. OTOH, I'd like the serializer to continue to use the canonical syntax: foo =
{ $num ->
*[other] Other
} |
I backed this out in #81; see the comments there for the rationale. I'd like to consider this again in the next milestone of the Fluent Syntax along with other improvements to relax the indentation requirements. |
This is now scheduled to land in Syntax 0.7 as part of #87. |
While working with Fluent syntax, I'm consistently hitting this awkward moment when this:
is a parser error, while this:
is the way to go.
I believe we should allow for the former.
The text was updated successfully, but these errors were encountered: