Very nice. It first struck me as just a curiousity but honestly I would consider using a browser plugin like this that let me edit web forms with something like this, picking up my local ~/.vimrc. That or for the various interactive code editing tools like ipython.
Just a tip - if you'd like to use vim on ChromeOS - look into Caret. Its a nice code and text editor like Notepad++, and it has a vim-mode. Its been a while since I've used it, and I don't think it's very extensible, but its something.
Zed[1] is probably the best editor on Windows, OSX, and Linux too. I hate to go back to editors where I have to save, manage what tabs are open, and clutter the workspace with toolbars and buttons.
...er, don't wish to sound negative, this crashed on me. 8Gb RAM Ubuntu box with Chrome - normally a stable computer that doesn't do things like 'swap'. I might try it again on my ChromeOS box, but, right now, that is as far as I got.
Nice, I had a crack at doing this a while back using emscripten, but couldn't get around that Vim's input handling is blocking.
Looks like coolwanglu has found a way around this by hacking some kind of async transformation into emscripten. I haven't looked at his code, but I suspect he specially handles known blocking libc calls. My guess is some how storing the set of stack frames when a blocking function is called so that the stack can be unwound to let the js engine continue.
It did not work well in Chrome: 36.0.1985.49 beta
C-f, C-b didn't even work.
I then gave it a shot in Firefox nightly and it seemed to work really well. This brings me joy.
I don't like to edit forms/documents on the web; it's a constant struggle against my muscle memory. Vim.js could be the start of something that could change that. Well done!
Chrome 36 beta came out half a year ago. It's unreasonable to expect web developers to support very old versions of a browser that silently auto-updates. Most popular frameworks and libraries, such as jQuery (see https://jquery.com/browser-support/), only officially support the latest stable Chrome and one version prior.
(Edit: strike point about Chrome release date; had the release-release date, parent probably means when beta started.)
I'll also note that in the past, I've purposefully not upgraded due to serious bugs in the present version of Chrome. (There was a great one a while ago where entire websites — notably Wikipedia — were rendering in the wrong font, for example.)
> a browser that silently auto-updates
While I'll grant that this is true for the majority of users:
1. It requires a user to restart their browser. For me, this usually means the next weekend or Chrome/OS X crash, since during the week I'm usually busy with things other than restarting the browser…
2. Not all OS's auto-update, though this is a very small minority.
ctrl-n in insert mode (or any completion like ctrl-x ctrl-l)
of course plenty of command line options like virtualedit:
Though it does implement the expression register ( i CTRL-R = ), the regex class \x (among Vim's other rando regex classes), and :set synmaxcol which is pretty nitty gritty.
If you're using Vim and not using q: q/ :normal ( and hopefully :t, :m etc with relativenumber ) you're missing a lot of Vim's power, and would be better off in an IDE. The speed benefits from Vim are from knowing a large amount of the editor's features.
Practical Vim the book is a good place to start. You should be spending as much time learning Vim as using Vim for about the first two years of your Vim usage.
- I don't quite like the 'would be better off in an IDE' part.
That said, at this point I'll better see what I can find about these oh-so-essential features and I might even add them to my routine/workflow (so far, I still don't know why though...).
Edit: As expected, the help page doesn't explain why I should care about those. q: and q/ are nothing I ever missed, :normal is weird and I cannot imagine what it is used for. Basically my whole reason to jump on this thread "Okay, now I don't know these. Why are they useful?" is absolutely still relevant. Reading the documentation isn't enough. I .. won't buy a book at this point.
I'm not trying to be rude, but I'm not going to transcribe a book or help files here. The answer is read Practical Vim. It should be required reading for any Vim user.
q/ and q: are improved versions of : and / -- when you type q: or q/ it brings up a split with your : or / history in it -- so now you can use normal vim editing commands to edit an existing command or type in a new one, and then hit return and it runs the / or : on that line.
Once you get used to using them, you will only use / or : when the search or command you want is absolutely simple and straightforward.
:normal lets you use normal commands at a command line, often used for automation or scripting stuff... so you can do :normal 5j to go down 5 lines.
Can someone please explain how this is different from CodeMirror vim mode? I am an emacs user and know only the basic vim commands and so, I cannot tell if there is something fundamentally different between the two implementations.
This is the vim C code compiled into Javascript. Not simply an implementation of vim behavour, but the actual vim source code compiled and running in the browser.
it's C code compiled with emscripten to run in the browser.
CodeMirror is directly written in js.
In theory,anything written in c or c++ can run in the browser.
A straightforward compile of vim using emscripten doesn't work, because the I/O just doesn't work right (blocking I/O, for one thing). Emscripten works "out of the box" mostly on computation-heavy rather than interaction-heavy code.
Didn't downvote you but since you seem to wonder about the downvotes I think they came because you jumped in in a negative way (and was wrong). I'd say that the downvotes were kind of justified here, - I want HN to be positive to creators unless they are wrong/evil.
It's a crappy hack, but paste this into your JavaScript console:
function exportFile(path) { var b = new Blob([FS.readFile(path).buffer], {'type': 'text/plain'}); var u = URL.createObjectURL(b); window.location.href = u; }
Although expected, it is a little clunky/slow to use. Fun to play around with nonetheless, but I wonder whether an Emscripten port of Neovim would be a little sprightlier.
But more importantly, all IO is being ported to libuv, from the blocking calls that are currently being done. This obviously fits Javascript's IO model much better, as you don't have to fake an event loop in Javascript as this port is apparently doing - you just use the event loop the JS implementation provides. After that's done, I'd expect Neovim to work more smoothly as a JS port.
61 comments
[ 2.5 ms ] story [ 103 ms ] threadBut one thing (for whatever it's worth) what makes vim super useful (to me anyway) is the plugins and my vimrc with custom key bindings.
(edit) On second look, it appears you can modify vimrc. Very nice.
[1] http://zedapp.org/
Looks like coolwanglu has found a way around this by hacking some kind of async transformation into emscripten. I haven't looked at his code, but I suspect he specially handles known blocking libc calls. My guess is some how storing the set of stack frames when a blocking function is called so that the stack can be unwound to let the js engine continue.
Good stuff.
It did take a little longer than vim to load, but I guess that's expected.
I then gave it a shot in Firefox nightly and it seemed to work really well. This brings me joy.
I don't like to edit forms/documents on the web; it's a constant struggle against my muscle memory. Vim.js could be the start of something that could change that. Well done!
I'll also note that in the past, I've purposefully not upgraded due to serious bugs in the present version of Chrome. (There was a great one a while ago where entire websites — notably Wikipedia — were rendering in the wrong font, for example.)
> a browser that silently auto-updates
While I'll grant that this is true for the majority of users:
1. It requires a user to restart their browser. For me, this usually means the next weekend or Chrome/OS X crash, since during the week I'm usually busy with things other than restarting the browser…
2. Not all OS's auto-update, though this is a very small minority.
I was merely providing feedback / datapoint.
https://github.com/coolwanglu/vim.js/commits/master
q/
q:
:normal
ctrl-n in insert mode (or any completion like ctrl-x ctrl-l) of course plenty of command line options like virtualedit:
Though it does implement the expression register ( i CTRL-R = ), the regex class \x (among Vim's other rando regex classes), and :set synmaxcol which is pretty nitty gritty.
Can you elaborate and explain what you're missing and what for?
Practical Vim the book is a good place to start. You should be spending as much time learning Vim as using Vim for about the first two years of your Vim usage.
- you haven't answered my question. Like, at all.
- I don't quite like the 'would be better off in an IDE' part.
That said, at this point I'll better see what I can find about these oh-so-essential features and I might even add them to my routine/workflow (so far, I still don't know why though...).
Edit: As expected, the help page doesn't explain why I should care about those. q: and q/ are nothing I ever missed, :normal is weird and I cannot imagine what it is used for. Basically my whole reason to jump on this thread "Okay, now I don't know these. Why are they useful?" is absolutely still relevant. Reading the documentation isn't enough. I .. won't buy a book at this point.
In fact, I think I only type `q:` as a typo when I'm trying to `:q[uit]` :p
Once you get used to using them, you will only use / or : when the search or command you want is absolutely simple and straightforward.
:normal lets you use normal commands at a command line, often used for automation or scripting stuff... so you can do :normal 5j to go down 5 lines.
C-n is just normal complete
http://kripken.github.io/emscripten-site/
Dropping support for operating systems and reformatting the code doesn't make it run faster.
But more importantly, all IO is being ported to libuv, from the blocking calls that are currently being done. This obviously fits Javascript's IO model much better, as you don't have to fake an event loop in Javascript as this port is apparently doing - you just use the event loop the JS implementation provides. After that's done, I'd expect Neovim to work more smoothly as a JS port.