Actualvim – Sublime Text 3 input mode powered by Vim itself | Hacker News Reader

Actualvim – Sublime Text 3 input mode powered by Vim itself

github.com

107 pointsjkarni111 comments

Author here:

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?

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

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.

[1] https://github.com/ervandew/eclim/issues/100

Oh, that's awesome. I didn't think of using it like that.

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!

Very interesting. Thanks for relaying that.

The picture on this page answers my question: http://eclim.org/

VT100 embed is their third mode.

This makes me want to ask... why not just use vim?

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.

and then there is this: https://github.com/fatih/subvim sublime in vim :-)

or vim in emacs: http://www.emacswiki.org/emacs/Evil

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

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.

You never have to click anything in sublime

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.

That's actually not true - vim does let you use your mouse: http://vim.wikia.com/wiki/Using_the_mouse_for_Vim_in_an_xter...

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.

The main reason (for me) is Ctrl+P. Working on a project with lots of files (like Rails) without that is a huge pain.

Not only does Vim have a Ctrl+P plugin, but the Ctrl+P feature of Sublime originated from the Vim plugin.

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.

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.

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.

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. :)

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.

As long as it can parse my .vimrc (but then, that's vimscript)

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.

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.

[^1]: https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

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:

https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_...

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.

> https://groups.google.com/forum/#!searchin/vim_dev/kans/vim_....

[...]

This has been acknowledged and even patched as you surely know. So what are you complaining about exactly?

I didn't know it was patched.

https://groups.google.com/forum/#!searchin/vim_dev/set_last_...

Cool.

But this thing is Vim.

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.

Nope, no +server in default OS X CLI Vim. I'm actually using a combination of their NetBeans communication protocol and raw tty output right now.

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.

Oh, I misread that. Thanks and sorry.

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.

[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)

[5](https://github.com/Shougo/vimshell.vim)

[6](https://github.com/Valloric/YouCompleteMe/)

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

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.

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.

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.

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

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.

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.

You are quite wrong, on any given day vim dev's mailing list has recent seg faults at the top of its list.

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 ?

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

This is the first time I see someone using "ad hominem" when they refer to (apparently valid) critisism of software quality.

I've certainly seen people being passionate about software but this is new. ;)

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.

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.

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.

Might I suggest using the text editor for editing text?

It seems rather silly to complain about missing functionality that doesn't achieve the tools core value prop.

That's a point of view.

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?

Because this happens when you open a large file in Vim

http://i.imgur.com/erVrk5j.png

Better question: why not emacs with evil mode?

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.

Ditto, in Visual Studio. I use viEmu a lot, but it has strange behavior sometimes and missing features.

It's still the best vi emulator I've found. If you know of better ones, I'd love to hear about them.

Check out VsVim. It's pretty solid. http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-...

VsVim's implementation is very complete. http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-...

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

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

0: https://github.com/guillermooo/Vintageous/ 1: https://github.com/kylefinley/dotfiles/blob/master/sublime/U...

Edit: formatting

Why wouldn't I just use Vim (or better yet, Emacs) in the first place?

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.

http://www.emacswiki.org/emacs/LightTable

http://www.emacswiki.org/emacs/MiniMap

http://www.emacswiki.org/emacs/Evil

https://github.com/emacs-helm/helm (go to anything)

I've said this elsewhere in this thread, but—

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.

There do seem to be things that Sublime does better, but some of us don't want chrome. I work mostly in terminals in ratpoison for a reason...

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.

Chrome can be hidden. That's what I like about it, it has heavy built-in customization.

Yes, but addition of chrome that I then hide isn't better chrome (for me).

Multiple selections has been the killer feature for me, which is the only thing I haven't found a good replacement for in Vim or Emacs.

Have you seen https://github.com/terryma/vim-multiple-cursors and block cursor mode in Vim (ctrl+v)?

And of course... https://github.com/magnars/multiple-cursors.el for emacs folks (I use it every day...)

This is like using vim-mode on emacs.

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.

Can you report this on the issue tracker? https://github.com/lunixbochs/actualvim/issues

Also can you check the console when opening a file to make sure there's no error?

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.

https://github.com/scrooloose/syntastic

Huh, do the syntax checkers for those languages actually do type checking too?

For C and C++ at least, it uses your compiler, so yes.

For Haskell too, with ghc-mod[1].

[1] https://github.com/eagletmt/ghcmod-vim

Syntastic is great for flagging syntax errors, but I don't think it provides for type checking like DannoHung is after.

Actually, it does: http://cl.ly/image/2Z2U080T0L2A

Sublime Text in-editor linting is one of my projects too (sublimelint/SublimeLinter).

Reply on news.ycombinator.com