[the_mungler]

I'm not the biggest fan of the embed block syntax, for two reasons. 1. Having `%\\\%` escape to `%\\%` is confusing. Assuming you want to embed kson inside kson it would look like this:

```

%kson: level 1

  %kson: level 2

    %kson: level 3

      - "a list"

      - "of values"

    %\\%

  %\%

%%

```

Note that for each level of nesting, the delimiters inside the block have to increase, instead of the ones outside. In a long embedded block you probably copied from elsewhere, you have to check every escaped delimiter to make sure it has the correct number of back slashes and update it. It would have made more sense to have a varying number of % correspond to a matching set to close it. e.g. %%%kson: foo matches %%% and closes it.

2. It's impossible to represent strings where every line has at least some leading indent, because they "always strip their minimum indent".

I think both these issues are solved by using zig's style of raw string literals. An embed block could start with %tag and each following line with % continues the block. No closing delimiter or delimiter escapes needed.

```

%kson: level 1

  %%kson: level 2

  %  %%kson: level 3

  %  %  %  - "a list"

  %  %  %  - "of values"

  %  %  %  - "indented"

```

Granted, this also kind of looks ugly with percent signs. But the upside is you could paste in each sub level, and a text editor could insert the symbols for you before each line, just like they already do when highlighting text and commenting it out.

[dmarcotte]

Thanks for trying out KSON and having a look at the embed blocks. When embedding text inside text, the price/tax to delimit it must be paid somewhere, as the "KSON turducken" you've cooked up here demonstrates. We are familiar with this dish! Here's how we considered it in the design:

Our design observes that triple+ embedded KSON embed blocks should be rare and are zany enough information architecture that we do not need to cater to them. We accommodate singly-embedded KSON by offering `$/$$` as an alternative embed delimiter that can be used to minimize escaping (fun: if you paste your example in the playground <https://kson.org/playground/> and format it, the formatter will minimize the escaping for you).

The two-char end-delimiter is important to make it trivial to describe the end of a embed block: a `%` embed block ends if and only if exactly `%%` is encountered. This is designed to make it dead simple for humans and (especially) tools to understand the bounds of an embed.

Zig's manually-managed margin approach is interesting. Paying the embedded text price/tax with a manually managed margin is inventive, and does indeed give good whitespace control and skips all escaping. However, having to always manage that margin goes against our goal of having embed blocks facilitate "pure" embedded editing as much as possible---every block that does not contain `%%` can be edited completely in the block's native language.

Hopefully that helps make some of our goals and design decisions more clear. We've worked hard to minimize the cost of embedding while maximizing the clarity, utility and toolabilty of it. Definitely open to ideas on improving our min/max'ing here if folks see opportunities. Come chat with us on Zulip if you've got thoughts! https://kson-org.zulipchat.com/

[the_mungler]

Yeah, definitely some tradeoffs there. I do like that it makes the common use cases easy. And yeah, I did make quite the "turduckin" as you put it .

A more concrete criticism: suppose you wanted to embed some markdown, where all of the content consisted of an indented code block.

%markdown: a code block

    fn foo(){

        # do stuff

    }

%%

My understanding is the leading spaces would be removed, breaking the formatting and making it normal text instead of a code block.