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.
Really nice work. I'm happy where I am in vim but if I ever decided to move this looks like the way to go.
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 have my share of complaints about the NetBeans protocol. It's actually pretty weird and incomplete, but it's supported by default so I'm using it.
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.
> 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?
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.
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.
Is he not just embedding a VT100 emulator and using NetBeans socket to copy the buffer back and forth? The primary focus of NetBeans integration is to pass basic state forth and not to facilitate a full Vim embed.
To be honest, I don't know. An eclim discussion[1] implies that eclim is using Vim's NetBeans protocol, and the eclim code that I have read is well-organized and the project is mature, so when you said you were having issues with the NetBeans protocol I thought eclim might be a useful reference for you.
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 whatsoever, instead it has this broken mbyte that will ruin your day if you touch a vim source file in anything but vim.
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.
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. 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.
> 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:
> 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?
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.
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.
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.
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.
> 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.
I have no idea how you make vim crash; usually it's because I attempt to search through a multigigabyte file or something. Vim may have many issues but stability is NOT one of them.
Vim is one of the software I use almost everyday. I've almost never seen it segfault. You are doing something very experimental or running some stuff that maybe is not just suitable to be used with VIM.
> 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.
For many of these, there are better solutions than shoving them into vim. You can easily add a clock to a hardstatus line in screen or tmux. You can also use these for pair programming, reasonably easily. Notifications are better piped through notify, so you see them even if vim hidden.
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.
Okay cool, I get it. Thanks for the info.
Yeah I see these could be useful in a modern environment.
But nothing really beats (at least for me) the expressive way I can edit text in VIM.
I would love to see some of the more modern stuff implemented into VIM, like the whole page code scroll preview from Sublime Text.
You are making an ad hominem argument against vim's 'stability' using the fact the dev list has seg faults at the top. As a matter of course, seg faults/crashes are the most irritating bug a program can encounter. When they occur and are repeatable, it's likely they would become a popular topic of discussion, regardless of the frequency in which they occur.
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.
It is not as bad as you make it sound. We are currently seeing many segfaults because of the release of 7.4 and its inclusion of a new regexp engine. Other then that, there are not more segfaults then usually, which is not that bad.
A patch series implementing asynchronous timers has in fact recently been posted to the Vim development list [^1]. Its status is uncertain, and is still being actively discussed, but to state that such a thing "will never be possible" is just blatantly false.
Actually I know all about that patch and have commented in that thread. I tried that patch and vim segfaults. It's not the patch's fault, it's vim's fault. Checkout this response from Bram when one of the devs for that patch reveals an error:
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.
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.
Is there so much in your .vimrc that it couldn't be written in a new syntax, without that much effort? We're not talking about supporting an entire legacy software app here.
Not every potential Vim user already uses it. So right, you couldn't pry Vimscript out of the hands of diehard users, but you might get a big crowd of people who aren't otherwise willing to take on Vim in the first place.
The challenge will be in getting the crazy compatibility that vim currently has. Given the pre-1989 C style syntax it probably still compiles on the original Amiga it was developed on. That's not really a good thing unless you use an Amiga still.
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.
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?
I suppose it depends on what you want to accomplish. Most of the extra baggage could be removed within a month. Fixing other things would be much much harder.
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.
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?
So Vim is broken because you can't have a clock in your status line? Are you an idiot? Seriously, all that ranting and you can't come up with a single practical example of Vim being "broken" other than not being able to have a clock in your status line? I'm assuming you just made up the segfault thing because I have literally never seen that happen.
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.
No, it connects to vim via vim's client server mechanism. The docs for it are wrong, because it will work on OS X if you have MacVim set as your default vim because MacVim is compiled with +server. Anyway, I am quite sure this thing will run into all kinds of trouble because of how broken vim is.
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.
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.
The point of vim and its key bindings is to not have to use anything other than the keyboard (and keys that are not too off from the home row), so it's not the best of both worlds at all. Having to click on something forces someone to use their mouse, breaking their concentration and wasting time on clicking on a tab.
Having to click on something is different from being able to click on something. Vim doesn't let you use one of the two primary input tools of your computer--Sublime lets you use both.
To borrow your situation, if you are already using the mouse it's distracting to have to use the keyboard.
Maybe you should actually use something before forming an opinion on it. Your lack of knowledge with vim is pretty obvious given that you didn't know that you could use your mouse.
I'm just guessing here, but you can use all the Sublime Plugins and Key combos while in INSERT mode. The Vim Insert Mode is rather limiting since you're supposed to do mostly just typing in there. I always add the basic emacs keybindings to my vimrc so that I can jump by word, to the beginning of the line / the end or move by character, without leaving insert mode. I really don't like leaving insert mode for just 2 char movements. I know there's CMD-O for that, but I find it too cumbersome still.
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)
Vim can be setup to look and scroll exactly like Sublime, I recall a mapping where the key for 'go down a screen' is overridden with multiple 'go down 1 line' which makes it feel smooth. (I generally just go '{L,H,M}', 'z{t,m,b}')
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.
No. Kien's CtrlP plugin is inspired by Sublime's Ctrl+P (the name is the hint) feature which itself extends TextMate's Cmd+T and Cmd+Shift+T which inspired numerous other Vim plugins like Command-T (hint), FuzzyFinder, LustyExplorer, Unite and many others.
I know. But it doesn't work the way I want it to. It needs to fuzzy search the directory that I've opened, prioritizing first by reverse chronological order of when they were opened. It's been a while, but I played with the settings for both the CtrlP and the Command-T plug-in, but neither worked like in Sublime.
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.
Me too. I really love the way vim manipulates text. But I really dislike vim as a dev environment. I currently run with a bunch of plugins (nerdtree, YouCompleteMe, vim-indent-guides, ctrlp.vim, etc etc) and they all roughly do what they intend to do. But at the end of the day, I find myself tweaking my vim config a lot just to get a decent experience.
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.
You might want to try Vintageous[0], It improves the native "Vintage" mode and adds things like vim-style searching and multiple cursors support. If you are addicted to NERDTree like I was, here are some custom keymapping[1] that will allow you to navigate the sidebar using the keyboard.
ctrl+h ctrl+h - takes you to the sidebar where you can navigate using j, k, h, l
Because you get all of the benefit of Sublime AND Vim. There's plenty of benefits to using Sublime over Vim, and vice-verse. This way you can have the best of both worlds. There are already Sublime plugins that do this, but they are kind of lackluster to be honest.
Lots of vim stuff is implemented in emacs lisp and there are a few different efforts to emulate the unique parts of LightTable and Sublime into emacs. It just comes down to preference. I enjoy using all three, but emacs is the one which has everything I personally need.
I split the difference. I use Vim if I'm in a server somewhere or if I'm already looking at the command line for git or ag or something. I usually use Sublime when working on a whole project at once.
I certainly don't begrudge you your workflow, it just doesn't match mine. I manage my entire project from a combination of vim and shell, to the point of running my tests from my makefile and making sure error messages have meaningful (in so far as is possible) file:line: info in a format vim will understand so I can easily jump to meaningful pieces.
Vim-mode on emacs probably uses an internal emulator and doesn't slave a real Vim instance to do the work.
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.
Just installed it on ubuntu using sublime text 3 (installed from sublime-text_build-3047_amd64.deb). I get into vim mode when creating new files; however, when opening existing .py files on disk I don't get the vim editor.
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.