31–40 of 112 posts
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…
I love vim's keybindings and cant work without them. I really like sublime but i just cant leave vim's keybindings which makes me so much efficient. Last time I tried a vim emulator for sublime it didn't go so well. it wasnt as smooth and limiting. I hope someone perfects the vim+sublime combo because that would be killer.
Earlier quoted context omitted.
How much of a challenge would it be to rewrite vim properly? Or is that a crazy idea..
Not that crazy. Vim itself is a reboot of Vi, and there were/are other minimal Vi clones that are very small (couple of KLOCs). You'd be throwing away the horrible Vimscript, and sadly the community is married to it. As a result your neat little Vim2 reboot thing will not be nearly as useful for a long time, so you've lost backwards compatibility for what? Cleaner internals? Doesn't really benefit the end user much.…
This makes me want to ask... why not just use vim?
Because with this you can use Sublime Text's UI (chrome, file browser, and smooth scrolling—all better than Vim's) with Vim's input mode. Best of both worlds.
Earlier quoted context omitted.
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…
But this thing is Vim.
Earlier quoted context omitted.
Not that crazy. Vim itself is a reboot of Vi, and there were/are other minimal Vi clones that are very small (couple of KLOCs). You'd be throwing away the horrible Vimscript, and sadly the community is married to it. As a result your neat little Vim2 reboot thing will not be nearly as useful for a long time, so you've lost backwards compatibility for what? Cleaner internals? Doesn't really benefit the end user much.…
I really don't care much about backward compatibility with existing plugins. We're using vim not the plugins anyway. I justed wanted an terminal editor with vi bindings.
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…
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. 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)
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…
Earlier quoted context omitted.
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…
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…
> 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 switching: 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?