As a text editor, I can agree that SublimeText is an absolutely gorgeous product. As a Vim user, it didn't take me long to realize it wasn't for me.
For me, SublimeText still feels like I'm using a program external to the system I'm developing on. It doesn't feel like it's quite close enough to the bones of the system to me.
I know that a "feeling" isn't really the best argument, so here are a couple things that are more concrete to attempt to explain it:
1) I haven't found an implementation of the ease of which it's possible to split your editor quickly and easily. :split or :vsplit and :tabf are all commands I use frequently to not only open files when I need them, but browse the filesystem quickly and easily.
2) Running external commands. While I understand it's possible to run external commands with a key binding in SublimeText, I can simply drop into a shell (:sh) or execute a command :! with just a few keystrokes in Vim, whenever I want.
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:
SSH into a remote box, manipulate some files and tail a log file for an error, locate a file, edit it in Vim, hop into PostgreSQL to perform some queries, fire up a local development server, test an HTTP response, see that it works, create a quickfix file for all the changes, open them all in Vim, recheck everything, push my changes up, restart the services, monitor the server with the changes in place, ensure things are good, and exit.
I can do that all within the comfort of the terminal, where Vim runs for me.
To reiterate: I agree that SublimeText is a beautiful editor, but I don't see how it could possibly replace the availability of Vim in my workflow.
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.
> 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. 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.
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.
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.
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.
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've tried Sublime Text several times, but each time I went back to Vim. The Vintage plugin just does not cut it for me; there're too many things that Vim does, that Sublime cannot do. I couldn't live with EasyMotion, RelativeNumber, the fantastic split window support, Gundo (Undo Tree), and much more.
Regarding the plugins he mentions, I see nothing special, all of that is also available as Vim plugins:
5. Vim Compatibility (Obviously in there)
4. Keybindings in JSON are indeed nice, though imap / and friends in Vimrc are ok, too. Using Vim+Python, one can also write Vim plugins in Python (import vim).
3. Vundle (https://github.com/gmarik/vundle) is a fantastic package manager and reads GitHub repositories likehttps://github.com/vim-scripts. Adding a new package is as simple as doing
:Bundle 'vim-scripts/YankRing.vim'
:BundleInstall
or :BundleSearch foo to find what's available.
The listed plugins:
Git -> try Fugitive.vim it is awesome
Emmett -> Also available for Vim
SublimeLinter -> Syntastic
SublimeCodeIntel -> Clang Complete
2. Vim has built-in support for sessions via the :mksession command. Or, just use the session.vim (https://github.com/xolox/vim-session) plugin, because it makes it even easier.
I recently made the switch from Xcode to Vim (I mostly do Objective-C these days) by getting Clang Complete running (http://appventure.me/2013/01/use-vim-as-xcode-alternative-io...) so that I can use Vim full time and not only for web and python stuff. I couldn't be happier.
I'm curious, but what's your workflow re: Obj-C development? I only dabble, and for me the vim-xcode bindings are enough but mainly because I don't find myself on the command line much during an XCode session. The built-in shortcuts are all easy enough so that I don't have to use the mouse much either except to use interface builder.
Second, can you share a little on your #4? Aside from the aforementioned Obj-C dabbling, I use vim for almost everything. There are so many awesome plugins that do just about everything I could ask for and therefore I have yet to do any plugin writing myself. Having seen the usual complaints around VimL, what's the deal with external scripting support? I compiled with +python and +ruby since that's what I'm familiar with for plugins, scripts, etc. and a few plugins I have did require one or the other but are there any downsides? Most of t-pope's plugins appear to be straight VimL which makes me wonder.
Apologies for being an idiot, but I'd certainly appreciate some enlightenment.
It is less about the command line, and more about being able to use all of Vim's shortcuts and commands. I am magnitudes faster moving through a big code base in Vim than in Xcode. Even the split window support in Xcode sucks. Apart from that I find Xcode bloated and slow. Back in the Xcode 3 days, the speed was reasonable, but with 4 it became slow. Even worse, if you're on battery, Xcode's constant indexing and whatnot will drain the battery really fast. I've just made the switch to 100% vim a week ago, so far everything feels way better, and coding is so much more fun, but I guess I need more time to really assess it.
For plugins, I think it is simply a case for familiarity. If you already know Python and its packages or Ruby and its library inside out, learning another new language, which has no use outside of Vim might seem like not worth it.
Sublime does have a really strong plugin ecosystem, and I reason that this is because it is so much easier to write a new plugin for something that irks you if you don't have to learn a completely new language first.
Also, the plugin quality should be better because obviously when you use python every day, the quality of your code is higher than when you just learned VimL and only learned it for this one plugin.
I've tried them and I found them too constraining. In Vim I can split any window vertically or horizontally just with a command, without ever having to reach for a menu. Also, with the Zoom plugin I can fullscreen any of these, and then go back to the split. I'm pretty sure that Sublime has really good split support, I guess I'm just spoiled by the plethora of options that Vim offers.
Don't forget peepopen for the file finder -- thats about the closest thing to sublime texts command+t (it's a separate app that opens up. I love it way more than fuzzyfinder or any of the text based finders)
I still have only used sublime text once, but I might try it out again soon just to get a better idea of what these features are that make it so much better. And them I'm going to add them into vim.
I think that it is a serious problem that sublime text is proprietary. While it does support plugins, the one time I did use it I remember seeing several messages from plugin authors complaining that the sublime API does not support certain features that they wanted it to support, and that the sublime text authors refused to implement them. So to that effect I really think there is no benefit to using a proprietary text editor, no matter how many flashy features it has. I would rather just improve vim (and encourage others to do so) so that it is better than sublime text.
It also seems somewhat strange that sublime is proprietary considering how lax their licensing policy is. It doesn't seem to me like there is any financial or practical reason for it to be proprietary. To channel Stallman, the only thing I can reasonably conclude is that the author intends to attack his own users. It really disappoints me to see that this kind of project is being promoted as a replacement for free software editors.
I don't want to be "that guy" but the only thing really stopping me from switching is the lack of an ARM Linux client. Heck, I'd even be willing to do the work on it, but until I can use the same editor across all my machines, I'll stick with vim. It ain't perfect but I can put it on all my machines (and the Chromebook even comes with it, just have to switch to developer mode to get access to it.)
But ST does look quite nice, I've played with it a few times, but never really seriously looked at it.
it's funny how people praise Sublime Text when plain old Emacs can do most of the things that Sublime Text can:
> 5. vim compatability!
evil-mode - a very advanced vi layer for emacs, probably much better than vintage, I hear only good things about it although I use the standard emacs mode
> 4. Powerful Keybindings in JSON and Plugins in Python
there are many modes that support that if you want it. I personally don't like it though. "projectile" is pretty nice though: https://github.com/bbatsov/projectile
Also perspective-el: https://github.com/nex3/perspective-el is fantastic for switching between multiple projects / window configurations giving you something like project sessions.
That's my biggest issue with Emacs: there are more than one million lines of elisp in circulation.
There isn't going to be any text editor come anywhere close to that.
I need something "programmable" so I'm "stuck" with Emacs.
I'm a bit bitter because sometimes (often actually) I wish Emacs was multi-threaded, easier to interface with externals tools (to make it a bit more like an IDE) -- that is, able to quickly invoke external tools without blocking everything etc.
But I realize that Emacs is soooo big that it's probably going to take a long time before we see a "modern" Emacs.
Sublime Text is awesome, but the article falls completely flat by mentioning stuff that's actually in vim and missing the parts that are not.
5. vim compatability!
> With a few tweaks, I was able to make it just like vim as far as I could tell
It took me five seconds to hit walls and off-by-one issues revealing Vintage mode as a remote simulacrum of Vim. A look at the source confirmed that it's just a mode emulation and a small bunch of keybindings, a far cry from the notion of text objects which makes Vim what it is. I am a vim user, but I use ST without Vintage because the impedance mismatch is too big.
> minus some :commands
Author doesn't mention VintageEx. Still thouroughly lacking, even for basic stuff.
4. Powerful Keybindings in JSON and Plugins in Python
:help index lists default keybindings
:verbose map lists all set keybindings, what they do and where they've been set.
With Vim (vim --version will tell you), depending on compilation options, you can write plugins in various languages (python, perl, ruby, lua, tcl...), not just vimscript.
hot-load: :source ~/.vimrc or whatever other file.
3. Package Manager and the More Centralized Community
vim.org/scripts[0] is the central place to look for.
Pathogen and Vundle fix that. Package Control give you a central, automated and in-editor index, which I'm not sure is a real plus since I care about installing plugins once in a blue moon, so that's merely a convenience. Besides I've had Package Control bork ST more than once on upgrades (either of ST or of itself), so I'd rather have it outside.
2. Project Sessions
:mksession is what you want. Bind it to a key[1], or be creative in your vimrc.
Also, automatic restore[2] when there's one around and you boot with just vim in the project directory.
1. Ctrl+P - GotoAnything:
For the function mentioned (fuzzy search for files), there's a plugin of the same name.
The author again fails to mention what makes Sublime Text supposedly stand apart: Go To Anything goes to anything, not just files, so symbols (with @symbol) and lines (with :linenum) are reachable from a single shortcut.
I don't want to sound mean, ST rocks and has a number of good things I miss in Vim, but they're not among this list. In fact it's good enough that I contemplated doing a real Vim mode with extensible text objects (hence why I looked at the Vintage source).
Is this supposed to be funny or what? I don't know Sublime, it probably has some unique features but I don't see even a single feature like that in this list. It's all - including point 5, VIM emulation mode - pretty much expected from any modern editor. The last thing I used before switching to VIM was Komodo IDE, which had everything mentioned in this list (and more because of the "IDE" part, but that's irrelevant). I don't know for sure, but I suspect things like Eclipse or Visual Studio these days have all these features too.
Really, we should stop saying that one particular tree is especially great because it has green leaves. I sincerely believe that there ARE innovative, interesting features added to many editors but I just don't have the time to dig through tons of obvious things to read about the single feature that sets given editor apart. I'm glad and happy that your editor does syntax highlighting, code folding, autocompletes words and has a plugin system, it's obvious, now can we move to the interesting part?
So… we have a guy with what looks like a limited experience of tools A and B writing an article full of hyperbole and factually wrong on how tool B kills tool A.
Yes, tool B is a good tool. However I can't imagine a single reason why anybody with a sizeable experience of tool A switch to tool B.
Newcomers who turned to tool A because it was trendy last year but never got the hang of it, on the other hand…
Other than the central repository (which vim does lack, there are quite a few plugins I'll admit), I don't see anything too different from vim, or am I just missing something. not trying to be mean spirited, just curious.
You have almost everything VIM is awesome at + nicer non terminal based UI niceties. Plus its really really fast. You get the code wall, really good window manager, better project management and its also cross platform.
Gvim has a lot of awkward hangups, in my opinion. Selecting text is still weird, there's no context menu, etc. It's vim outside of a terminal, which is great, but most full-fledged graphical editors take better advantage of their environment than Gvim does.
I agree with gvim being a bit basic. If you're on OSX, I think MacVim (http://code.google.com/p/macvim/) is a much better choice. On Linux, I use terminal vim and rely on the terminal for environmental integration: you can choose from a dozen X terminals that will do almost anything you want.
I've been a pico/pine user for almost 20 years and on OSX ST2 has been my editor of choice for the past couple. I decided just this past week to force myself into getting to know vim better because I hear how powerful it is.
Once you get a decent .vimrc going, it can be configured to be as good/better than ST2. Its free. Its cross platform. Its easily usable over SSH.
I have been using vi/vim since 1989, and I found spf13 to be a totally frustrating experience. Twice I tried it out and quit. It messes with settings of neocomplcache (issues reported and verified with authors), it installs plugins like autocomplete (??) which can also be frustrating. I had hunt through the source of some 20 or more plugins to figure out the offending ones and remove them.
However, that's just my experience. I'd suggest he try a clean vim and add plugins as he needs them. There are plenty of links suggesting great plugins for developers. "sjl" (steve losh) has an article which was linked here (Coming Home to Vim) that mentions some good plugins.
The reason that I suggest spf13, is because it shows what's possible. I spent nearly a year building up a set of plugins and settings only to discover that 95% of what I had "discovered" was included.
I'm sure it has it's problems, but you can easily remove all of the included bundles. I think at the very least it provides a well structured foundation to built upon.
I've been studying other's .vimrc files in an effort to understand what all vim vanilla is capable of. Once I get that dialed in, I'll look into plugins for my local box; I just want to make sure that I can use it effectively just by firing up any new VM.
Also, I'm being sacrilegious and setting myself up for primarily --INSERT-- mode, since its the most like a GUI text editor. Its making the barrier of entry slightly more endurable!
This will get you to stop using the arrow keys for moving around, use either hjkl, or faster combinations such as "f" "t". Hope you get out of insert mode soon!
As a text editor, I can agree that SublimeText is an absolutely gorgeous product. As a Vim user, it didn't take me long to realize it wasn't for me.
For me, SublimeText still feels like I'm using a program external to the system I'm developing on. It doesn't feel like it's quite close enough to the bones of the system to me.
I know that a "feeling" isn't really the best argument, so here are a couple things that are more concrete to attempt to explain it:
1) I haven't found an implementation of the ease of which it's possible to split your editor quickly and easily. :split or :vsplit and :tabf are all commands I use frequently to not only open files when I need them, but browse the filesystem quickly and easily.
2) Running external commands. While I understand it's possible to run external commands with a key binding in SublimeText, I can simply drop into a shell (:sh) or execute a command :! with just a few keystrokes in Vim, whenever I want.
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:
SSH into a remote box, manipulate some files and tail a log file for an error, locate a file, edit it in Vim, hop into PostgreSQL to perform some queries, fire up a local development server, test an HTTP response, see that it works, create a quickfix file for all the changes, open them all in Vim, recheck everything, push my changes up, restart the services, monitor the server with the changes in place, ensure things are good, and exit.
I can do that all within the comfort of the terminal, where Vim runs for me.
To reiterate: I agree that SublimeText is a beautiful editor, but I don't see how it could possibly replace the availability of Vim in my workflow.