Actually it's quite simple. We parse from left to right. When we hit EOL, we return to the beginning of line and increase Y by one.

Blocks are parsed in the following way: when we get the beginning count of block opening characters, we move Y by one, loop right while whitespace, until we encounter ending count of block characters.

In transposed block, we just switch X and Y, it is easily done with pointers, and use the same code.

    (fst-atom """   trd-atom frt-atom
      """     00001
      asdf    00002 """    fth-atom)
      qwer    00003 hahaha
      zxcv      """ hehehe
      """           hohoho
                    """

I'm not sure I'd like the above to be parseable.

Here, I brought down the enthusiasm a bit in the closing word. I hope it creates less confusion now.

Solves a mess with closing parens. But I'm not sure if it is worth of hassle. Anyway, it exists.

Ikr? People should loosen a bit, why should everything be so serious?

Sorry for the confusion. I must be a very disturbed person because I kind of like what is explained there.

Changed the "somewhat" to "very" in the document, thank you.

Thank you for the criticism. Lots of lispers share your opinion.

I don't intend to be funny. Just a bit childish, but in a good way :)

I'm scared the people who decide how I write Dune config files will see this and think its a good idea.

Terrified, really.

Here is another example, an axiom from propositional logic:

    (impl (impl p (impl q r)) (impl (impl p q) (impl p r)))

which, vertically indented in a transposed block, looks like this:

    * (                                               )
    *   i (               ) (                       )
    *   m   i p (       )     i (       ) (       )
        p   m     i q r       m   i p q     i p r
        l   p     m           p   m         m           *
            l     p           l   p         p           *
                  l               l         l           *

which, using transposed lines within the transposed block, finally looks like this:

    * (                                                                                           )
    *   *impl* (                               ) (                                              )   *
    *            *impl* *p* (                )     *impl* (                ) (                )     *
                              *impl* *q* *r*                *impl* *p* *q*     *impl* *p* *r*       *

This time I won't make any judgements. Could be good, could be bad, you decide.

Not sure if that example helps. You can make any programming language hard to read without some basic formatting. The way I would write the sexpr would be:

  (impl
    (impl 
       p 
       (impl q r))
    (impl
       (impl p q)
       (impl p r)))

It's clear when each section begins and ends and doesn't require complex parsing rules.

That looks clean, can't argue that.

It is true that I plan a custom renderer with scripting support, to replace the HTML version. From the tests I performed by now, it can be smoother and faster than the current version. But it is yet to be seen how well would a substitution to HTML catch up with the current state of art CSS+HTML+JS.

At some moment I had a version with cached bitmaps that simply flew fast and smooth. But, since HTML has some serious issues with rendering to bitmap from js, I had to pick the slower version with native real time HTML rendering.