Vim is both: beloved and hated by me(for those reasons you mention ). I still love it more than I hate it :)
To keep the summary short: This is may way to cope with it: Start documenting what to change: http://vim-wiki.mawercer.de/wiki/index.html also see this subpage - (please add all your items there so that they don't get lost) http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html The main issue is: I don't know which is the perfect way to fix everything I found yet. Will take at least till April till I know more about this. On irc there is an unoffical #vim-mutiny channel with people who would like to improve many of the things you mention. One of the reasons is: Its a lot of work. Some partial consens is: - C gets the job done, but writing abstract code is tough (too tough for me, sry. I'd even call it a waste of time - but the compiler I'd like to use does not exist AFAIK) - C++ is close to usable now that C11++ is there (with pointer knowing about responsibilities and such). - But is this the most general solution? Shouldn't we strive to merge power of Emacs/Sublime/Vim users by working on apis and implementing the plugins we want based on those apis? Or create a new compiler which can compile down to js, C, lisp so that plugins can be shared across emacs/vim/Yi ? If you follow the path you've started (thinking about what sucks and how to improve) you'll start learning that there are many solutions. Which one is best? I invite you to take part finding it. But let me also try to help you with your current issues > 1. Drop support for anything except Python (including vimscript) vimscript is 70% of vim. A lot of plugins such as matchit are used that often that dropping vimscript means you can start using Emacs right away. Also the VimL stuff is coupled with Vim functionality (internally), eg there is no python only implementation of map, command like commands. So for now forgett about it unless you have much time. > that, due to some compile time events, they can't use this plugin. Well - maybe join gituhb.com/MarcWeber/vim-addon-manager and add a bug report that it should add constraints, such as "this plugin requires ruby" - thus prevent installing it. However Command-T is well known, and there are many alternatives which work almost as good, see this simple FastGlob implementation which has been good enough for me for ages: http://vim-wiki.mawercer.de/wiki/topic/opening-switching-files.html There are many additional implementations. Maybe even try such: https://github.com/Shougo/unite.vim Thus think about whether you really need it. Also installing vim with ruby support is dead simple if you need the right distribution, such as nixos linux. > Dropping Vimscript support may be the toughest job, but think of it. You're wrong. Because then you could just use Yzis. And that has been abondoned. Thus it has been done. Community is still here - think and learn about why. Yzis uses lua though. > Do you feel in your heart that, there's anyone on earth, who honestly > want to program in vimscript? Depends on the task. Complicated or performance critical stuff: No. But given its age useful is - autoload feature - that eval happens to be close to json_decode - releading works nicely (With reload plugin) - ... but yes, no closures (funcref in github.com/MarcWeber/vim-addon-mw-utils) implements a workaround and similar make it hard. But the bigger problem is async support. > Is there anything, that can be done in > vimscript, but can't be done in python? Wrong question. XSL and Haskell type level programming both are touring complete, too. Its worth that VimL can be interrupted in for loops and resize events get triggered (due to "run event loop now to look for ctrl-c abort) and such. That sucks. Fixing it would require introducing threading etc. > I feel a little bit frustrated, when I see the plugin I am going > to use, was last developed 3 years before(Though it works better than > anything else I have used). :) > Losing vimscript, you are bringing a revolution in development. I totally agree, but you also split community which is why it should be wise to think about which upstream to provide. > 2. Improved plugin management like pip. > Reason: > I am a big fan of Vundle. Again - try vam. Vundle was started after VAM. VAM is more powerful. See here: http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html (if somebody feels any of the tools being treated unfair just fix, thanks) That you don't mention vim-addon-manager means you didn't know about it (which means that Vim also has a documentation issue, again, something I want to fix with the simple git based wiki. Currently the docs are spread over :help www.vim.org www.vim.org/scripts vim wikia http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html and many additional places But if you have a look at the amount of contributors to my wiki you'll understand that its the same as wikia: Only individualists try to improve them. I cannot make contributing easier than even allowing to edit without login. > vundle it eg fails on loading plugins at runtime (lazily to keep startup time fast), it fails on non git sources - but I agree it works good enough for most use cases. > YouCompleteMe Again, a distribution such as "nixos" in combination with vundle/vam will make it a lot easier. Then you can install YouCompleteMe by distro and symlink it to ~.vim/plugin-dir/YouCompleteMe and have it activated by vundle/pathogen/vam. A Vim only solution will never reall succeed installing such complicated combinations (same about ocaml completion support, eclim etc). > or plugins like powerline, which takes quite a bit of setup before use. What is the problem with powerline? VAM supports dependencies. Also have a look at this which wants to use ruby gems for managing vim plugins: https://www.relishapp.com/kana/vim-flavor/docs/philosophy (And now you have the mess, support Ruby or Python? Its hard to force community) This author didn't even reply to me when I asked about how VAM and that project can collaborate, because VAM is also about having a maintained pool of packages (and telling users about alternatives for outdated packages). The implementation is not perfect but it gets the job done IMHO. > In this way, one can mark another plugin as dependency for his own one > in a convenient way. VAM introduces addon-info.json which may contain { dependencies: { "plugin-name": { .. } "other-plugin-name": { .. } } If you need more info contact me on irc or by mail. The values of the dependencies can even be links to github urls. But I prefer people submitting packages to VAM-kr so that they can be referred to by uniq human readable names. > 3. Embedded shell support like screen.vim. ConqTerm or such come close. However it only works in insert mode, and you cannot use vi keys. vim-addon-async tries to be a smart async solution redirecting stdin/out to from processes. It implements ruby/python/php completion for repl, too. Thus just "having a shell" might be what you want, or not. But yeah, it sucks which is why I say that async is a real problem, too. We know all know it. For older Vims there has been a patch turning a buffer into a terminal. > 5. Documentation support at point. Plugin's like YouCompleteMe > provides language documentation. But it opens a window at top, rather > than at the place where I am typing. I stopped caring about positions. I just make sure I can open the files I need fast. Thus instead of making sure something like TList is always on the left I map a key to "open it on the left side". Eg I've mapped <m-s-X> where X is hjklq to wincmd X so that hiding buffers is one hit only. Of course my reply will not solve your problems, but it might help you in some ways. Vim is historically grown very much, and there is no trivial fix which can be applied in 5 days IMHO. (or at least I cannot do it, maybe somebody else can ?) So let me suggest that you keep posting about the most urgent problems, maybe there are workarounds so that you can at least still use Vim in a productive way. Community is listening and helping. This is my biased view on the topic. My knowledge is limited, too. I hope others point out where I'm obviously wrong. So before suggesting to rewrite VIm have a look at history of some famous editors such as jedit, Vim, Emacs - it does take quite a while. Yours Marc Weber -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
