106 comments

[ 4.5 ms ] story [ 137 ms ] thread
This is pretty cool. Backspace not working for me though in Chrome.
Same here, Chrome on Debian.

Backspace and ESC not working, so after I enter a mode I'm stuck in it forever.

Really cool! It even supported doing things like:

    inoremap jj <Esc>`^
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.

… There are still browsers that use backspace for navigation?

(I'm a little surprised by this because I've seen so many complaints about it leading to data loss.)

Chrome and Firefox. Probably IE too.
No, at least for me (Firefox on Linux) Backspace doesn't do anything special.
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).
Ah, thanks. I don't need it anyway :) Alt + Left/Right works fine.
It also appears to be enabled by default on Mac OS X.
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!
_I_ use backspace for navigation. What's the alternative? Use a mouse?
Alt-Left.
On Mac OS X, the standard shortcut is Command-[ instead (and Command-] is Forward).
I generally use three fingers swipe to the left.
As do I. Actually, if I have a mouse, I tend to right click, then hit back, it's the first option.
In general Command-Left/Right-arrow should work as well unless it's been taken out of Safari.
if you use vimium/vimperator/something else you can do shift+H to go backwards, shift+L to go forward.
Which would require me to press two keys instead of one.
yeah but not to move your hand if you're on the homerow
Considering we're talking about Vim here, pressing keys should be second nature to you anyway...
There are still browsers that don't maintain form state across back/forward history?

(I'm a little surprised by this because I thought all browsers used backspace for back)

Wow, I can use hjkl to move my cursor !!!
Kinda cool as a demo, but too many vim shortcuts are hijacked by the browser for this to be useful to me.
fantastic! One issue - I keep hitting is using the backspace key in chrome is mapped to the back button... so it keeps taking me back here..
I use Vim for everything, this is great!
so... what exactly am i supposed to do with no file system?
yeah, I thought the same ... does a text editor in the browser make sense?
It seems to have some kind of filesystem. You can write files, there's /dev, /root, /tmp and /usr, and vimrc and color settings.

Not really sure how it all works, I only took a quick look.

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!
Can anyone think of a sane way to make this integrate with github?
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.
Github is using the Ace editor, which has a VIM mode.
(comment deleted)
Who wants to make a javascript emacs? you could call it emscriptenmacs..
ymacs (Fabrice Bellards Emacs "clone") is installed in jslinux.
For Vimium users: don't forget to enter the insert mode in your browser first ;)
Rule 34 for software: If it exists, there IS a javascript port of it.
That would be Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.

http://www.codinghorror.com/blog/2007/07/the-principle-of-le...

And tlrobinson's Law (or corollary?): Any submission to Hacker News about a novel JavaScript program will contain a comment referencing Atwood's Law.

https://twitter.com/tlrobinson/status/395636386671235072

What about emacs in Linux in JavaScript? :-)

http://bellard.org/jslinux/

It would be missing a good editor. Probably not a bad operating system however
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.

;-)

(comment deleted)
...authored by tlrobinson?
Even more true now that Emscripten and asm.js exist.
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.

Cool nonetheless.

(comment deleted)
Why not Acme.js yet?
(comment deleted)
Very slow (unusable) on a MacBook Air 1.4GHz 4GB RAM using Chromium 30.0.1589.0 (215899). I suppose it's the price of using an emscripten port.
All the three letter motions I tried don't work. Without them this is more vi then vim. caw ci" ca( all don't work.
It is built with the compiler flag: --with-features=tiny.
Waiting for os.js, javascript port of X operating system. And js.js, javascript port of javascript. Javascripteption anyone?
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.

[1] https://github.com/coolwanglu/vim.js/blob/master/web/vim_lib...

[2] https://groups.google.com/forum/#!topic/vim_dev/AQTHbUHijgg

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.
This also does not seem to be compiled with full optimizations, standard emscripten -O2 output looks somewhat different than what is here.