Skip to content

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

Closed
zbraniecki opened this issue Apr 17, 2017 · 8 comments
Closed

Allowing full-message variants to end without indention #42

zbraniecki opened this issue Apr 17, 2017 · 8 comments
Labels

Comments

@zbraniecki
Copy link
Collaborator

While working with Fluent syntax, I'm consistently hitting this awkward moment when this:

key = {
    $foo
}

is a parser error, while this:

key = {
        $foo
    }

is the way to go.

I believe we should allow for the former.

@stasm
Copy link
Contributor

stasm commented Aug 17, 2017

I'd like to err on the side of consistency. Here's a linter rule that I would like to suggest:

If a Pattern contains a TextElement with \n or a SelectExpression, it should be written starting from a new line.

The following valid FTL:

key1 = Foo
    Bar

key2 = Foo { $arg ->
       *[one] One
    }

would pritty-print as:

key 1 =
    Foo
    Bar

key2 =
    Foo { $arg ->
       *[one] One
    }

@zbraniecki
Copy link
Collaborator Author

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:

key = { OS() ->
    [mac] Mac
   *[other] Other
}

over:

key =
    { OS() ->
        [mac] Mac
       *[other] Other
    }

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.

@stasm
Copy link
Contributor

stasm commented Nov 3, 2017

As a first step, I suggest to only allow no indentation in values which start immediately on the line of identifier =. This would in practice mean defining two different value productions in the EBNF: inline-value and block-value. By doing so, I would like to allow this:

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

@stasm stasm added this to the Syntax 0.5 milestone Nov 9, 2017
@stasm stasm changed the title Consider allowing full-message variants to end without indention Allowing full-message variants to end without indention Nov 11, 2017
@stasm
Copy link
Contributor

stasm commented Nov 14, 2017

I think it would be possible to allow this as syntax sugar (no changes in the AST) by something like:

value ::= pattern | '{' __? block-expression WS? '}'

…where WS represents any white-space, with and without line breaks and with and without indentation.

@stasm
Copy link
Contributor

stasm commented Nov 14, 2017

By "no changes in the AST" I mean that the value field of a message written using the syntax sugar would still consist of a Pattern with a single Placeable in which there's a SelectExpression (with or without the selector).

This allows to always assume that a message's value is a Pattern.

@stasm
Copy link
Contributor

stasm commented Dec 7, 2017

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
    }

@stasm
Copy link
Contributor

stasm commented Jan 19, 2018

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.

@stasm stasm reopened this Jan 19, 2018
@stasm stasm modified the milestones: Syntax 0.5, Syntax 0.7 Jan 19, 2018
@stasm stasm added syntax and removed syntax labels May 15, 2018
@stasm
Copy link
Contributor

stasm commented May 18, 2018

This is now scheduled to land in Syntax 0.7 as part of #87.

@stasm stasm closed this as completed May 18, 2018
@stasm stasm removed this from the Syntax 0.7 milestone May 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants