3 ms·
Pasting the reply I gave in r/vim Answer to some of the points, Janus: There are divided opinions in vim community about whether distributions should be used
by m2mdas 13y ago
Pasting the reply I gave in r/vim
Answer to some of the points,
Janus: There are divided opinions in vim community about whether distributions should be used or not. I am on the latter side. But still for just checking out I installed Janus a while ago. Yes it is slow, but it turns out that it is as slow as my then `.vimrc` configuration. I tried to track down the problem. It is because of vim's blocking behaviour during executing external commands. When you write a buffer or switch to a buffer, syntastic, tagbar, powerline statusline, gitgutter, bufexplorer all execute external command. Vim becomes more slow when `.git` repository grow larger or when saving a large file. So how do you solve the problem? Remove those plugins and install Unite.vim[1] with vimproc[2] asynchronous library.
Files that change: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server.
* Indenting pastes* : There is a plugin for that [3] ?
* Opening files inside my project : Last I checked command-t was damn fast, don't know where slowness comes form. Another alternative is `Unite.vim` `file/async` source. It is fast at finding files but goes slow while doing ignore-pattern checking. Without the checking it is DAMN FAST. The `phpcomplete/files` source I created for my php autocomplete plugin[4] easily list 4000+ files in seconds. If you want to list files obeying the patterns in the '.gitignore' or '.hgignore' files. Checkout my unite-file-vcs[4] plugin. It adds a `file/vcs` source that lists files by issuing `git ls-files` or `hg status -c -m -u` command for `git` or `mercurial` projects respectively.
Navigating inside files*: Checkout unite-outline[6]. It shows live output by parsing the current buffer. Unite.vim required. But it does not support css files right now. Adding support should be easy.
So the summary of the story. Move to `unite.vim` and friends ;)
[1] https://github.com/Shougo/unite.vim/ https://github.com/Shougo/unite.vim/
[2] https://github.com/Shougo/vimproc.vim https://github.com/Shougo/vimproc.vim
[3] https://github.com/sickill/vim-pasta https://github.com/sickill/vim-pasta
[4] https://github.com/m2mdas/phpcomplete-extended https://github.com/m2mdas/phpcomplete-extended
[5] https://github.com/m2mdas/unite-file-vcs https://github.com/m2mdas/unite-file-vcs
[6] https://github.com/Shougo/unite-outline https://github.com/Shougo/unite-outline
- regularfry 13y ago> Files that change: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server. It's possible this isn't what you meant, but external edits do not imply editing code live on a server.
- m2mdas 13y agoWell I made this comment in context of his editing file via pry-rescue which at first observation looked as if he was live editing in server. Upon further inspection it seems that pry-resque is acutlly a good debugging tool. I did not know about it because of my very little ruby development knowledge. Sorry, My bad :)