top | item 7278214

Neovim

879 points| tarruda | 12 years ago |github.com | reply

362 comments

order
[+] tinco|12 years ago|reply
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|12 years ago|reply

  > ...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).
[+] justinmk|12 years ago|reply
This should not be the top comment, it is a rant that misses the point. Neovim maintains backward compatibility where it makes sense to do so. Neovim is NOT a rewrite, it is a thoughtful refactoring that aims to achieve one of Vim's _original_ goals: first class support for embedding. And better interoperability.
[+] cicero|12 years ago|reply
I don't see anything shameful about using old software if it works well and suits your needs. Yes, new editors like SublimeText have advantages, and if you prefer them over Vim, use them. However, I've seen many projects undergo a rewrite in order to move to new technology, but they never matched the utility of the old technology they were trying to replace. I'm not saying it can't happen, but that it often doesn't.

I don't use Vim much now because I work a lot in Windows, and Vim got me into the habit of hitting escape when I was through entering text, but escape cancels the input in a lot of programs. However, I still use it in the shell or when I need to make certain global edits.

I wish Neovim great success, and I might use it someday if it meets my needs, but not just because it's new technology.

[+] chongli|12 years ago|reply
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.

What?! You can take my vim+bash+tmux+urxvt when you pry it from my cold, dead hands!

[+] gradstudent|12 years ago|reply
> 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.

You're confounding usability with "do not need a manual". They're not the same thing at all. Moreover, I reject entirely your assertion that vim is not usable.

vim is amazingly usable; text manipulation commands for example all follow a common structure: [action][times][position]. That means the rules you learn for using "yank" apply just as well to "delete" or "paste" or whatever. Anytime you encounter a new text command you don't even need to wonder how to use it; it's a sure thing it will follow the same structure that you already know.

[+] chadillac|12 years ago|reply
ring ring ring

"yeah, what's up?"

"Nagios is paging, something with that code you pushed live a couple hours ago is throwing a fit... looks like half the web cluster is on the verge of going to swap, can you look into it? asap!"

"Well, I'm on at the bus stop and won't be near a computer for at least an hour...yeah, I'll sort it out, will text you when we can push fix live."

pulls out Note 3, shitty 3G coverage

connects to VPN

ssh into dev env with connectbot

switches to hackerkeyboard for input mode

screen -dr dev

Ctrl+c, tail join IRC channel that dumps syslogs from production cluster

sees error

Ctrl+c,vim the/file/causing/the/unexpected/problem

fix, :wq

git stash, git pull, git stash apply, git commit, git push

Ctrl+d, exit

sends text message "good to go!"

deal with it.

[+] keerthiko|12 years ago|reply
I am honestly amazed at how feistily every 'hacker' here is defending LaTeX in response to your comment. I agree with you for the most part.

This whole "it's apples to oranges" claim is bullshit. Both Word as well as LaTeX can be used for anything from writing a resume, making a technical paper with a few simple equations, to writing an entire Vector or Linear Algebra textbooks. When you have two options for doing the same task it's very much comparing apples to apples.

Yes, they each were originally built with different objectives and different target markets, but they have since aspired to be usable for all the same things. Of course, they each have their strengths and weaknesses.

But I don't get how do a bunch of folk here feel justified in arguing against someone saying "there's room for improvement" with clear viable suggestions on the details too. I know that hating on MSWord (or MS-anything) is fashionable on HN. But you can't seriously be defending

* the steep learning curve: throw your 14-year-old who's doing a math assignment Word vs your favourite LaTeX editor, see what happens;

* lack of WYSIWYG-like feedback-loops: you have to wait a full minute on decently sized documents to see the result of adding that equation that took you 10 seconds to add;

* syntax holdups: you miss an underscore and your document is broken. All the way through. And can take an hour to fix even if you're skilled. People writing documents that need LaTeX's power aren't always coders, and debugging is not a fun or planned-for activity for anyone.

I also don't for the life of me see why someone has to "be an expert, not just written a couple documents casually in undergrad" to be able to comment on the flaws of a product. They're as much a user as a power user, and obviously the power users went through that stage too. Losing sight of your past difficulties (or being gifted in LaTeX) doesn't make them irrelevant for people not in your current position.

Loosely relevant: I smell hardcore "hacker entitlement" around people using LaTeX and defending it including all its stupid barriers to easy document-creation tooth and nail. Hardcore programmers do this with way too many things (like Linux, and development environments for almost any language). And it's just really frustrating for a lot of people to deal with =/

PS: NeoVim sounds like someone finally got off their high horse (or from whining) and decided to actually make something better. Thanks!

[+] terminus|12 years ago|reply
> 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.)

Let's deconstruct each of the pieces we are supposed to be ashamed about, shall we.

LaTeX the language: a wrapper language built on top of TeX for typesetting documents. The idea being to specify higher level document logic (for instance sections, subsections, paragraphs, tables) and if all else fails, then fallback to explicit placement commands. I fail to see anything to be ashamed of in the idea. And, as for your complaints about extendability in some of the comments below: maybe you should look at the texlive distribution or PGF/tikz here: http://www.texample.net/tikz/)

LaTeX/TeX compiler: that's a fair point. But, doesn't have much to do with the language.

vim: a text editor wrapped around using the keyboard efficiently, similar in idea to LaTeX the language in that it asks you to express yourself on a higher plane. Neovim is essentially a more maintainable repackaging of the same model keeping extendability in mind.

bash: wrapper over the early Unix model pipes, ttys, processes (and not threads) etc. The bash scripting language is not all it could be. But, as I said before, the basic model is fairly tied up with Unix itself and is similar in zsh/fish etc.

[+] fournm|12 years ago|reply
I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim!

The thing about compatibility is that it doesn't matter how great your new and shiny is if it can't talk to old things at all. Imagine the best new text editor in the world, but it's completely incompatible with every file format that's ever been written previously, even .txt! No one would use it, because the cost of switching is too high.

In some cases, it's definitely worthwhile to have some development pain to keep that around. Stuff like keeping vimscript (and therefore the entire ecosystem around vim) functioning means that neovim could be a drop-in for some people, and HAS to be preserved at least partially. Stuff like keeping ancient Amiga support or integration with Sun workshop? Definitely not worth it anymore.

[+] NAFV_P|12 years ago|reply
> 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.

I just looked it up, $70 is way out of my pay range. I'll convert when I have a full-time job.

> 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, you should be ashamed.

[+] grannyg00se|12 years ago|reply
So Sublime text provides a 99% feature loss but a great usability gain?

Can you explain that a bit?

[+] eyko|12 years ago|reply
"I hate the ideas many programmers have about backwards compatibility, unless it affects me." – FTFY

> "There is nothing holy about Unix era software, chances are it's shit and a lot of it should be thrown out."

1. we're still very much in the "Unix era"

2. There's nothing holy about software at all. Rules shouldn't be broken, but rules can be broken.

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

If anything I'd say Vim is converting TextMate/SublimeText left and right. Most SublimeText users are former TextMate, and many new Vim users are former SublimeText users.

> 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

Speak for yourself. I don't personally write LaTeX but I still very much use the shell, and Vim.

[+] krick|12 years ago|reply
Oh, it's a real flamewar and people still seem to be here, so I want to add a little constructiveness to it. Vim, bash, LaTeX. Let's postpone vim, as the whole topic is [supposed to be] about it. And we have enough shells (zsh, fish) instead of bash, many people (me too) tried it and have chosen bash (although I use IPython quite often). And I don't know sane and fully functional alternative to LaTeX. (Markdown and co don't count as they don't have same control on output.)

So let's stick with LaTeX. There are 2 categories of people: those who think that LaTeX is fine for its usecases and those who think that something is wrong and could be done better. Fine is fine, so lets concentrate on the second category. I'll recite main complaints: slowness, horrible syntax, arcane source code, impossibility to divide semantics from representation. (Did I miss something?)

I guess many of us are able to program. So why somebody, right here, right now, wouldn't create a github/bitbucket repo, post link on it and explain, what exactly in your opinion could be done better? I personally would probably participate if somebody has a plan sane and explicit enough.

[+] srik|12 years ago|reply
But I want to write on my text editor on a terminal emulator because I have access to all of the built in operating system utilities.
[+] AliceWonder32|12 years ago|reply
Um, I've never heard of SublimeText. I like vim because it is cake to ssh into a server and quickly / efficiently modify a text file.

And there is nothing shameful about developers accomodating my desire to use a command-line text editor to create/edit TeX files in whatever terminal I am using.

Normally I create / edit TeX using LaTeXila but it is fanstatic that I can do so with vim and when I don't have access to LaTeXila I use vim for TeX editing, and I am quite glad I can.

With software that works in a standard shell environment, I can ssh into a networked computer from my Android tablet (Better Terminal Emulator Pro and Hackers Keyboard) and do actual work. Far more convenient than carrying my laptop everywhere and also faster than checking out source, firing up a GUI, and then committing the source.

Terminals ARE good technology and we would be worse off without them.

[+] Arnor|12 years ago|reply
I can't believe I read this whole thread... I need to go take a shower now...
[+] pjmlp|12 years ago|reply
I fully agree.

For me, Vi and Emacs are only when I don't have an option in terms of IDE support, even though I know at least Emacs quite well.

What can I say, the world of Amiga GUIs, Smalltalk and Lisp environments spoiled me as an IDE fanboy.

It baffles me why in 2014, some developers still prefer to work as if UNIX System V had just been released.

[+] _cipher_|12 years ago|reply
> 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.

I agree. Bash sucks. ;)

[+] krick|12 years ago|reply
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?".

[+] tarruda|12 years ago|reply
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|12 years ago|reply
> 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)

[+] wonderzombie|12 years ago|reply
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.
[+] jneen|12 years ago|reply
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

[+] tambourine_man|12 years ago|reply
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.

[+] jck|12 years ago|reply
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.
[+] zem|12 years ago|reply
> 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.

[+] justinmk|12 years ago|reply
Neovim fully supports vimscript and almost all existing vim plugins.
[+] xutopia|12 years ago|reply
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!
[+] pekk|12 years ago|reply
Vim already can be scripted with real programming languages, how did you miss that?
[+] rjzzleep|12 years ago|reply
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.

[+] dengnan|12 years ago|reply
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.

[+] segphault|12 years ago|reply
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.

[+] bronson|12 years ago|reply
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.

[+] coyotebush|12 years ago|reply
> 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|12 years ago|reply
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...

[+] gnoway|12 years ago|reply
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.

[+] bayesianhorse|12 years ago|reply
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...

[+] jmehman|12 years ago|reply
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?
[+] fournm|12 years ago|reply
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).
[+] speedkills|12 years ago|reply
This reminds me of the now dead 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.

[+] binarygrizzly|12 years ago|reply
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.

[+] limsup|12 years ago|reply
Cool project! It'd be nice if the build system was converted to GYP, so that it integrated well with libuv.