5 ms·

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.

by krick 13y ago

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?".

swdunlop 13y ago
"Hm, maybe better to write an open-source version of Sublime Text?" You mean, like Lime? https://github.com/limetext/lime https://github.com/limetext/lime
- krick 13y ago
  Oh, I didn't know about that one. Now that seems interesting! Thanks for sharing.
- swah 13y ago
  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".
  - swdunlop 13y ago
    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.
- riffraff 13y ago
  redcar has been around for a few years, with compatibility with textmate bundles https://github.com/redcar/redcar https://github.com/redcar/redcar
  - swdunlop 13y ago
    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 https://gist.github.com/swdunlop/8872387
deleted 13y ago
[deleted]
tambourine_man 13y ago
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.
- agscala 13y ago
  I think it should be called Vimim, Vi Improved Improved
  - fiatjaf 13y ago
    It really should.
  - jaredmcateer 13y ago
    Only after it actually is.
  - dredmorbius 13y ago
    Or Vim for short. You know: Vim IMproved.
tarruda 13y ago
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.
BrandonM 13y ago
> 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-iteration https://www.bountysource.com/fundraisers/539-neovim-first-it... (near the bottom)
zem 13y ago
> 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.
jck 13y ago
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.
wonderzombie 13y ago
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.
- IgorPartola 13y ago
  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.
justinmk 13y ago
Neovim fully supports vimscript and almost all existing vim plugins.
xutopia 13y ago
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!
- paddyoloughlin 13y ago
  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 http://vimdoc.sourceforge.net/htmldoc/if_pyth.html [2] http://stackoverflow.com/questions/905020/resources-concerning-python-scripting-in-vim http://stackoverflow.com/questions/905020/resources-concerni... [3] http://vimdoc.sourceforge.net/htmldoc/if_ruby.html http://vimdoc.sourceforge.net/htmldoc/if_ruby.html
jayferd 13y ago
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 https://github.com/jayferd/ixl-prototype
pekk 13y ago
Vim already can be scripted with real programming languages, how did you miss that?

by krick 13y ago

swdunlop 13y ago

"Hm, maybe better to write an open-source version of Sublime Text?" You mean, like Lime? https://github.com/limetext/lime https://github.com/limetext/lime

krick 13y ago
Oh, I didn't know about that one. Now that seems interesting! Thanks for sharing.
swah 13y ago
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".
- swdunlop 13y ago
  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.
riffraff 13y ago
redcar has been around for a few years, with compatibility with textmate bundles https://github.com/redcar/redcar https://github.com/redcar/redcar
- swdunlop 13y ago
  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 https://gist.github.com/swdunlop/8872387

deleted 13y ago

[deleted]

tambourine_man 13y ago

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.

agscala 13y ago
I think it should be called Vimim, Vi Improved Improved
- fiatjaf 13y ago
  It really should.
- jaredmcateer 13y ago
  Only after it actually is.
- dredmorbius 13y ago
  Or Vim for short. You know: Vim IMproved.

tarruda 13y ago

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.

BrandonM 13y ago

> 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-iteration https://www.bountysource.com/fundraisers/539-neovim-first-it... (near the bottom)

zem 13y ago

> 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.

jck 13y ago

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.

wonderzombie 13y ago

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.

IgorPartola 13y ago
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.

justinmk 13y ago

Neovim fully supports vimscript and almost all existing vim plugins.

xutopia 13y ago

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!

paddyoloughlin 13y ago
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 http://vimdoc.sourceforge.net/htmldoc/if_pyth.html [2] http://stackoverflow.com/questions/905020/resources-concerning-python-scripting-in-vim http://stackoverflow.com/questions/905020/resources-concerni... [3] http://vimdoc.sourceforge.net/htmldoc/if_ruby.html http://vimdoc.sourceforge.net/htmldoc/if_ruby.html

jayferd 13y ago

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 https://github.com/jayferd/ixl-prototype

pekk 13y ago

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