SHshocks·Jan 14, 2014
Is this a bi like vimproc[1]?
1: https://github.com/Shougo/vimproc.vim
In An experimental Vim fork with multi-threading capabilitiesShougo
vimproc.vim
Vim Script2013–2014
Shougo / vimproc.vim
vimproc.vim
Interactive command execution in Vim.
3Distinct people
5Mentions
0Explicit recommenders
1.1KGitHub stars
What to know before exploring
What it is
Interactive command execution in Vim.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- shougo/unite.vim · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by week5 dated mentions
Observed mentions: 2013-09-12 08:20:30 UTC to 2014-01-14 18:59:34 UTC. Weeks start Monday, UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Sep 9 | 2013-09-09 00:00:00 UTC | 2013-09-16 00:00:00 UTC | 1 | 0 | 1 |
| Sep 16 | 2013-09-16 00:00:00 UTC | 2013-09-23 00:00:00 UTC | 0 | 0 | 0 |
| Sep 23 | 2013-09-23 00:00:00 UTC | 2013-09-30 00:00:00 UTC | 0 | 0 | 0 |
| Sep 30 | 2013-09-30 00:00:00 UTC | 2013-10-07 00:00:00 UTC | 0 | 0 | 0 |
| Oct 7 | 2013-10-07 00:00:00 UTC | 2013-10-14 00:00:00 UTC | 0 | 0 | 0 |
| Oct 14 | 2013-10-14 00:00:00 UTC | 2013-10-21 00:00:00 UTC | 0 | 0 | 0 |
| Oct 21 | 2013-10-21 00:00:00 UTC | 2013-10-28 00:00:00 UTC | 0 | 0 | 0 |
| Oct 28 | 2013-10-28 00:00:00 UTC | 2013-11-04 00:00:00 UTC | 0 | 0 | 0 |
| Nov 4 | 2013-11-04 00:00:00 UTC | 2013-11-11 00:00:00 UTC | 3 | 0 | 3 |
| Nov 11 | 2013-11-11 00:00:00 UTC | 2013-11-18 00:00:00 UTC | 0 | 0 | 0 |
| Nov 18 | 2013-11-18 00:00:00 UTC | 2013-11-25 00:00:00 UTC | 0 | 0 | 0 |
| Nov 25 | 2013-11-25 00:00:00 UTC | 2013-12-02 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2 | 2013-12-02 00:00:00 UTC | 2013-12-09 00:00:00 UTC | 0 | 0 | 0 |
| Dec 9 | 2013-12-09 00:00:00 UTC | 2013-12-16 00:00:00 UTC | 0 | 0 | 0 |
| Dec 16 | 2013-12-16 00:00:00 UTC | 2013-12-23 00:00:00 UTC | 0 | 0 | 0 |
| Dec 23 | 2013-12-23 00:00:00 UTC | 2013-12-30 00:00:00 UTC | 0 | 0 | 0 |
| Dec 30 | 2013-12-30 00:00:00 UTC | 2014-01-06 00:00:00 UTC | 0 | 0 | 0 |
| Jan 6 | 2014-01-06 00:00:00 UTC | 2014-01-13 00:00:00 UTC | 0 | 0 | 0 |
| Jan 13 | 2014-01-13 00:00:00 UTC | 2014-01-20 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
5 sourcesBugs happen in software, you can not avoid. It is specially true for Vim which is used in wide variety of platforms. But still the segfaults bug listing is not that frequent as you described. Also Bram and other members are responding to to bug report in timely manner. Last I heard author of Sublime have stopped responding to bug reports.
Also you have zero knowledge of how Vimproc works. It spawns process or create socket connection in background and clients have access to it as a resource object from which client can read data during CursorMoved and CursorMovedI autocmd events. It is actually psudo-async but it works very well. I am using the plugins that have used Vimproc, even I used it in my PHP autocomplete plugin https://github.com/m2mdas/phpcomplete-extended (shameless plug) and it did not failed me yet. Also if you looked at the
Read the rest
s:garbage_collect() method https://github.com/Shougo/vimproc.vim/blob/master/autoload/v... it is trying to release resource handles of the processes exited.
Also why should I need a clock inside vim? There is tmux/Screen status line for that. Please provide another valid use case.
Nope, and nope.
> WTF are you talking about? Vim have may have many demerits but segfaults is not on that list. If segfaults are that frequent you described then people would have jumped ship already.
Vim is all segfaults once you introduce async, and it's highly unstable during any dev work. On any given day visit the Vim dev mailing list and scroll down. Today I see:
Scrolling in a c file segfaults: https://groups.google.com/forum/#!topic/vim_dev/teRV3RyDtzc
Referencing an old buffer seg faults: https://groups.google.com/forum/#!topic/vim_dev/Mssm8pKtnGM
Segfault opening a readme: https://groups.google.com/forum/#!topic/vim_dev/SE31YUccJN4
Segfault selecting a lot of text: https://groups.google.com/forum/#!topic/vim_dev/yzVqZ3qogho
Segfault on autocompletion: https://groups.google.com/forum/#!topic/vim_dev/lqcn57eRGGs
Segfault on tab sw
Read the rest
itching:
https://groups.google.com/forum/#!topic/vim_dev/Vc9Z8rfe22w
Just keep scrolling, the segfaults never stop.
> Though async future is not built-in there are several plugins for doing async operation, for example...
For your other point, some plugins fake async using a cursorhold hack that break vim for users who use leader keys. That is they insert fake key strokes. Vimproc actually quits on cursorhold:
https://github.com/Shougo/vimproc.vim/blob/master/autoload/v...
That's right thess plugins inserts keys to trigger autocommand. I would like you to go ahead and type a long vim command using leader keys and see if that works for you. When a plugin inserts keys while you are inserting keys everything stops and you have to start over.
Go ahead, go implement a clock with a plugin that updates every second. I bet that plugin fakes user interaction. It doesn't work.
Edit: Also nice on the downvotes, perhaps explain how my post is wrong in addition to downvoting. Everything I have said are matters of fact. Are my facts wrong?
WTF are you talking about? Vim have may have many demerits but segfaults is not on that list. If segfaults are that frequent you described then people would have jumped ship already.
I can't comment on the code structure of Vim but it does not matter to me because end product is working fine for me for 5+ years. Also bad code structure did not stop continuous development of Vim. Just for example there were 1000 patches added to the core before Vim version was changed from 7.3 to 7.4 within 2 years. Important features like more python binding, lua bindings were added during this time. Even if you see the current patch log of 7.4 ftp://ftp.vim.org/pub/vim/patches/7.4/README 68 patches were added since 7.4 release.
Though async future is not built-in there are several plugins for doing async operation, for example vim-dispatch[1] and vimproc
Read the rest
. Vimproc is more widely used. See Unite.vim[3] , neocomplete[4], VimShell[5] for demonstration. I would specially point to VimShell because with the help of it you can run REPL inside Vim and pass buffer content to it. Also there is YouCompleteMe[6] which provides FAST autocomplete.
[1](https://github.com/tpope/vim-dispatch/)
[2](https://github.com/Shougo/vimproc.vim/)
[3](https://github.com/Shougo/unite.vim)
[4](https://github.com/Shougo/neocomplete.vim)
[5](https://github.com/Shougo/vimshell.vim)
[6](https://github.com/Valloric/YouCompleteMe/)
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 fre
Read the rest
quently 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/
[2] https://github.com/Shougo/vimproc.vim
[3] https://github.com/sickill/vim-pasta
[4] https://github.com/m2mdas/phpcomplete-extended
[5] https://github.com/m2mdas/unite-file-vcs
[6] https://github.com/Shougo/unite-outline