This works using Vim's NetBeans control protocol (inside Vim, do `:help netbeans` to get an overview. Also see the VimSocket class in vim.py) and minimal help from a simple VT100 emulator I wrote (found in term.py).
Open the command panel (cmd|ctrl+shift+p) and run the "ActualVim: Monitor TTY" command if you want to see what's going on in the terminal for any open view.
I actually wrote the first Vim emulation mode in Sublime Text a couple years back ( https://github.com/lunixbochs/sublimevim ) that possibly inspired the other similar plugins. I consistently ran into enough unsupported motions with both my own and other plugins that I caved and wrote ActualVim.
OT It's funny how conditioned I am to seeing __Beans and instantly dismissing it as something I can't be bothered to look into. Silly biased me; it looks like a really powerful 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, lint, compile, etc - but it had enough functionality I was able to barely make it work the other way.
eclim is probably an excellent reference-implementation of both approaches. Did you look at it, and if so was it useful?
I developed ActualVim using only a VT100 reference ( http://bochs.info/text/vt100.txt ) and `:help netbeans`
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.
They're using a Vim script to extend the NetBeans protocol and pass arbitrary messages back with nbkey/keyCommand. I can totally use this. Thanks!
VT100 embed is their third mode.
If you use vim as is you may not notice much, but vim will forever be limited to responding only to user interaction with no hope of ever getting any kind of timers, async actions or event loop.
Try making a simple clock for your status line that updates every second. You can't. And it will never be possible. Because vim is broken.
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 and vimproc. Vimproc is more widely used. See Unite.vim , neocomplete, VimShell 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 which provides FAST autocomplete.
> 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:
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:
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?
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.
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...
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.
BTW there is a plugin called CoVim https://github.com/FredKSchott/CoVim that implements pair-programming feature using default built-in Python binding.
>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.
Given the Macbook-heavy nature of HN, that's probably what leokun is talking about.
On the other hand I don't use very many plugins, esp. not plugins that have native extensions.
What is this async stuff you are talking about ?
Something vim cannot do, that other editors can. It's called an event loop. Vim only ever does anything based on user interaction. Sometimes you may just want to sit back and have vim do things even though you hadn't typed something recently. Like pair program remotely, have a clock, get notifications, all kinds of timed things.
This isn't to say there's no legitimate use for async processing in vim - just trying to be helpful to anyone wanting these particular things.
I would love to see some of the more modern stuff implemented into VIM, like the whole page code scroll preview from Sublime Text.
Vim's stability and the occurrence of certain seg faults in it may appear to be related, but it isn't proof one leads to the other just because it's on some list somewhere.
I consider the term 'stability' to be related to overall dependability. I depend on vim on a daily basis, as do others here. It's yet to let me down.
I've certainly seen people being passionate about software but this is new. ;)
It's clearly an unsafe operation that wont work with async/timed code, because the buffer may be null at that point, but Bram's response is how do you reproduce it? How do you reproduce it? It's a segfault on an unsafe pointer! It crashes vim. Anyway, the way to reproduce it and all the other segfaults I encountered is to develop a plugin using the timers in that patch.
So nope, vim is broken, and that patch will never see the light of day. Those guys put months of work into that patch and Bram is like "I don't have time." His instincts are right. The patch would ruin vim for anyone using timers.
This has been acknowledged and even patched as you surely know. So what are you complaining about exactly?
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. :)
For instance, Vim uses an internal byte queue to represent all input. When Vim receives keystrokes, it translates them to known sequences, sometimes combining them with previous bytes, and shoves them back into the input stream- ie, instead of using structs/unions, Vim uses raw bytes. The down side (besides the insanity of doing this in the first place) is that some sequences can never be represented unless you want a byte/multibyte sequence for every possible combination. Data is just lost. On the upside, Vim potentially saves a few bytes. No one would make that tradeoff in 2013. See https://groups.google.com/forum/#!topic/vim_dev/2bp9UdfZ63M for the discussion about this.
Another problem for attack is that Vim uses a pile of regex hacks for syntax highlighting. Presumably, the hacks make it go faster. Of course, some things are context specific, so this gets really fucking ugly really quickly. Perhaps this wouldn't be a huge problem, but Vim also lacks the ability to run any asynchronous plugins (https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM). IE, you couldn't do the highlighting outside of Vim and apply the rules in real time. You can't run a linter in the background and highlight errors. The patch ostensibly fixes these problems, but in reality it will never be merged because of existing bugs in Vim (ie, the extension causes Vim to crash through no fault of its own).
The design philosophy of Vim is that it should be embedded (not an IDE). This is fine, but Vim makes this hard because it uses global variables for everything instead of internal interfaces among other reasons. If Vim made this easy, you'd see Vim embedded into other text editors (instead of emulated or instead of using crazy pty hacks).
The most useful change I could see would be dropping Vim script entirely and replacing it with a single, well known scripting language. This is somewhat in the works right now- Bram is currently in the process of better bridging the gap between python and Vim (currently, python is restricted to evaling vimscript/ex commands).
Ultimately, 100K could do a bit to cleanup Vim, but that probably isn't helpful to end users. If you peruse the vim mailing list, there are quite a few topics like this- people suggesting or implementing large changes- they all get dropped. Realistically, I just see Vim stagnating.
From my point of view it is a very dependable text editor with lots of room for customizability and an unparalleled text editing paradigm.
How many ifdefs it has, the length of its source files or its use of pointers don't matter to me because they have zero negative effect on my workflow. I like Vim as it is, I don't feel limited in any way.
The impossibility to make a clock in a text editor is not an indication that it's broken: it's a sign that you should buy a wristwatch.
As others have said, how in the world are you having these kinds of issues?
It seems rather silly to complain about missing functionality that doesn't achieve the tools core value prop.
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
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.
To borrow your situation, if you are already using the mouse it's distracting to have to use the keyboard.
Apart from that, many people like the looks of Sublime, and (at least for me) the Sublime text view scrolls a lot better for large documents than either Vim, MacVim, or Emacs.
Edit: I'm not a Sublime user, I switched from longtime Vim to Emacs + Evil a couple of months ago and couldn't be happier (well, I'd like better scrolling, but I mostly jump anyway)
As for jumping around while in insert mode, I totally understand that instinct but it goes against the grain of Vim. Don't spend extra time in insert mode.
I think the real problem with Vim is that you have to wrangle it with a lot of tweaks to make it sane and comfortable and that's a rabbit hole a lot of people (justifiably) don't want to go down. Sublime is very friendly, I like it a lot, Vim demands a long weekend of your life to customize but it really does leapfrog everything once you get it right.
... I for one, look forward to running emacs in sublime, and in an eterm in emacs running vim, which will of course, be running subvim, full circle.
Vim feels a lot like Linux to me. When I was young I loved Linux as I really enjoyed tweaking it and hacking on it. But now I just want my OS to work and get out of the way, so I use OSX. I want the "OSX of editors", which is probably Sublime. But man do I love vim's text manipulation.
When I was a .NET dev, Visual Studio+viemu was pretty much perfect. Text manipulation via vim, project management via VS. viemu is the only vi emulator I've found that is really well done.
ctrl+h ctrl+h - takes you to the sidebar where you can navigate using j, k, h, l
ctrl+h - move to pane to the left
ctrl+l - move to pane to the right
ctrl+shift+h - move and create pane to the right
ctrl+shift+l - move and create pane to the left
.. and a few others
https://github.com/emacs-helm/helm (go to anything)
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.
In that case, you have at least Vintage, Vintageous, and my original project sublimevim (that was mostly a proof of concept before we had any of this) as "vim-mode" in Sublime Text.
Also can you check the console when opening a file to make sure there's no error?
There are ways to get around it, but getting the error in the editor window is very nice for dummies like me.