vim gets rewritten ?
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
- 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
- :compiler is not perfect, eg if you use a ruby build system to build ahaskell application you want to have both error formats
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
- 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
- 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
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
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
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
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