Hacker News Reader

Comment by krick | Hacker News Reader

I'm not sure how I feel about this. On the one hand I've been thinking on it for quite a long time already, newer shinier Vim is something I secretly wish for. On the other hand I found it quite problematic. The main problem of Vim is Vimscript. So "newer shinier Vim" is Vim with real programming language instead of vimscript. But it's impossible to remove Vimscript: it won't be Vim anymore. It affects not only scripting itself, but also how we interact with it in command mode, not to say about plugins we have already.

And here we have a project. Virtually nothing is done, previous commit was 20 days ago, and the last commit is adding the fundraiser link an hour ago. I mean, the author doesn't seem to be fanatically enthusiastic. And plans are quite generous. Maybe I'm too pessimistic, but I have some bad feeling about that. I'm thinking instead of "Hm, maybe better to write an open-source version of Sublime Text?".

View on HN

I am enthusiastic about it, thats why I started the fundraiser. To finish the first iteration fast I need to put my freelance work to a halt.

> And here we have a project. Virtually nothing is done, previous commit was 20 days ago, and the last commit is adding the fundraiser link an hour ago. I mean, the author doesn't seem to be fanatically enthusiastic.

I understand the skepticism, but the FAQ[1] gives a pretty good explanation for this and shows that this guy has some familiarity with vim and motivation for taking on this project.

[1] https://www.bountysource.com/fundraisers/539-neovim-first-it... (near the bottom)

Of all the reasons to keep Vim, Vimscript is the one I'd least expect to see on a list! The obtuse nature of Vimscript and clunky Ruby/Python interop are, IMHO, a huge wart on an otherwise fantastic editor.

I think the GP acknowledges that Vimscript is awful: "The main problem of vim is Vimscript."

I agree. vim the editor has a good UI: it is fast to work with and makes me productive. Vimscript is bad. I cannot grok how to write complex things and simple things often break too.

The GP is pointing out that Vimscript is essentially the command mode. The two are one and the same. Try switching Vimscript for, say JavaScript, and now you have to either use JavaScript in the command mode (yuck!) or create some bridge between the command mode interpreter and JavaScript (yikers!). So unless we rip out the command mode out of vim, we cannot replace Vimscript.

This is essentially where I'm going with ix. Vim with an awesome haskell-like language underneath whose syntax is optimized for doing powerful stuff in command mode.

A prototype is at https://github.com/jayferd/ixl-prototype

Neo Vi Improved. We suck at naming things :)

Yeah, I have mixed feelings as well. I love my Vim, don't touch it. And yet, vimscript does suck and better separation from core and UI could allow for very interesting things. Also, no one really cares about Vi compatibility anymore and cleaning the scary old C code base could make it much more accessible.

I guess we'll see.

I think it should be called Vimim, Vi Improved Improved

Only after it actually is.

Or Vim for short.

You know: Vim IMproved.

It really should.

"Hm, maybe better to write an open-source version of Sublime Text?" You mean, like Lime?

https://github.com/limetext/lime

Nice, but I would have to know a little more about their philosophy before deciding I'm interested in the project. Their frontpage shows something as closed as Sublime's. "This is what we're doing with this tech, its gonna be great".

There's source code, a BSD license and the README describes their rationale right up front. In light of just the superficial information on github, your comment seems hyperbolic.

My interest in the project is in something with a design similar to Sublime Text that works remotely in an SSH session. There's also some exotica about wrapping Python in a Go process which I find interesting and terrifying.

redcar has been around for a few years, with compatibility with textmate bundles

https://github.com/redcar/redcar

Interesting. I find it a little comic that plist XML files have become the common language for exchanging syntax definitions between editors, due to TextMate.

I wrote a utility to convert these files to/from YAML so it would be friendlier to edit Sublime Text themes; editing naked XML plists was painful for me.

https://gist.github.com/swdunlop/8872387

Oh, I didn't know about that one. Now that seems interesting! Thanks for sharing.

Check out his fork of vim, he has already done a bunch of stuff related to multi threading. I'm guessing this fork only has build system cleanup commits yet.

> But it's impossible to remove Vimscript: it won't be Vim anymore. It affects not only scripting itself, but also how we interact with it in command mode

why do you feel that? vimscript is not the same thing as ex; i agree that any true vim would need to keep strict ex compatibility, but vimscript itself is purely for writing plugins in.

Neovim fully supports vimscript and almost all existing vim plugins.

I think a modular base would mean that VimScript could be entirely replaced with a different kind of scripting language. I for one would love to see Ruby or Python take that spot!

You can already script Vim with those languages.

Vim needs to be built with the support enabled, though.

Python: [1] (more info [2])

Ruby: [3]

[1] http://vimdoc.sourceforge.net/htmldoc/if_pyth.html

[2] http://stackoverflow.com/questions/905020/resources-concerni...

[3] http://vimdoc.sourceforge.net/htmldoc/if_ruby.html

Vim already can be scripted with real programming languages, how did you miss that?

Reply on news.ycombinator.com