jerch

I did not like the static memory in the first place, because it creates tons of frictions for the higher level JS integration. But emscripten currently does not allow "memory.grow"...

Oh I see, well thats interesting. What JS engine do you use for that? If you want to go that route we prolly should share more general ideas about wasm...

kk you got me, gonna try your patches with the "always write" patch merged than. Seems to be the fastest for you, if I am not mistaken? Still wondering why...

@christianparpart Imho murmur3A is also worth a look in terms of speed for a fallback. @WSLUser What does this have to do with windows terminal?

Well it is more meant as a fallback thingy. I have no numbers for AES-NI, but I am pretty sure you cannot beat native circuits with any software hash trickery....

@WSLUser Haha, well thats like telling someone to stop tinkering, or an engineer to stop engineering, because some other more famous party might come up with a better solution one...

I'd simply go for the fastest here. And since the possible search domain is quite small, I suggest to investigate, whether there exists a perfect hash function with very low...

So you want something like a local echo mode. As you already figured, xterm.js does not provide anything like that out of the box, as it mainly mimicks functionality of...

My idea on those things? Broken for our terminal world, because a "maybe render it like this" never gonna work for appside (or a multiplexer). It breaks with the promised...

@christianparpart Further note that those runwidth decisions cannot be made from an unicode version flag alone, as unicode explicitly left that up to the output system. E.g. take a compound...