1) I find it easy to use split windows in ST (Cmd+Alt+2). I mostly use a fixed 2 column view though, Vim provides much more dynamic window management options. But I really can't work comfortably on large projects where I have multiple buffers open on multiple windows and stuff. I could not get used to Vim's "each tab is a workspace" approach. I like my tabs to be buffers.

2, 3) Nowhere near Vim's terminal integration, but you can use https://github.com/misfo/Shell-Turtlestein plugin to run arbitrary shell commands. It can even pipe in the current buffer and pipe the output into the buffer.

There are plugins for common stuff like ssh or git but you are right while working on vim, context switches are cheaper. Not with ST. As an example, I used subl as my default editor in shell, for a while. Git would fire up an ST window for commit message input or interactive rebases. Each time, my mind had to comprehend what just happened. With vim, I just handle the input and continue my work, without even noticing it.

I'm glad I read your post because it helped clarify the editor debate for me. What you describe is not programming but systems administration and Vim sounds perfect. I never understood why people need to go so fast. Me, I'm happy moving the mouse to an insertion point every few seconds after I've pondered the code I'm writing.

As for Sublime, I won't use it. It's not open source and does not give any thought at all to security issues involved with downloading remote package code and executing it, at least not last time I checked.

Pardon me but I call it development, not systems administration. I know enough about being a sysadmin to know that I am definitely not one. I just consider myself a full stack developer; a very far cry from systems administration.

To be fair, Sublime itself doesn't do any downloading of remote package code. If you install the (admittedly very popular) plugin to do so, well, hard to blame the core editor for that.

I can blame them for opening a giant security hole without a word of caution.

> 3) Since Vim runs in the terminal, it means that I can, very easily, perform many things without having to use the mouse or alt-tab once. Uninterrupted workflow is extremely important to me as a developer who tinkers with the entire stack:

I have a stupid, but related question for the smart people of HN.

I find myself using Vim in the terminal, instead of GVim, for the same reason: Ctrl-Z works, Ctrl-PgDn to the next terminal tab (and back: Ctrl-PgUp) works, it doesn't pop up a new window when I run it, etc.

But GVim has much nicer colors (I picked my favorite out of about 50 themes), and I can't get Vim in a terminal to look more than halfway decent. In the terminal, colors are more distracting and hard on the eyes.

Is anyone aware of a way to get the best of both worlds, i.e. true-color colorschemes in Vim in a terminal? To partially answer my own question, KDE's Konsole seems to support true color[1], but before I install it I'd be curious to know if Vim even works with that feature, and if there are any other, preferably GTK-based, true-color terminals out there.

[1]: https://github.com/robertknight/konsole/blob/master/user-doc...

1. Make sure your terminal advertises itself as supporting 256 colors. $ echo $TERM should output xterm-256color

2. Find yourself a nice 256 colors-ready colorscheme.

3. Enjoy.

If you can't find a 256 colors-ready colorscheme that suits your needs, you can use a Vim plugin called CSApprox to convert a GUI colorscheme for use in a 256 colors terminal.

ZyX as written a patch to allow Vim to play well with that feature in Konsole. You could try it: https://bitbucket.org/ZyX_I/vim/commits/9c4ad944627dc19bd898...

Check out http://www.reddit.com/r/vim/comments/17941z/is_there_any_way...

Thanks! This is the only response that actually answers the question. I'll try Konsole with the linked vim patch.

Yeah - you basically just need to get xterm (or whichever terminal em you are using) to run as 256 colors:

My solution is to place this in my .bashrc

# begin code if [ "$TERM" == "xterm" ]; then export TERM=xterm-256color fi # end code

Of course the terminal should be 256 color terminal. Hope this helps.

The problem with that is it's still only 256 colors, which likely doesn't include all the colors in my preferred colorscheme. That's why I'm looking for "true-color", which typically means 16.7 million colors like we are used to (e.g. #rrggbb in CSS), not 256.

I am using vim in tmux inside a terminal (iTerm2) and I was also unhappy with how vim looked in the terminal so I've made a colorscheme (https://github.com/adrianolaru/vim-adio) especially for this setup. Check it out, maybe you'll like it.

I ran into the same issue with vim in a terminal. I decided to give gVim a try and I really like it. I used to use the sp and vs commands but now find myself using the tabbed windows in gvim. Try typing :tabnew for a new tab and gt for cycling through them.

Accessing vim from ssh is a definitely a benefit for those who use it; especially with GNU Screen since you can suspend, resume or even share a terminal session with someone else.)

I do like sublime text when I'm working with others, so they can take the driver's seat from time to time. But when I'm working alone, I stay in the terminal because screen+vim allows me to stay in a single environment for all of my work.

The SFTP plugin for Sublime allows me to operate on remote files via ssh/sftp quite easily. Set up a local directory with a simple config file with the remote server and file path, and it takes care of the rest. When opening a file, it will automatically sync it down from the server, and when I save the file, it automatically pushes it back up to the server so I can immediately test it from there. And because I keep a dedicated terminal session up, it's a simple alt-tab to switch over and test my changes.

The best of both worlds, if you will.

You know you can use Vim to edit remote files locally, right? Or use it from any graphical FTP client?

If I'm going to run my editor locally, why not use something that's better fitted to running in a graphical context, rather than something limited to the terminal?

I use both GVim/MacVim and CLI Vim in exactly the same way.