23 ms·

Neovim

879 points by tarruda 13y ago

segphault 13y ago
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 13y ago
  That actually is planned on the first iteration of the fundraiser, see the FAQ
  - segphault 13y ago
    That's really great! After reading the FAQ, I have contributed $100. Best of luck with the project!
    - tarruda 13y ago
      Thanks a lot :)
  - jnbiche 13y ago
    Is there some way to donate via Bitcoin?
    - ben0x539 13y ago
      And via EVE Online isk?
      - jnbiche 13y ago
        Yeah, when it has a 10 Billion USD market cap, is accepted by Fortune 500 companies and leading Internet sites, and is celebrated by successful venture capitalists like Fred Wilson and HN's founder, get back to me. (And you'll probably retort with the failure of an exchange that almost everyone in the Bitcoin community has been hoping would fail for the past 3 years). But seriously, I'm pretty sure that you can exchange Eve online currency for Bitcoin, so I'd sure take it as a donation if someone offered.
- keithpeter 13y ago
  "I'd really love to see a richer UI with proper support for features like variable-width fonts." Would the variable-width fonts be simply for display with plain text being edited and buffered, or do you wish to be able to have rich text formatting within the editor (e.g. italic, bold, smart quote marks &c)? Just interested: rich text formatting has been suggested for emacs I recollect.
  - ics 13y ago
    By none other than rms himself.[0] [0]: https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00...
  - segphault 13y ago
    For display purposes, yes. I want better text readability when I'm working on an article. A nice variable-width font, more line spacing, etc. I want my Vim buffer to look as good and be as comfortable to read as a native text editor like Byword. For formatting, I mostly use Markdown. Ideally, I'd like to see the literal markdown for the paragraph under the cursor, but formatted text for the rest of the buffer. There's actually a script with a pretty good first pass at achieving that kind of Markdown support via Vim's "conceal" feature, but some of Vim's inherent limitations make it imperfect: https://github.com/tpope/vim-markdown/pull/9 https://github.com/tpope/vim-markdown/pull/9 I'm hoping that the way neovim decouples the UI layer from the underlying editing engine will make it easier to address issues of that nature.
    - keithpeter 13y ago
      I can see what you mean, although the flicking between markup and formatted text as you moved the cursor would annoy the hell out of me I think. Now, would the cursor be a block over a character or a caret between characters? A lot of history riding on that one. Jef Raskin's Canon Cat springs to mind with its in-place commands (but not Vim's modefulness).
limsup 13y ago
Cool project! It'd be nice if the build system was converted to GYP, so that it integrated well with libuv.
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.
bronson 13y ago
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.
- tarruda 13y ago
  As the author I would like to contribute changes back, search vim_dev mailing list for 'message loop' and 'job control' and you will find two patches I've sent that werent even commented by Bram. This fork changes so much that its impossible that it will ever be accepted
  - nfm 13y ago
    Maybe we can hope for an MRI/YARV scenario!
  - bronson 13y ago
    I TOTALLY hear that. Maybe an GCC/EGCS, eglibc/glibc, or (as nfm points out) Yarv/MRI scenario could work. First prove your mettle (will take donkey's years), then upstream can jump to your stable code base in one glorious commit. Hope you can mention in the readme that upstreaming is not a goal... It might be hard to get the wording right but it would have made my first impression quite a bit less skeptical. :)
- patrickdavey 13y ago
  Yes, I was surprised by this, and no mention of the project on vim.org ...
- thetxef 13y ago
  the author has posted at least two different patches to vim dev google group. I dont think Bram even commented in any of them. Many others did.
- kansface 13y ago
  Bram shows no interest in these sorts of things. Frequently, devs post to the vim mailing with a month or two of work on some new feature with no comment from the BDFL.
thomc 13y ago
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-iteration https://www.bountysource.com/fundraisers/539-neovim-first-it...
- tarruda 13y ago
  I greatly appreciate it, thanks :)
coyotebush 13y ago
> 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?
toblender 13y ago
Long Live Vim!
fournm 13y ago
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).
CountHackulus 13y ago
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.
deleted 13y ago
[deleted]
bpierre 13y ago
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
bigtunacan 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      I think it's likely that the license was accidentally removed as part of cleaning up the build system.
- tarruda 13y ago
  The license removal was completely accidental, I will include it as soon as I get back to it.
izietto 13y ago
$10000 seems to me a great amount for having this!
tinco 13y ago
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.)
- fournm 13y ago
  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.
  - tinco 13y ago
    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! This is the part where people are surprised, but I am an extremist. I definitely think backwards compatibility should be among the lowest priorities when making decisions on improving software, especially and perhaps just, in Open Source. Just think about it. What happens when we decide a certain core feature of Vim is archaeic, and could be implemented in a more modern, more flexible, more loosely coupled way. First, every vim plugin would break. But if you look at how many Vim plugins are actually used, I would be surprised if the top 100 Vim plugins covered less than 99.99% of all Vim users. That means we only have to upgrade 100 Vim plugins, and probably just a couple of lines if they're written well. How much technical debt have we accrued now, that in reality could be paid off just by biting the bullet and going through a hundred pieces of software and changing a couple of lines? This is open source, we could just do it. (tm)
ilaksh 13y ago
If anyone is looking for alternative to vim then check out Textadept which has a curses UI version and a graphical UI version.
bayesianhorse 13y ago
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...
- deleted 13y ago
  [deleted]
- standardfoil 13y ago
  Can't tell if you are actually serious about the above or not, especially path 1.
  - bayesianhorse 13y ago
    Even if it sounds like sacrilege to some, I am putting it out there for comment. Both ideas arose from the dissatisfaction with text editing, one in the browser, and the other in the mobile space where currently almost nobody uses a text editor. Especially the "modal html5 editor" would be useful across a variety of websites, either built into the site or the browser itself. For example it would be nice to have plugins that work about the same in IPython notebook, Chrome/Firefox Devtools, Udacity, latex-as-a-service, web-based admin tools, webmail etc. That being said I am not convinced these projects are worth investing time in. They are on my mind though.
    - jamesgeck0 13y ago
      Path 2 is actually something you could do with neovim. The editor's core and it's UI would be decoupled, so you could put whatever UI you wanted to build on top of it relatively easily.
euoia 13y ago
I think this is a great project. The author appears to be extremely competent. I pledged $20.
jdc2172 13y ago
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
jdc2172 13y ago
the improvements to the plguin system sound awesome - hopefully it remove the need to do virtually anything in vimscript...
- tarruda 13y ago
  Yes, anyone will be able to extend vim without knowing vimscript exists.
jmehman 13y ago
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 13y ago
  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.
deleted 13y ago
[deleted]
dbbolton 13y ago
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.
arjie 13y ago
First-class support for embedding wins a pledge from me. I wish you the best.
reirob 13y ago
For those searching a combination between VI, Emacs and Haskell: https://github.com/yi-editor/yi https://github.com/yi-editor/yi
mynameisfiber 13y ago
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 13y ago
  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 13y ago
    The regex engine was updated in version 7.4 and now is noticeably faster.
    - ggreer 13y ago
      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
rjzzleep 13y ago
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 13y ago
  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/
gnoway 13y ago
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 13y ago
  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.
jamesjporter 13y ago
I wish someone would try this again for Emacs :(
SmileyKeith 13y ago
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.
- deleted 13y ago
  [deleted]
ribs 13y ago
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 13y ago
  libuv will be used mostly because it acts as a platform layer for many common system functions.
binarygrizzly 13y ago
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 13y ago
  Lime text fits this description I think.
mekoka 13y ago
I would love to have Bram Moolenaar's input on this project.
- dviola 13y ago
  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 13y ago
    https://groups.google.com/forum/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/#!topic/vim_dev/x0BF9Y0Uby8
skrewler 13y ago
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?
wprl 13y ago
I wish them the best of luck. Vim is already an IDE.
dengnan 13y ago
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 13y ago
  There's viper mode. Though, aside from a brief dalliance with emacs in the late 1990s, I've used vi / vim since 1987.
  - rrradical 13y ago
    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).
speedkills 13y ago
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 13y ago
  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.
speedkills 13y ago
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.
sandGorgon 13y ago
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 13y ago
  Have you seen this: https://www.bountysource.com/fundraisers/539-neovim-first-iteration https://www.bountysource.com/fundraisers/539-neovim-first-it... ?
laichzeit0 13y ago
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 13y ago
  "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.
stewbrew 13y ago
Good to hear that vim development takes on some speed again. Please keep compatibility with existing vim plugins.
dschiptsov 13y ago
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.)
lscritch 13y ago
But what about the children in Uganda?
snarfy 13y ago
Good luck! This is a tough problem. Many have tried, and they all failed. http://www.freehackers.org/VimIntegration http://www.freehackers.org/VimIntegration
bowerbird 13y ago
300 comments in 24 hours. nothing better than people word-fighting about writing tools... -bowerbird
- gdiocarez 13y ago
  Right, haha, like comparing tool that does the same thing and just justifying or proving that this one is better -_-
  - chris_wot 13y ago
    Wait till you see what happens when someone comes up with neoemacs.
celebril 13y ago
It seems the trolls have arrived. https://github.com/neovim/neovim/pull/52 https://github.com/neovim/neovim/pull/52
lsiebert 13y ago
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.
ingend88 13y ago
Get this story and many more in top5HN Newsletter. Signup at http://top5hn.launchrock.co http://top5hn.launchrock.co
gdiocarez 13y ago
Vim is already awesome as it is.
dviola 13y ago
Bram Moolenaar just gave his opinion on Neovim. See here for his answer: https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...
dviola 13y ago
Bram Moolenaar response to Neovim: https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

879 points by tarruda 13y ago

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 13y ago
That actually is planned on the first iteration of the fundraiser, see the FAQ
- segphault 13y ago
  That's really great! After reading the FAQ, I have contributed $100. Best of luck with the project!
  - tarruda 13y ago
    Thanks a lot :)
- jnbiche 13y ago
  Is there some way to donate via Bitcoin?
  - ben0x539 13y ago
    And via EVE Online isk?
    - jnbiche 13y ago
      Yeah, when it has a 10 Billion USD market cap, is accepted by Fortune 500 companies and leading Internet sites, and is celebrated by successful venture capitalists like Fred Wilson and HN's founder, get back to me. (And you'll probably retort with the failure of an exchange that almost everyone in the Bitcoin community has been hoping would fail for the past 3 years). But seriously, I'm pretty sure that you can exchange Eve online currency for Bitcoin, so I'd sure take it as a donation if someone offered.
keithpeter 13y ago
"I'd really love to see a richer UI with proper support for features like variable-width fonts." Would the variable-width fonts be simply for display with plain text being edited and buffered, or do you wish to be able to have rich text formatting within the editor (e.g. italic, bold, smart quote marks &c)? Just interested: rich text formatting has been suggested for emacs I recollect.
- ics 13y ago
  By none other than rms himself.[0] [0]: https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00...
- segphault 13y ago
  For display purposes, yes. I want better text readability when I'm working on an article. A nice variable-width font, more line spacing, etc. I want my Vim buffer to look as good and be as comfortable to read as a native text editor like Byword. For formatting, I mostly use Markdown. Ideally, I'd like to see the literal markdown for the paragraph under the cursor, but formatted text for the rest of the buffer. There's actually a script with a pretty good first pass at achieving that kind of Markdown support via Vim's "conceal" feature, but some of Vim's inherent limitations make it imperfect: https://github.com/tpope/vim-markdown/pull/9 https://github.com/tpope/vim-markdown/pull/9 I'm hoping that the way neovim decouples the UI layer from the underlying editing engine will make it easier to address issues of that nature.
  - keithpeter 13y ago
    I can see what you mean, although the flicking between markup and formatted text as you moved the cursor would annoy the hell out of me I think. Now, would the cursor be a block over a character or a caret between characters? A lot of history riding on that one. Jef Raskin's Canon Cat springs to mind with its in-place commands (but not Vim's modefulness).

limsup 13y ago

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

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.

bronson 13y ago

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.

tarruda 13y ago
As the author I would like to contribute changes back, search vim_dev mailing list for 'message loop' and 'job control' and you will find two patches I've sent that werent even commented by Bram. This fork changes so much that its impossible that it will ever be accepted
- nfm 13y ago
  Maybe we can hope for an MRI/YARV scenario!
- bronson 13y ago
  I TOTALLY hear that. Maybe an GCC/EGCS, eglibc/glibc, or (as nfm points out) Yarv/MRI scenario could work. First prove your mettle (will take donkey's years), then upstream can jump to your stable code base in one glorious commit. Hope you can mention in the readme that upstreaming is not a goal... It might be hard to get the wording right but it would have made my first impression quite a bit less skeptical. :)
patrickdavey 13y ago
Yes, I was surprised by this, and no mention of the project on vim.org ...
thetxef 13y ago
the author has posted at least two different patches to vim dev google group. I dont think Bram even commented in any of them. Many others did.
kansface 13y ago
Bram shows no interest in these sorts of things. Frequently, devs post to the vim mailing with a month or two of work on some new feature with no comment from the BDFL.

thomc 13y ago

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

tarruda 13y ago
I greatly appreciate it, thanks :)

coyotebush 13y ago

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

toblender 13y ago

Long Live Vim!

fournm 13y ago

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

CountHackulus 13y ago

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.

deleted 13y ago

[deleted]

bpierre 13y ago

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

bigtunacan 13y ago

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 13y ago
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 13y ago
  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 13y ago
    I think it's likely that the license was accidentally removed as part of cleaning up the build system.
tarruda 13y ago
The license removal was completely accidental, I will include it as soon as I get back to it.

izietto 13y ago

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

tinco 13y ago

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

fournm 13y ago
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.
- tinco 13y ago
  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! This is the part where people are surprised, but I am an extremist. I definitely think backwards compatibility should be among the lowest priorities when making decisions on improving software, especially and perhaps just, in Open Source. Just think about it. What happens when we decide a certain core feature of Vim is archaeic, and could be implemented in a more modern, more flexible, more loosely coupled way. First, every vim plugin would break. But if you look at how many Vim plugins are actually used, I would be surprised if the top 100 Vim plugins covered less than 99.99% of all Vim users. That means we only have to upgrade 100 Vim plugins, and probably just a couple of lines if they're written well. How much technical debt have we accrued now, that in reality could be paid off just by biting the bullet and going through a hundred pieces of software and changing a couple of lines? This is open source, we could just do it. (tm)

ilaksh 13y ago

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

bayesianhorse 13y ago

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

deleted 13y ago
[deleted]
standardfoil 13y ago
Can't tell if you are actually serious about the above or not, especially path 1.
- bayesianhorse 13y ago
  Even if it sounds like sacrilege to some, I am putting it out there for comment. Both ideas arose from the dissatisfaction with text editing, one in the browser, and the other in the mobile space where currently almost nobody uses a text editor. Especially the "modal html5 editor" would be useful across a variety of websites, either built into the site or the browser itself. For example it would be nice to have plugins that work about the same in IPython notebook, Chrome/Firefox Devtools, Udacity, latex-as-a-service, web-based admin tools, webmail etc. That being said I am not convinced these projects are worth investing time in. They are on my mind though.
  - jamesgeck0 13y ago
    Path 2 is actually something you could do with neovim. The editor's core and it's UI would be decoupled, so you could put whatever UI you wanted to build on top of it relatively easily.

euoia 13y ago

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

jdc2172 13y ago

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

jdc2172 13y ago

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

tarruda 13y ago
Yes, anyone will be able to extend vim without knowing vimscript exists.

jmehman 13y ago

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

deleted 13y ago

[deleted]

dbbolton 13y ago

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.

arjie 13y ago

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

reirob 13y ago

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

mynameisfiber 13y ago

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 13y ago
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 13y ago
  The regex engine was updated in version 7.4 and now is noticeably faster.
  - ggreer 13y ago
    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

rjzzleep 13y ago

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 13y ago
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/

gnoway 13y ago

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

jamesjporter 13y ago

I wish someone would try this again for Emacs :(

SmileyKeith 13y ago

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.

deleted 13y ago
[deleted]

ribs 13y ago

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 13y ago
libuv will be used mostly because it acts as a platform layer for many common system functions.

binarygrizzly 13y ago

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 13y ago
Lime text fits this description I think.

mekoka 13y ago

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

dviola 13y ago
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 13y ago
  https://groups.google.com/forum/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/#!topic/vim_dev/x0BF9Y0Uby8

skrewler 13y ago

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?

wprl 13y ago

I wish them the best of luck. Vim is already an IDE.

dengnan 13y ago

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 13y ago
There's viper mode. Though, aside from a brief dalliance with emacs in the late 1990s, I've used vi / vim since 1987.
- rrradical 13y ago
  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).

speedkills 13y ago

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

speedkills 13y ago

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.

sandGorgon 13y ago

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 13y ago
Have you seen this: https://www.bountysource.com/fundraisers/539-neovim-first-iteration https://www.bountysource.com/fundraisers/539-neovim-first-it... ?

laichzeit0 13y ago

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

stewbrew 13y ago

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

dschiptsov 13y ago

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

lscritch 13y ago

But what about the children in Uganda?

snarfy 13y ago

Good luck! This is a tough problem. Many have tried, and they all failed. http://www.freehackers.org/VimIntegration http://www.freehackers.org/VimIntegration

bowerbird 13y ago

300 comments in 24 hours. nothing better than people word-fighting about writing tools... -bowerbird

gdiocarez 13y ago
Right, haha, like comparing tool that does the same thing and just justifying or proving that this one is better -_-
- chris_wot 13y ago
  Wait till you see what happens when someone comes up with neoemacs.

celebril 13y ago

It seems the trolls have arrived. https://github.com/neovim/neovim/pull/52 https://github.com/neovim/neovim/pull/52

lsiebert 13y ago

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.

ingend88 13y ago

Get this story and many more in top5HN Newsletter. Signup at http://top5hn.launchrock.co http://top5hn.launchrock.co

gdiocarez 13y ago

Vim is already awesome as it is.

dviola 13y ago

Bram Moolenaar just gave his opinion on Neovim. See here for his answer: https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

dviola 13y ago

Bram Moolenaar response to Neovim: https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...