vim gets rewritten ?

neovim

In which way does Vim also suck?

You all know it: I love Vim. If you look at my github page (github.com/MarcWeber) you'll undersand that. Because I do love Vim I also have to worry about its future and at least list some issues I've been faced with in the past. Some could be fixed easily, others are much harder

What sucks?

• plugin system: vim.sf.net is old, authors have to write 3 introductions: Onefor vim.sf.net, one for README.md (due to github) and one in doc/*
• Vim is written in C, and C sucks (Yes, you may think differently. But its afact that other programming languages prevent some errors and are more productive). See language-pro-cons.
• VimL is limited, and Vim only. in-which-way-does-viml-suck
• Python/Ruby/... support lacks. Eg you can't abort python ruby scripts byctrl-c the way you can abort VimL.
• missing async support. There are many many hacks (See vim-addon-async'sdocumentation). Eg Vim is very bad at this simple task: Have a look at the first 5 grep results while grep is still running.
• zero bytes are not supported. If you need them (eg for PHP xdebug integration)you have to find hacky "workarounds".
• Even "text editors" only need features like "snippets" and the like today.At the core you need "file handling tools". And there is no standard way This leads to insane code bloat such as in many ways VAM implementing rm -fr and introducing its own "run external command" abstraction and such.
• The sign api is broken by design, because two different plugins can have signnumber collisions by accident. A possible work around is to use a plugin such as vim-addon-signs
• :compiler is not perfect, eg if you use a ruby build system to build ahaskell application you want to have both error formats vim-addon-errorformats tries to allow this
• The dev cycle of Vim could be improved (patches only, no branches, itsunclear which patches get accepted for what reason, ...) Eg Silex has been waiting for 2 years to get a patch merged. His patch is in a TODO list. On vim-dev there are some additional stories.
• multiple threading implementations or such, eg the if_mzsch has threadingsupport and locking or such as well as one of the features provides its own threading.
• Different if_ implementations have different sets of features/apis
• Community tends to reinvent the wheel even though you try hard to serveeverybody with some plugins (I don't think this is Vim specific)
• On the one hand its nice to have "vim" always do what it should, egseparating user and builtin namespaces. But that also makes it very very hard to implement some features or be backward compatible without rewriting bigger parts
• completion does not allow querying extended information lazily
• Vim should have a mode "try to guess indentation settings"https://github.com/ciaranm/detectindent/network
• Vim being backward compatible just sucks. I don't want to "touch ~/.vimrc"and set nocompatible over and over again. Who the hell is still depending on that behaviour? Having :e *<tab> completion is more important than being compatible for ever!
• pipes instead of temporary files (eg for :make like stuff)
• .viml files should be allowed to have 1310 line endings on Windows(See discussion https://github.com/gmarik/Vundle.vim/issues/6)

Yes - I agree on "Vim should be a text editor only" - but I also want it to be smart enough to let me do what I want. And at some point you hit a border. Some people work around it to get close to there goals, but often its about adding yet another hack.

In the end a project is as healthy as its community is. Emacs has a bigger community, why?

If you want this to be fixed and if you can afford spending resources (time/money) on this let me know.

How to escape from this

Options:

• Fork Vim (and spend a lot of time fixing this all) ? See fixing-vim-next-steps
• switch to vim-alternatives
• switch to .. ?
• start crowd funding? Preview vote here: http://mawercer.de/vim.php

So I guess we should start with a comparison about what we want so that we can choose one or muliple ways to continue.

I'd help getting this fixed by doing anything

• joining #vim-mutiny on irc.freenode.net
• supporting crowd funding (if it was started)
• spending time on patching/testing
• spending money for devs

Who would eventually join? * Marc Weber * fobius

If you want to get added send me an email: marco-oweber AT gmx.de

What's the main problem? its nontrivial to understand which is the best way to continue.

things to avoid

• 18:25 @LeoNerd> We don't want to pull in the huge amount of libgtk and all its dependencies just to found out we don't have a $DISPLAY, or libtickit just to find that STDIN is not a TTY