> I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?

No. The ones I've looked just set up stuff, like launching a language server. They shouldn't be involved in typing.

I think it's related to the GPU usage. It's easy to introduce delays when you do GPU compositing, and the OS will already be doing its own.

As for emacs, IIRC they did some ugly things to update the UI directly instead of going through the normal event loop, which was causing compatibility issues later on.

On my system (Linux, 4k display without scaling) the fonts look awful, but bumping up the font weight more or less fixes it.

Yes, I'm aware of the iterative solution, which is why I explicitly mentioned the recursive one.

They tried to give the algorithm description to the LLMs, but they also used the recursive solution (see page 25 of the paper).

The recursive solution has a stack depth proportional to the number of disks. That's three pieces (two pegs and how many disks to move) of data for each recursive call, so for 6 disks the "stack" will contain up to around 15 values, which is generally higher than an unaided human will be able to track.

In addition, 64-256 moves is quite a lot and I suspect people will generally lose focus before completing them.

I think a human will struggle to solve Hanoi using the recursive algorithm for even 6 disks, even given pen and paper.

Does that change if you give them the algorithm description? No. Conversely, the LLMs already know the algorithm, so including it in the prompt makes no difference.