tearflake

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.

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.

That looks clean, can't argue that.

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 :)

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.

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.

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.

I'm sorry, I really wouldn't know what's happening there. On my Linux, Chromium works the best, Firefox can pass, Opera is a bit slower, and Epiphany (is that the name?) chokes a fair bit.

On i3, Windows things seem fine - I tried Edge, Chrome, and Firefox.

On Mac, I somehow managed to get it working based on Lambda Test web interface feedback, but I wouldn't know the real use performance.

May I ask, what machine you are running it on? On my Celeron (4GB RAM), things are OK-ish.

Maybe a note keeping app?