Hacker News Reader

Comment by jlgreco | Hacker News Reader

I am wondering in what way a "modern vim" isn't "vim". GVim exists, and plugin management is a problem frankly solved years ago.

I also wonder how he is going to support modern features that Vim currently has with a web-based editor. Can I script this in my choice of modern languages? Python? Ruby?

If I were going to change any single thing about Vim, it would be to make MzScheme scripting support a first class citizen, and slowly re-engineer the backend to be more Emacs styled. Core C (or whatever, but C out of momentum) functions with the rest of the system build up in Scheme. I think it would be foolish to call such an improvement "modernizing" though, since it is hardly a new idea. ;)

View on HN

> If I were going to change any single thing about Vim, it would be to make MzScheme scripting support a first class citizen, and slowly re-engineer the backend to be more Emacs styled. Core C (or whatever, but C out of momentum) functions with the rest of the system build up in Scheme.

Thank god there are people who share this vision! I have solemnly promised to myself that I will write a new vim in exactly this fashion if no one has done so in the next 10 years.

One thing that I don't understand about contemporary developers is the aversion to running their editors in a terminal. The benefits of doing this are significant (e.g. session management with tmux, remote pair programming via the same), but programmers leave them behind for what is ultimately just eye candy.

The major reasons for this are the difficulty in binding complex key chords in a terminal, and the poor implementation of OS X's Terminal.app (both of which can be worked around today with a little work, and a proper X terminal). If this terminal-based workflow is going to thrive in the future, what will need to be modernized is the terminal.¹

So you heard it here first: if a new vim built atop a Lisp interpreter running on a new data-centric, mixed character-grid/HTML5-webview terminal emulator does not appear in the next 10 years, I'm on the job.²

¹ Some excellent musings on the subject: http://lubutu.com/idea/ivo

² This would all be easier if I could love to learn Emacs, but Vim modal editing is a pernicious addiction.

I heard you like Vim, but want an emacs-backend, without all the work.

http://emacswiki.org/emacs/ViperMode

You're welcome :D

I haven't used it myself, but I've heard a number of people say that it's not really the same. I think their complaint was that it's a somewhat superficial emulation.

Evil is better than Viper and Vimpulse in every way.

Have you tried evil[1]? I've heard good things about it (even from Vim people), so maybe it's a good compromise between Emacs and Vim.

[1]: http://emacswiki.org/emacs/Evil

That's a great article. Do you know when it was written? It's weird how it's just dangling there with all of 2 sentences of context at http://lubutu.com.

Also, how do you do the superscripts?!

Article was submitted by the author about a year ago:

http://news.ycombinator.com/item?id=3300264

> Also, how do you do the superscripts?!

Unicode. In my case I input them in vim by way of vimperator. You can input them in vim using the digraph feature (try <C-K>11 in insert mode).

My vimrc actually parses my ~/.inputrc to extract the keybindings I use to input Unicode characters in bash and every other program that uses readline, allowing me to use the same keys for Unicode chars in every context that I input text.

https://github.com/guns/meinhaus/blob/guns/etc/inputrc#L144

https://github.com/guns/meinhaus/blob/guns/etc/vim/local/com...

The Compose key in in X11 does the same, but globally. I think it's not bound by default; I have it on the right extra Windows key. Compose, then 1 then ^ generates a super-scripted ¹.

/usr/share/X11/locale/en_US.UTF-8/Compose has a list, mostly filled with obscure stuff like ㊷.

As tikhonj mentioned, Emacs evil-mode is very likely exactly what you're looking for. I had considered myself a hardcore vim user, but I felt the call of Slime and org-mode. When I finally took a serious look at Emacs, I became convinced that Emacs with evil-mode is the ultimate editor for vim lovers.

What concerns me about vim emulation modes is the uncanny valley mentioned by another poster. Working in a second-class interface doesn't sound that great.

However, that's pretty strong praise, so I promise I'll give it a shot before trying to birth a new editor into the world.

I've used Emacs for the last 10+ years first with my own custom keybindings and recently with keybindings with 'default' CUA bindings like you find them in almost any other modern application. Before I switched to Emacs I used vi/Vim for almost 10 years. Also, even when I had switched to Emacs I still used Vim on the commandline and on remote servers but not in any advanced way.

I tried out evil-mode a couple of weeks ago just on a lark and I am staying with it. You really get the best of both world[1] this way. It might be a little strange at times but I wouldn't describe the usage as a second-class interface. Just different. I'd rather describe the default Emacs keybindings as a second-class interface :-)

[1] this will not mean much if you've never used Emacs

I hate how editing in a terminal is "single-threaded" so I can't edit code while running it and examining output.

I was about to disagree with you, but after running Conque in a vsplit, I found that it only processed changes in insert mode.

Another problem with running in a terminal is the lack of good integration with window-system cut/paste (e.g., where you can use editor commands to select text, copy it, and paste it in some other app, getting the actual text instead of just what's displayed on the terminal).

I often run Emacs in a remote screen session (well actually I open a terminal frame in my already-running window-system Emacs), and this is by far the biggest annoyance for me.

> Another problem with running in a terminal is the lack of good integration with window-system cut/paste (e.g., where you can use editor commands to select text, copy it, and paste it in some other app, getting the actual text instead of just what's displayed on the terminal).

This works quite nicely in Vim (even when running in console) with X11. You can access both X11 clipboards from Vim if it was compiled with that option (if you use binaries, most likely it is).

The registers for X11 clipboard are "* and "+.

Sure, if you also have an X display-connection to the same machine where the terminal itself is running available and advertised. Unfortunately in many running-inna-terminal scenarios, you don't have such a thing...

Implemented with Python:

http://vixn.org/

I'm on it too :) - ping me if and when you get started with this project.

My pet peeve has always been the crappiness of VimL, and the internal confusion between the scripting language and command mode. I've started designing a language (and have a toy implementation) whose goal is to be as powerful on the command-line as a shell language, but also super-easy to write large plugins in.

Way to be subtle with that last paragraph. :P

I'd actually approach the issue from the other end (that is, frontend) - There is a slight pain point in the strong binding between vim and terminals in that, as this video points out, the UI is limited by a character grid. This makes many features uglier and less usable, such as autocomplete, file viewers, the command line, the gutter, etc. It also limits your choices for fonts.

If I were to design a "modern" vim from the ground up, I'd probably arrive at something a lot like Sublime Text 2 with vim at the core.

Oh, don't get me wrong, I am a Vim user who can't stand Emacs. I just think that Emacs was engineered better. ;)

I think that re-engineering Vim to be more like Emacs under the surface would lend itself well to other things, like what you are suggesting.

Viper?

I gave it a shot, but I didn't like elisp enough to stick with it.

Not really better engineering[+], I think, so much as perseverance—Emacs originally had the same character-grid limitation, and has gone through multiple display-engine (etc) rewrites to get to the point it's at now, and the amount of pain involved along the way has been ... considerable. There are still limitations stemming from the original design that are going to require even more pain to remove.

[+] This isn't a diss, mind you—I use Emacs, and love it, and have done a fair bit of Emacs development.

Chrome Packaged Apps are essentially a Chrome extension with some extra features that can run outside a browser instance.

As such, scripting would be limited to languages that can run in JS. So if he allows plugins, it would be JS, CoffeeScript, or possibly Emscripten.

That is what I suspected. Kind of makes the idea of using that sort of system to create generic modern developer tools DOA I think. Definitely so if it means I lose Vim's ! command; I couldn't live without that.

I agree. You can make unitaskers like sprite packer/unpackers image quick editors/resizers and the like but anything comprehensive is going to be hard.

Can the Pyhton API do everything brainfu^Wvimscript can?

Yeah, to my knowledge. Basically it lets you execute Vim commands from python.

Reply on news.ycombinator.com