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.

You can say it's good. Or you can say it's bad. But you can't say you're indifferent.

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?