PatientZero's law:
Any submission to Hacker News about a novel Java script program containing a reference to Atwood's law will contain a reference to tlrobinson's law.
I'm normally unimpressed by applications ported to javascript. However, this actually has me excited. I would love to be able to edit all my Dropbox text files with a web interface. If anyone here works for Dropbox, I beg you to integrate this!
Backspace ended up triggering the browser's back action though. Other than that, this is really nice.
Edit:
After looking at the source, this seems to make use of emscripten to reuse Vim's existing source code. This really makes me wonder what other cool things we can bring over to the client side.
Not on Linux, where the 'previous page' action is mapped to Alt-left by default. After being initially frustrated, I got really used to Alt-Left for going back.
The reasoning behind it is pretty smart too, because numerous times backspace can result in the loss of data, like when you're filling up a form and you hit backspace outside of a text box.
Indeed, I like the 'alt-left' keyboard shortcut, though I especially like it because it does the same thing in both Chrome and Firefox on both Windows and Linux! Yay for consistency!
The “backspace = back” behavior of Firefox is only enabled by default on Windows. The behavior is controlled by the about:config setting `browser.backspace_action` (http://kb.mozillazine.org/Browser.backspace_action).
This... Plus Gmail... Man that's fantastic. I have sent an embarrassing number of emails that end with :wq.
Once you try Vim, it's really hard to go back. I also tried using mutt instead of GMail, and while it gets me 90% of the way there, the lack of graphical preview of attachments and things like filters and HelloSign make GMails web interface more useful.
There are browser plugins that let you edit <textarea> elements in your $EDITOR.
I use "It's all text!" in Firefox for this purpose and it works well; the workflow is pretty simple: focus in textarea, hotkey to switch to vim, save & close buffer to switch back to the browser. (not affiliated, just a user).
Yep, I constantly have to delete jj at the end of emails. The cool thing about this port is that mapping seems to work. Naturally the first thing I tried was :inoremap jj <esc>, which I don't think works in codemirror + vim plugin.
I save very often using :w. When I want to save and exit my brain is now hard-wired to do :wq. It would probably take a year for me to train myself to use :x, which is arguably just as slow since I have to reach down with my ring finger instead of up. Not saying anyone should switch, just that it would be hard for me to do so.
did you port ncurses using emscripten? This could enable bringing a large portion of GNU over to the browser as a cloud-based app. Stallman's nightmare, in other words.
It works amazingly well. However don't split windows then use ctrl-w j to switch. The browser captures ctrl-w first and closes the tab. Other ctrl-* combinations don't work probably for similar reasons.
I really hope someone will patch it into the IPython notebook (or at least enable the codemirror vim keybindings). If I can find the time to learn some javascript I'll give it a go myself.
Given the size of the "compiled" file, i'd say it's a bad idea . A better idea would be whatever js editor with a vim mode, not c code compiled with emscriptem like this one.
Lots of comments seem to expect some further web integration with various services but this looks like more of a prototype/proof-of-concept using emscripten.
While this is impressive, I find it surprisingly slow compared to much more demanding applications with bigger code bases compiled via Emscripten. Any ideas why?
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.
Yeah, 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.
There'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.
And this one is a test-bed for new JS language features (or at least meant to be - don't know how far along it is): https://github.com/mozilla/narcissus
