My background? It is Vim.
I use Vim for writing Vim plugins. Of course, I use Vim for my work. But it is not the main purpose.
I have been using Vim for almost 10 years.
My main Vim usage is GVim. But I use terminal Vim (or Neovim) if needed like remote editing work. My main OS is Manjaro Linux with Xfce.
Current Vim version is 7.4.1219. It is the latest version currently. It is built with huge version with Python2 and lua and GUI.
I use other text-editing programs. For example, Firefox or LibreOffice if needed. My best is Vim though.
I choose Vim over other editors because, once I have lived in Windows environment. In Windows environment, Emacs is too bad. Although Vim is difficult editor, many good information is available. Easy to start. And many filetypes support is available.
My configuration is full lazy loaded by neobundle.vim and split into the multiple files. People may be suprised.
My favorites are deoplete.nvim/neocomplete.vim, vimshell.vim, unite.vim.
unite.vim can do everything. To open the project files, I use unite.vim. But I sometimes use vimfiler.vim instead.
I use neobundle.vim currently as my plugin manager. But it is too complex implementation. I will replace it to dein.vim after the development.
I use sticky shift mappings originally.
I don’t use staus line plugins. I like simple one.
“:help”, especially “:help eval” and “:help vim-script-intro”. Vim is well documented.
In Vim, channel feature.
In neovim, remote plugin feature.
I once used autocomplpop(acp.vim) plugin. https://bitbucket.org/ns9tks/vim-autocomplpop/
It is very useful, but it uses Vim builtin completions and cannot be customized.
So I created neocomplcache.vim. https://github.com/Shougo/neocomplcache.vim
neocomplcache is inspired from:
It is the ultimate interface. It integrates everything. It is like Vim. HeHeHe…
I need anything.el for Vim. Unite.vim is inspired from ku.vim and anything.el. So, unite.vim is not just the fuzzy finder.
I will rewrite unite.vim for neovim remote plugin in the future. Unite.vim is the best plugins for me. But the implementation is too complicated and slow (I think you know).
vimproc.vim is the asynchronous library for Vim script.
If it is not asynchronous, it blocks your Vim. It is very irritated. Vim is improtant program like the Operating Systems. It is like the OS is freeze! No, it is not accepted!
I forked Yukihiro Nakadaira’s proc.vim to make vimproc.vim because I need proc.vim’s asynchronous feature to create vimshell.vim.
I use vimproc.vim in my plugins if possible. For example, unite.vim, neobundle.vim, vimfiler.vim etc. I need proc.vim’s asynchronous feature to create vimshell.vim. And other people use vimproc to implement asynchronous feature. But they may be replaced with Vim’s channel feature or neovim’s job feature.
I talk about Vim/neovim at meetups every years. Dark side Vimmers have been grown… HeHeHe
$ echo "editor song" > shougo "Internal error: 'Editor songs' is not defined in Shougo..." vimshell exit 1
I think the text editor is the most important things in the world. So you can describe the world by the text editors things. “Battle editors” is one of them. Unfortunately, I cannot write “battle editors” in English. Sorry.
I should describe “battle editors world” in English….
[Shougo later sent the below follow-up.]
New BattleEditors novel repository is:
I will translate it in English.
The asynchronous is implemented Vim and neovim. So, the next is to extend GUI features. For example, image support.
For Vim, to improve the completion behavior.
For neovim, to fix/improve the remote plugins implementation including Python3 support.