I didn't say default OS X, I said MacVim, which many Mac OS X users use. To say it doesn't work on Macs is wrong when there is MacVim.
I wrote it in OS X. I'm not sure where you see "doesn't work in OS X". I said it doesn't work in Windows. Quoting the docs: "it's likely to only work in Linux and OS X for the near future" It works out of the box for me in Mavericks. It would actually have a worse time running if you managed to use MacVim on the backend, because it scrapes the status and command lines from terminal output.
The clock is a basic example of something simple vim can't do. It's not because I can't have a clock.
That's a stupid example and it undermines everything sensible you said elsewhere. What about the following useful usecases? * on-the-fly syntax validation * non-blocking as-you-type completion * live results from shell commands * fast syntax highlighting * etc.
Well a clock is pretty easy to make, so an easy challenge to anyone countering me, you just change some numbers somewhere, but sure. I guess I just didn't have the imagination to think of something better while in rant mode.
Because vim is broken. I gave up vim after 7 years because of all the segfaults, in-extensibility and just horrible code. Some of the files in the vim code base are over 20,000 lines with hundreds of ifdefs, and littered with unsafe pointer use. The code is a horrible experience to just look at, pre 1989 C style functions, mixed tabs and spaces everywhere, and the files aren't even a valid encoding of any kind whatso…
How much of a challenge would it be to rewrite vim properly? Or is that a crazy idea..
Vim is a house of cards. It relies on global state for everything; changing a global variable, calling a function, and changing it back to the original value is a common pattern. Precompiler switches also cause trouble. Nested ifdefs - inside functional calls (adding or removing arguments) are another common pattern. There is also quite a bit of copy paste. Vim supports every OS- amiga, VMS, dos to name the uncommon ones. It has bindings to nearly every scripting language including python, perl, and ruby, scheme, lua, and others. The code base is such a mess that new features are very difficult to write, but there is no incentive to fix that.
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.…
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…
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.
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 patch…
vim segfaults a lot on my copy of OS X. Never seen it happen on Linux or Windows though. Given the Macbook-heavy nature of HN, that's probably what leokun is talking about.
Never experienced VIM crash of any kind on Mac OS X, Linux or Windows. And I have been using it since Amiga days.
On the other hand I don't use very many plugins, esp. not plugins that have native extensions.
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…
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.
This makes me want to ask... why not just use vim?
Because vim is broken. I gave up vim after 7 years because of all the segfaults, in-extensibility and just horrible code. Some of the files in the vim code base are over 20,000 lines with hundreds of ifdefs, and littered with unsafe pointer use. The code is a horrible experience to just look at, pre 1989 C style functions, mixed tabs and spaces everywhere, and the files aren't even a valid encoding of any kind whatso…
Just asked my office mate who's been using VIM on ubuntu for probably 10 years (vim, maybe not ubuntu) now about this. He literally edits and builds code all day every day for 8+ hours. His environment is pretty simple, not many plugins, a solarized them and that's about it. He mostly develops in css, html, javascript, lots of python, and c++. Never had a segfault. This matches my experience as well.
As others have said, how in the world are you having these kinds of issues?
How much of a challenge would it be to rewrite vim properly? Or is that a crazy idea..
Vim is a house of cards. It relies on global state for everything; changing a global variable, calling a function, and changing it back to the original value is a common pattern. Precompiler switches also cause trouble. Nested ifdefs - inside functional calls (adding or removing arguments) are another common pattern. There is also quite a bit of copy paste. Vim supports every OS- amiga, VMS, dos to name the uncommon…
Not that I would want to do this, but (just so I can judge the scope of what you're saying), if someone were to start a kickstarter to rewrite it, would $100,000 be enough?
Things I would actually be interested in for Vim: Some sort of type-validation plugin for languages like C, C++, Scala, Haskell, etc. There are ways to get around it, but getting the error in the editor window is very nice for dummies like me.
Sublime Text in-editor linting is one of my projects too (sublimelint/SublimeLinter).
> NetBeans protocol ... I think it's meant to be used the other way - using Vim as your frontend to edit code while using NetBeans to manage the project eclim[1] is probably an excellent reference-implementation of both approaches. Did you look at it, and if so was it useful? [1] https://github.com/ervandew/eclim
Isn't eclim primarily to use Vim as the frontend and Eclipse as the backend? Same idea, slightly different scenario. I used it for linting Java over in sublimelint. I developed ActualVim using only a VT100 reference ( http://bochs.info/text/vt100.txt ) and `:help netbeans`
The core of eclim is a server that talks to the Eclipse JDK, for which there are vim, emacs, etc, front-ends.
Eclim also happens to provide an Eclipse plugin that _embeds_ Vim in Eclipse, using the NetBeans protocol, just as you are embedding Vim in Sublime. The author of eclim is also very responsive, if you wanted to ask him about anything.