
Neovim - tarruda
https://github.com/neovim/neovim
======
tinco
Thanks for trying to do what many of us secretly wished we could do but can't
because of time/skill constraints. I will definitely move to NeoVim the second
it's packaged (is it yet?), regardless if you've changed anything yet.

I hate the ideas many programmers have about backwards compatibility, that
it's more important than development speed and modern concepts. There is
nothing holy about Unix era software, chances are it's shit and a lot of it
should be thrown out.

Look at SublimeText, it's got 1% of the features of Vim, yet it's converting
Vim users left and right, by its sheer usability.

We as developers in the Open Source community should be ashamed people are
still using Vim to write LaTeX in Bash running on terminal emulators. (Yes, it
gives me shivers just thinking about how much each of those technologies sucks
when you think about how good it all could be.)

~~~
glesica

      > ...should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators.
    

First, why? It works just fine. Second, is there anything better? I don't know
of anything I would prefer to use. So until someone comes up with something,
I'll stick to using Vim to write LaTeX in a Bash shell (might upgrade to zsh,
we'll see).

~~~
tinco
No, it doesn't work fine. LateX is slow, inconsistent and needs to be ran
multiple times to give a correct result, it has no API, is not extendable in a
sane way, it's source code is so arcane there's books written about it, and if
you've read the books the only thing you've learned is that trying to
reimplement LateX is a fool's errand. And it's syntax is ugly.

Markdown is better. Microsoft Word is better. They just both lack certain
things we need, and LaTeX has those things.

Could you not envision things could be better?

A LaTeX that parses to an in-memory tree so it could be transformed before
compilation?

A shell that instead of working on character streams worked on structured and
annotated data streams, so it could intelligently interpret what is going on?

An editor that does have at its core an expectation that its output is ASCII
character commands controlling a 1970s terminal interface?

Of course you'll stick to using Vim to write LaTeX in a Bash shell, I do too.
Doesn't mean I'm not mad about it..

~~~
markdennehy
1) You run latex twice only on really large and complex documents like books,
and if you're writing books (not editing, see antipope.org for details) in
Word, then you need professional help.

2) Markdown and LaTeX are designed for different tasks. Next you'll be telling
me that if you have a leafblower, you have no need for a chainsaw.

3) Find me the structured and annotated data streams first - and show me that
the structure and annotations are correct - _then_ lament the lack of a shell
that can route them to the programs that don't interpret stdin and stdout and
stderr that way anyway.

4) I use vim to write latex when I write latex, but "in a bash shell" doesn't
make any sense. You fire up vim from bash, yes, but unless you're trying to do
an ex-style editing session, you're not editing in the shell any more than
you're editing in the kernel or the tty driver...

~~~
skrebbel
You're completely missing the GP's point. Whether or not LaTeX is better than
MS Word for task X is besides the point. It's that LaTeX has many obvious
opportunities for improvement, ways to drag it into the current age, while
keeping all its fundamental strengths. As do many similarly old tools such as
Bash, terminal emulators and Vim.

These improvements aren't all that difficult to imagine, but they don't
happen, because, well, why? GP seems to think an obsession over backwards
compatibility.

~~~
markdennehy
Why expend manpower and energy improving a working solution just to do so when
you have so many other broken things that need fixing first? That's a fairly
self-answering question. There's a reason the expression is "If it's not
broken, don't fix it".

~~~
efuquen
We have tools that have virtually been unchanged for over 20 years. While the
consistency and stability has been nice, there has been a lot of good things
that have happened in software development and technology that those tools
could really benefit from. You're honestly going to tell me you don't think
that taking a second look at these tools and seeing how we could improve them
would be a good thing?

What you're basically advocating is nobody should innovate because things are
"good enough". With that sort of attitude we would never have any progress on
anything.

~~~
markdennehy
That's not what I'm advocating. What I'm advocating is not wasting time and
effort rewriting working tools just because the rewrite would be newer.

Which is _not_ what you're saying I'm advocating.

~~~
Ideka
Nobody thinks it's a good idea to rewrite something just to make it "newer".
The idea is to rewrite (or maybe just refactor) these tools to make them
_better_.

It's also not "fixing what's not broken", but improving something that
could... well... be improved.

------
krick
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
"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)

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

------
bpierre
Thiago de Arruda (the author of Neovim) has also released a Vim fork with
multithreading support (proof of concept):

[https://github.com/tarruda/vim/](https://github.com/tarruda/vim/)

[https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ](https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ)

------
thomc
A brave effort. Given your commit history, documented plan and great idea I
was happy to back it [1] and hope you succeed. Best of luck :)

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

~~~
tarruda
I greatly appreciate it, thanks :)

------
rjzzleep
Thiago if you read this, please do your fundraiser a favor and mention all the
work and review that went into your thread safe message queue already.

There is a lot of skepticism about your capability of delivering, but i think
it's clear that you already have the experience needed.

~~~
Argorak
To make sure that your message does reach him, try to reach out directly.

His contact information is here:

[http://tarruda.github.io/](http://tarruda.github.io/)

------
segphault
As someone who uses Vim to write articles and documentation in addition to
code, I'd really love to see a richer UI with proper support for features like
variable-width fonts.

It looks like the developer behind this refactoring effort has some really
good ideas for decoupling the Vim engine from the user interface layer. It'd
be great if somebody could build a really good cross-platform Qt-based UI on
top.

~~~
tarruda
That actually is planned on the first iteration of the fundraiser, see the FAQ

~~~
segphault
That's really great! After reading the FAQ, I have contributed $100. Best of
luck with the project!

~~~
tarruda
Thanks a lot :)

------
bronson
It sounds like they have no interest in getting this stuff pushed back
upstream? There's no mention of it on the home page.

At this point it smells kind of Emacs/XEmacsish. Hope they can rally immense
development effort.

~~~
ggreer
The author of NeoVim (Thiago de Arruda) tried to add support for multi-
threaded plugins to Vim and has been stymied[1].

I'm not sure how to get a patch merged into Vim. Bram Moolenar is the only
person with commit access, and he's not a fan of most changes beyond bug
fixes. My co-founder and I tried to add setTimeout & setInterval to
vimscript[2]. Even six weeks of full-time effort and bending over backwards
wasn't enough. Eventually we were just ignored.

I've contributed to a lot of open source projects, and the Vim community has
been the most difficult to work with. I've been writing C for almost two
decades, and the Vim codebase is the _worst_ C I've ever seen[3]. The project
is definitely showing its age, and I'd love for something new to replace it.

1\.
[https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIB...](https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIBwNAJ)

2\.
[https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZj...](https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J)

3\. If you value your sanity, do not read eval.c. It is over 25,000 lines and
has over 400 ifdefs. The first ifdef checks for Amiga; the second checks for
VMS:
[https://github.com/b4winckler/macvim/blob/master/src/eval.c](https://github.com/b4winckler/macvim/blob/master/src/eval.c)

~~~
teacup50
Your patches were broken. Now your answer is to fork? Sheesh.

> _The project is definitely showing its age, and I 'd love for something new
> to replace it._

Then start over. Refactoring it will be nigh impossible.

------
coyotebush
> Migrate to a cmake-based build

> Legacy support and compile-time features

> Platform-specific code

Sounds like well-justified cleanup, although it's possible this project is
underestimating the usefulness of feature selection.

> New plugin architecture

> New GUI architecture

Now that's cool and ambitious.

I wonder whether Bram has an opinion on this?

------
bigtunacan
I'm a hardcore Vim user and I just don't see the point of this.

Not only that, but Vim is charity ware and requires the license to be
included. The license is most notably absent from the Neovim fork. Wonder if
that will be added any time soon...

~~~
rthomas6
So I read over the license and you're right, the license does need to be
included. However I don't see anything wrong with the project as long as the
license is included in its distribution. The license doesn't go against
anything Neovim is doing, provided they include the license and provide the
project source.

~~~
bigtunacan
Therein lies the problem; the license is not being included. I find this a bit
concerning since the default in forking a repo would have included it. So this
gives off the impression then that the license was deliberately removed.

Just to make it clear (most people on Hackernews probably already know this,
but for the sake of anyone that doesn’t), it would look like this.

hg clone [https://vim.googlecode.com/hg/](https://vim.googlecode.com/hg/)
neovim

cd ./neovim

git init && git add . && git commit -m “First commit”

git remote add origin
[https://github.com/neovim/neovim.git](https://github.com/neovim/neovim.git)

git push -u origin master

There you have it; an exact fork from Mercurial push out to neovim on github,
everything included. Getting those license files out of there took some manual
steps somewhere in between lines 1 and 3.

~~~
lucian1900
I think it's likely that the license was accidentally removed as part of
cleaning up the build system.

------
gnoway
Let me just say that I recently had to build a 'new' UnixWare 7.1.0 system. I
was stunned and delighted that I was able to compile vim 7.4 + then-current
patches.

Couldn't compile git, python or a couple of other things I wanted, but at
least I could use a reasonable editor.

~~~
oblio
That's awesome in a way. But this being Open Source you can just download the
sources for Vim 7.4 in the future and use it on UnixWare 7.1.0.

While the rest of us (and maybe you, yourself) on Ubuntu 15.10 can use Neovim
with all the cruft taken out.

------
dengnan
Finally, someone took this step. I really appreciate his work.

Don't get me wrong. Vim is an awesome editor and it is the only editor I'm
using now. I've been using it for decades and still cannot find an editor
which can replace it. Sorry, emacs, I tried several times but failed. I know
it's my problem but I'm too familiar with vim's short-cuts.

However, I do think we can still do some improvement on vim, especially on its
plugin systems. If you wrote plugins for vim, you know what I'm talking about.
For example, can you quickly tell me the differences between map nnoremap
nnoremap? How to write comment in vimscript?

To me, vimscript seems like a language patched by lots of authors with
inconsistent goals. It's not as cohesive as Emacs Lisp. And there are lots of
historical reasons why they do that --- I know, it's backward compatibility.
But you have to move forward at some time.

With that being said, I do think it is necessary to have an editor which keeps
the good parts in vim and improve it by not considering too much about
backward compatibility. I'm so glad that someone did it for us.

~~~
dredmorbius
There's viper mode.

Though, aside from a brief dalliance with emacs in the late 1990s, I've used
vi / vim since 1987.

~~~
rrradical
I tried Evil, which was supposedly better than Viper, and it got me 90% of the
way to vim. But that last 10% kept me from staying (and also that emacs has
way more typing/command lag than vim).

------
reirob
For those searching a combination between VI, Emacs and Haskell:
[https://github.com/yi-editor/yi](https://github.com/yi-editor/yi)

------
bayesianhorse
I actually had hoped "Neovim" would be a modern reimagining of a modal
Texteditor for the modern time, along one of two paths.

Path 1: An html5+javascript based modal editor where buffers are actually DOM
trees, enabling both code and other data to be rendered/edited, and also
offering much richer visual enhancements. Javascript is already a great way
for enabling a rich plugin ecosystem.

Path 2: Modal Textediting suited for mobile devices. For example based on
python+kivy, or even C with SDL, it would be aimed to be portable and to
extend the modal interface to touch-based gestures and speech recognition.
Akin to "verbal vim", entering vim-like commands with touch or voice gestures,
text editing on mobile devices like tablets would immediately suck a lot
less...

~~~
standardfoil
Can't tell if you are actually serious about the above or not, especially path
1.

~~~
haberman
I personally think path 1 is _absolutely_ where editors should be going.
Upvote from me.

NeoVim is a step in the right direction, but not far enough. The future is a
more Light Table like environment
([http://www.lighttable.com/](http://www.lighttable.com/)). But Light Table
(as visionary as I think its UI is) is written (and extended, AFAIK) in
ClojureScript, a LISP-like language that nobody knows.

It it was written and could be extended in JavaScript instead, and configured
to the extent that I could write VIM-like modal editor support for it, I might
finally be able to give up VIM after 20 years for something better.

~~~
Foxboron
Getting a little ahead of ourselfs maybe?

"Nobody knows", lets just compare IRC. #javascript on freenode got 951 users.
#clojure on freenode got 651 users. Even tho its not a good comparison, saying
"nobody" knows clojure is very far fetched. It has a ever growing community,
with several books published, and the whole point on Chris choosing Clojure
shows enough of its maturity.

~~~
haberman
Search Amazon.com books:

ClojureScript: 10 results (only one of these actually has ClojureScript in the
title)

Clojure: 89 results

JavaScript: 5,787 results

Sorry, there is no comparison.

I'm not saying Clojure sucks, I am just saying that it's not mainstream.
ClojureScript even less so -- it's an offshoot of Clojure which was designed
around the JVM, not browsers.

~~~
Foxboron
"I'm not saying Clojure sucks, I am just saying that it's not mainstream.", to
be frank, thats not what you said; "... ClojureScript, a LISP-like language
that nobody knows.".

Saying its not mainstream is no problem, but it tells you nothing about the
quality of the language. What i do find problematic is that you are changing
your argumentation from one comment too another. Clojure is a lang several
people know, judgeing by books is a poor comparison as we can limit too the
past year and compare and the difference would not be as stark, as you try to
present it. Clojure also got 80 (?) books published in less then 2-3 years
since its its rather quick breakthrough. There is no need to even try and
claim "nobody" knows clojure, or "it's not mainstream".

------
jmehman
I really like what he's setting out to do here but I was a bit put off by the
fundraising setup. If the target isn't met the donations still go to him, and
there's no pledge to do anything on that case. Is that right or did I miss
something?

~~~
ibash
On the other hand the fundraiser is now over $8,000 which is enough for at
least a month of work, I think it'll make the 10k in short order.

------
fournm
Ambitious. Best of luck to them--I've considered trying to do a full port to a
language like Go or Rust, but I've never quite had the time (or self-hatred to
try and handle quite so many corner cases as what I've seen in vim's code).

------
dviola
Bram Moolenaar response to Neovim:

[https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...](https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8)

------
snarfy
Good luck! This is a tough problem. Many have tried, and they all failed.

[http://www.freehackers.org/VimIntegration](http://www.freehackers.org/VimIntegration)

------
speedkills
This reminds me of the now dead
[https://github.com/chrizel/Yzis](https://github.com/chrizel/Yzis)

Even though it has been tried a few times before and never seems to catch on I
really like the idea and would be down to help except I haven't coded C in 15
years and don't really have any desire to go back. I wonder if there are parts
I could help with in newer languages. It's always fun to pick up a project to
learn a new language.

~~~
mercurial
The big difference here is that it's based on refactoring the existing
codebase. While not the most glamorous job in the world, it's more realistic
than attempting to recreate the product of 22 years of development starting
from scratch.

------
binarygrizzly
I applaud your effort but I worry that this step is not far enough to make a
better version of vim. However I really think that we can do better and the
famous, great editors (vim, emacs, acme, etc.) all have different features
that make them great and unique. I prefer vim because of its modal nature
which might be the reason why I find it also ergonomically superior (after
remapping ESC to jf) - e.g. I don't like it to stretch my fingers.

On the other hand I never really script vim as I find vimscript just terrible.
This is far better in emacs as it uses a decent programming language.

The third aspect I think is not well-designed is window/buffer-managment. In
my opinion this point could be outsourced or developed in connection with a
tiling WM or terminal multiplexer like tmux/screen (this part is best in
acme).

A modern approach I thought about (Yet Another Text Editor Syndrome) would be
a client-server architecture with a server node storing buffers with context
information (filename, cursor, etc.) to which clients can connect. A client
node could be on one hand a viewer (terminal or gui based) doing fancy thing
like syntax-hightlighting, cursor control, searching and on the other a REPL
(in any language) that just has to implement the bridge to a defined message
protocol.

~~~
unfamiliar
Lime text fits this description I think.

------
limsup
Cool project! It'd be nice if the build system was converted to GYP, so that
it integrated well with libuv.

------
euoia
I think this is a great project. The author appears to be extremely competent.
I pledged $20.

------
lsiebert
I think there are features (which the ability to embed a vim engine may
enable) that would make it easier to improve one's usage of vim.

Real time analysis of actions, with suggestions for better ways to do what you
just did. Long term analysis of actions, to see what are the biggest time
wasters (ie, you often do a certain command that requires typing, maybe it
might be better to make a function mapped to a leader based command. Or you
tend to copy things with a range that you could have copied using a text
object.

And that is what interests me about this. I really hope that separating GUI
from the core and the exposure of streams will allow you to put an analysis
engine between streams.

------
sandGorgon
kickstarter this please. I (and so many others I guess) would love to support
this.

I'm worried that a lot of good projects die off because everyone have mouths
to feed. I suspect that I have spent a large part of my adult life using vim,
so I want to make sure a good successor comes through.

Take a look at LightTable - which was quite successful [1] in raising and
delivering what it promised.

[1] [https://www.kickstarter.com/projects/ibdknox/light-
table](https://www.kickstarter.com/projects/ibdknox/light-table)

~~~
tiziano88
Have you seen this: [https://www.bountysource.com/fundraisers/539-neovim-
first-it...](https://www.bountysource.com/fundraisers/539-neovim-first-
iteration) ?

------
speedkills
The more I think about this, the more I like it. I badly want my vim to be
multi-threaded and a separate engine, especially one that had a queue based
pub/sub type interface could really open up some cool possibilities. At that
point if you could give it the ability to use operational transform for the
changes it would make remote editing, as well as remote pairing work really
well. I know floobits is doing something similar but I would have to think
this would make that much easier to pull off.

------
lscritch
But what about the children in Uganda?

------
mekoka
I would love to have Bram Moolenaar's input on this project.

~~~
dviola
I've just sent an email to the vim_dev@googlegroups.com mailing list. I asked
his opinion on the Neovim project.

The subject for my email is "Neovim", so let's wait and see what his opinion
is.

~~~
dviola
[https://groups.google.com/forum/#!topic/vim_dev/x0BF9Y0Uby8](https://groups.google.com/forum/#!topic/vim_dev/x0BF9Y0Uby8)

------
bowerbird
300 comments in 24 hours.

nothing better than people word-fighting about writing tools...

-bowerbird

~~~
gdiocarez
Right, haha, like comparing tool that does the same thing and just justifying
or proving that this one is better -_-

~~~
chris_wot
Wait till you see what happens when someone comes up with neoemacs.

------
skrewler
First off, what happens if you don't meet the funding goal, do we get our
money back?

I think a big reason for Vims popularity is how ubiquitous it is. It's
installed by default on most *nix operating systems. Even if I'm not
privileged on a system, I can still pull down my dotfiles and have my familiar
vim editing experience.

If I understand correctly, plugins written for Vim would be compatible with
Neovim, but not vice versa?

------
dbbolton
As far as I'm concerned, just moving a vim clone to git is a huge improvement.

Ever tried building vim from the ports tree on a <1GHz machine? Painful.

------
jamesjporter
I wish someone would try this again for Emacs :(

------
ilaksh
If anyone is looking for alternative to vim then check out Textadept which has
a curses UI version and a graphical UI version.

------
SmileyKeith
I think one of the most important things about this is the last bullet point.
"Development on Github." I occasionally look at the vim-dev mailing list and I
see people attaching patch files to conversations. I think Github's
collaborative development workflow could help the barrier of entry to updates
a lot.

------
mynameisfiber
Any worry about latency with this new plugin architecture? I'm not quite sure
how the current plugins communicate with the main process, but I am sure that
one of the things I would most like to see in a re-write of vim is a more
responsive interface, even if I have a handful of plugins running.

~~~
ggreer
If anything, the NeoVim will be much more responsive. Vim's current plugin
architecture is simple: when plugin code is running, the UI is blocked. If
your plugin has an infinite loop, Vim hangs forever. If your plugin does
network I/O, Vim hangs until the socket read/write is finished. The only work-
around is to use non-blocking sockets and abuse CursorHold/CursorHoldI
autocommands and updatetime. That trick breaks the leaderkey, which is a show-
stopper for many users. There are similar problems with syntax highlighting.
Vim has its own (extremely inefficient) regex engine that blocks the UI when
matching.

~~~
rquirk
The regex engine was updated in version 7.4 and now is noticeably faster.

~~~
ggreer
There's plenty of room for improvement. For example: if you run the same regex
many times in a row, Vim rebuilds the DFA on each run. A cache of recently-
used DFAs would avoid tons of wasted computation. Also, Vim doesn't free many
regex-related data structures until you close the buffer they were invoked on.
I had to work-around that bug when writing a plugin, since it caused Vim to
use gigabytes of memory.

The best solution would probably be to switch to PCRE. Some Vim-specific
stuff[1] would have to be special-cased, but Vim could get an order of
magnitude speedup (and fix quite a few bugs) by using a modern, optimized,
well-tested regex library.

1\. Vim abuses regexes like nothing I've ever seen. You can even match line
and column numbers with the regex engine:
[http://vimdoc.sourceforge.net/htmldoc/pattern.html#/\%l](http://vimdoc.sourceforge.net/htmldoc/pattern.html#/\\%l)

------
laichzeit0
If you can make Vim seamlessly work with a REPL then this would be worth me
upgrading (if all my current vim plugins still work).

It's the only reason I use Emacs + Evil + trying to get it to be as close to a
Vim clone as possible. You know how cool it is to type ":" instead of M-x?

~~~
leephillips
"If you can make Vim seamlessly work with a REPL"

Have you tried the ScreenSend vim plugin? I use it for Python and Clojure, and
occasionally other REPLized languages.

------
dviola
Bram Moolenaar just gave his opinion on Neovim. See here for his answer:

[https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...](https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8)

------
ribs
I'm not sure about libuv. Isn't that primarily for async I/O? This is a
desktop application. Async I/O isn't going to significantly affect
performance. And it doesn't make shit any simpler.

~~~
tarruda
libuv will be used mostly because it acts as a platform layer for many common
system functions.

------
arjie
First-class support for embedding wins a pledge from me. I wish you the best.

------
jdc2172
if this ever gets off the ground there should be a complete spec sheet for the
plugin commands so anyone can write their own vim core that interfaces with
other guis and plugins designed for the original vim

------
ingend88
Get this story and many more in top5HN Newsletter. Signup at
[http://top5hn.launchrock.co](http://top5hn.launchrock.co)

------
CountHackulus
Sounds nice, though I hope they keep support for more esoteric platforms. My
only real choices on z/OS are vim, emacs, and the ISPF environment.

------
jdc2172
the improvements to the plguin system sound awesome - hopefully it remove the
need to do virtually anything in vimscript...

~~~
tarruda
Yes, anyone will be able to extend vim without knowing vimscript exists.

------
stewbrew
Good to hear that vim development takes on some speed again. Please keep
compatibility with existing vim plugins.

------
wprl
I wish them the best of luck.

Vim is already an IDE.

------
izietto
$10000 seems to me a great amount for having this!

------
toblender
Long Live Vim!

------
gdiocarez
Vim is already awesome as it is.

------
dschiptsov
Sometimes people would like to have just a as-small-as-possible "classic" vi
(like nvi, or vi included in FreeBSD) to just quickly run through bunch of
config files in a [remote] terminal. So, vim-minimal works well for us.

I am not sure that libuv is what we need, and it seems like another "monster"
to be born, like "modern" Emacs (which is "aware of" such a crap like
gconfig).

    
    
      schiptsov@MSI-U270:~$ ldd /usr/local/bin/emacs |wc -l
      85
    

"Do not want" meme.)

------
celebril
It seems the trolls have arrived.

[https://github.com/neovim/neovim/pull/52](https://github.com/neovim/neovim/pull/52)

