3 ms·
Well, I don't know what you mean by slow, but it could be the use of setTimeout() every 10ms to simulate[1] Vim's synchronous busy-wait is affecting responsiven
by justinmk 13y ago
Well, I don't know what you mean by slow, but it could be the use of setTimeout() every 10ms to simulate[1] Vim's synchronous busy-wait is affecting responsiveness.
Lu mentioned[2] on vim_dev that it was necessary to write a hack for this portion.
[1] https://github.com/coolwanglu/vim.js/blob/master/web/vim_lib.js#L478 https://github.com/coolwanglu/vim.js/blob/master/web/vim_lib...
[2] https://groups.google.com/forum/#!topic/vim_dev/AQTHbUHijgg https://groups.google.com/forum/#!topic/vim_dev/AQTHbUHijgg
- ehsanu1 13y agoYeah, I hit this same road-block when trying to port vim to JS and gave up because it didn't seem worth it after that. If only vim ran a regular event loop, it would have been such an easy port, compared to what they had to do here. When figuring out how I could overcome it, I remember reading accounts of KDE developers trying to embed vim into their widgets and failing over and over. In the end, there was a solution to "embed" vim with some special IPC the netbeans IDE developers put into vim, but you had to run vim as a separate process for that to work - which is not possible on the web as it stands today. The numerous synchronous busy-wait loops in vim killed all approaches I had considered, so kudos to these guys for figuring out a way, even if it's slow.
- justinmk 13y agoThere's an event loop patch on vim_dev being played with. Maybe in the next 12 months we will see some action with that approach or the other "timers" approach submitted (and ignored by Bram) by the floobits devs.
- azakai 13y agoThis also does not seem to be compiled with full optimizations, standard emscripten -O2 output looks somewhat different than what is here.