end: header

[amitu]

Note: I prefer @ and VecSS over this discussion.

We have a end section syntax:

-- foo:

-- bar:

-- end: foo

Because of -- end: we know that foo is a "parent section" and bar is its child. We have a similar problem for complex section headers. We can use end: <header-name> to match -- end: <section-name> syntax:

-- foo:
sidebar: 

-- bar:

end: sidebare
next-foo-header: 1

Here we have passed bar to foo not as "children", but as header/argument sidebar.

We can do this for caption as well:

-- foo:

-- bar:

end: caption
next-foo-header: 1

Here we have used caption as the header name. If caption is the header name, we can say -- foo: line must not contain any data, but we can leave it as is also.

-- foo: this is a long

caption that spans multiple lines

end: caption
next-foo-header: 1

vs

-- foo: 

this is a long

caption that spans multiple lines

end: caption
next-foo-header: 1

I like latter, our fastn fmt should generate this. Should we accept former or should former be error? Ambivalent. Generally when ambivalent prefer stricter is my approach, let's see.

After end: <header-line> there must be no line gap, else it will trigger switch to body as it is our current behaviour.

Removing -- <section-name>.<header-name> syntax

We currently allow complex header using this syntax:

-- foo: 
next-foo-header: 1

-- foo.caption

this is a long

caption that spans multiple lines

-- end: foo.caption

This syntax messes with the order of headers (sometimes that is important, and moves them below the body etc. I am not a fan of this syntax, and think we should deprecate / remove it.

[siddhantk232]

Is this a valid example?

-- foo:
sidebar: 

-- bar:

end: sidebare
next-foo-header: 1

the header sidebar is taking a ui (I'm assuming) then why bar is passed like --bar. What is the type of sidebar here? If it's a ui type then shouldn't it be:

-- foo:
sidebar: bar ;; no end: sidebar since this is oneline
next-foo-header: 1

[amitu]

What is the type of sidebar here?

At p1 level, we cannot answer this question. sidebar can be of type bar, where bar is a record, with zero required fields. Or sidebar can be a list of bar records, with bar having zero required fields, and creating a list with single bar instance. sidebar can also be of type ftd.ui, in which case it is expecting a "component instance", what you showed, sidebar: bar, here the bar is component "constructor". This is invalid. You have to -- bar: to create a bar instance, which is what sidebar needs. And finally sidebar can be list of ftd.ui, and we have passed a single ftd.ui to it.

-- foo:
sidebar: 

-- ds.sidebar:
-- ds.column:
-- ds.heading-large: this is a heading

this is some body

-- ds.column
-- end: ds.sidebar

end: sidebar
next-foo-header: 1

Or

-- record person:
caption name: 
body bio:

-- show-person:
person: 

-- person: Jack Bauer 

Our nation is under attack. Once again. Of course. 

end: person
current-employee: true

Or

-- show-employees:
employees: 

-- person: Jack Bauer 

Our nation is under attack. Once again. Of course. 

-- person: Boejack Horseman

I am a man. I am a horse. I am depressed.

end: employees
company: FifthTry

[amitu]

Explicit Caption Continuation

Is there an ambiguity in this code:

-- foo: this is a long

caption that spans multiple lines

end: caption
next-foo-header: 1

Consider:

-- foo: this is a long

-- bar: caption that spans multiple lines

end: caption
next-foo-header: 1

The end: caption line belongs to the foo or bar?

You can argue that only caption of basic type can be used in caption line for foo, eg this is long has to be a string, and can not be any other type, and there for the -- bar can not be continuation of a string, so there is no ambiguity and code snippet is either invalid, or the end: caption is for bar, and next-foo-header is actually a header getting passed to bar, and bar is a sibling of foo, not a child.

[amitu]

-- ed.classroom classroom: Tech Every Programmer Should Know
url: amitu.fifthtry.site/tech/
contents:

    -- it:
    content: $unix-time

    -- it:
    content: $internet-protocols

    -- it: HTTP
    
    -- it:
    content: $css-color

    -- it:
    content: $rgb

end: contents

[amitu]

-- ed.classroom classroom: Tech Every Programmer Should Know
url: amitu.fifthtry.site/tech/
contents: it{content: $unix-time}, it: HTTP{content: $http}

-- foo: asd @hello: world @integer x: 20
x: 10
y: hello, world, first, second ;; list of string

-- foo: asd {hello: world; x: 10; y: hello, world, first, second}


-- ftd.text: Message: {-- f: Hello {-- r: world!} foo: bar}

-- foo: asd {hello(a=$x)}

-- foo: asd >hello: world >integer x: 20
-- foo: asd ~hello: world ~integer x: 20
-- foo: asd %hello: world %integer x: 20
-- foo: asd &hello: world &integer x: 20
-- foo: asd -hello: world -integer x: 20
-- foo: asd - hello: world - integer x: 20
-- foo: asd <> hello: world <> integer x: 20
-- foo: asd :hello: world :integer x: 20

[amitu]

-- foo:
x[]: 1, 2, 3

-- foo:
x[:]: 1:2
x[]: 3

[amitu]

VecSS = Vec<StringOrSection>  // header value, or the condition portion of conditional header

-- foo: {
    this is a long
    caption that spans multiple lines
}
next-foo-header: 1

-- foo: 
color if { 
    x > 10 
}: red

-- foo: 
color if { 
    x > {
    10  + 20 }
} > { 20 }: red

-- foo: hello {

    -- bar:

} world {
    -- hello:
}
next-foo-header: 1

-- foo: hello {-- bar:} world {-- hello:}
next-foo-header: 1

[amitu]

can we try to remove -- end: foo in favour of {}s?

-- component foo: 
integer x:

{

-- ftd.row: {

}

}

Not liking it.