It doesn't surprise me terribly that, in the sizable userbase, some people manage to make it segfault - particularly running unknown plugins &c. The first example you give is even found to be a bug in a compiled external extension. I've not read through any of the others...

I've been using vim pretty much daily, across many versions, over roughly two decades, and I literally do not recall encountering a segfault. I would be hugely surprised if "segfaults all the time" is a more typical experience for an individual user.

It probably isn't. It's when you want to do async or timed things that things start to fall apart.

What use case do you have for timed things or async things?

For good ideas for async stuff you should try emacs. You don't have to keep using it, just look at what it does with its built-in asynchronous subprocess handling. The interactive python shell is particularly neat, but it also has grep and compile functionality that doesn't block the editor as it runs, and a gdb mode that (based on my very brief go with it) seemed to work pretty well.

One neat thing I use it for is TTY capture from a target system (usually games console or embedded device) over a serial or network cable. Run your terminal program in emacs at the start of the day, and emacs will dutifully capture all the terminal output as you work. Search, save and manipulate TTY output using all the commands you know and love.

Well - except for `.'. Or `*'. emacs doesn't do those two...

My experience certainly doesn't make that implausible. I am pretty careful about async IO in terms of how my software interfaces with me, and this translates to less uncontrolled use of it generally.

Bugs 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 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.

That's right, you can update when there's user interaction. Great. Can you use that for remote pair programming? Nope. You'd only be able to see any updates if you yourself was typing. While every other editor can do that just fine.

When Vim is inactive, I can attach a function in a CursorHold autocmd event which would consists of loop that reads from the resource object and sleeps for a small interval after that. As the external program/socket connection is running in separate process, reading from it is not resource sensitive so it should not block Vim entirely.

BTW there is a plugin called CoVim https://github.com/FredKSchott/CoVim that implements pair-programming feature using default built-in Python binding.

Did you even read those discussions? The C Segfault was due to a plugin. facepalm

Right, because a plugin causing a segfault is totally the plugin's fault.

Bram usually takes segfauls very seriously and usually fixes them very fast: > Scrolling in a c file segfaults: https://groups.google.com/forum/#!topic/vim_dev/teRV3RyDtzc Obviously not a Vim problem, as has been mentionend in the linked thread.

>Referencing an old buffer seg faults: https://groups.google.com/forum/#!topic/vim_dev/Mssm8pKtnGM Fixed with 7.4.59. It is pretty clear, this is a problem, but I wonder how to reproduce it, because I have never seen it crash there when closing buffers. So there must be some additional step to trigger it, otherwise we would have seen a lot more segfaults.

> Segfault opening a readme: https://groups.google.com/forum/#!topic/vim_dev/SE31YUccJN4

probably caused by the new regexp-engine, that was introduced with 7.4 I am not entirely happy about including it and there seem to be still several bugs in it, but it is not even clear, if that crash has not already been fixed.

> Segfault selecting a lot of text: https://groups.google.com/forum/#!topic/vim_dev/yzVqZ3qogho A recurring issue, that seems to happen to me too once in a while. Nobody knows what the cause is so, it can't be fixed currently. Seem to be not a problem of Vim, but of some of the X libraries.

> Segfault on autocompletion: https://groups.google.com/forum/#!topic/vim_dev/lqcn57eRGGs might have already been fixed. The reporter does not mentioned, how to reproduce it or even what version he uses.

> Segfault on tab switching: https://groups.google.com/forum/#!topic/vim_dev/Vc9Z8rfe22w Not exactly sure, what causes this.

> Just keep scrolling, the segfaults never stop. It's not as bad as you make it sound. Usually segfaults are taken seriously by Bram and will be fixed soon, if the problem is clear. Second, even in your list, you needed to scroll back a couple of months. I wouldn't call that exactly an evidence, that Vim is full of segfaults.

Even though the code is a mess, full of nested ifdefs and uses a lot of global state variables, I have not often seen segfaults and I have been providing many patches in the last years and there are still many patches of mine in the todo list. Overall I am quite happy, with a Vi clone that is actively maintained and even further developed, although sometimes I wish for some more activities in fixing bugs and adding features. But Bram seems to be too busy to take a more active role.