How SublimeText Bodybags vim+Terminator | Hacker News Reader

How SublimeText Bodybags vim+Terminator

ngokevin.com

53 pointsngokevin67 comments

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

[0]: http://www.vim.org/scripts/index.php

[1]: https://github.com/lloeki/vimfiles/blob/master/rc#L158

[2]: https://github.com/lloeki/vimfiles/blob/master/rc#L257

So what would your list look like?

Generally speaking (not specific to ST), "vim compatibility" is a vicious tease.

That is one of my biggest issues when trying another editor, the vim compatibility is great, until it isn't.

Great article.

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.

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.

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

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

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

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

1. There's CommandT (https://github.com/wincent/Command-T), CtrlP (https://github.com/kien/ctrlp.vim), Waldo (https://github.com/jtaby/Waldo), FuzzyFinder (https://github.com/vim-scripts/FuzzyFinder). And most offer much more functionality than just file, directory, or buffer search.

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.

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)

ST also has split window support. http://d2wwfe3odivqm9.cloudfront.net/wp-content/uploads/2012... or

http://d2wwfe3odivqm9.cloudfront.net/wp-content/uploads/2012...

etc. You can even define custom layouts.

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.

You can split with a command in Sublime: cmd+alt+[1,2,3,4,5...]

Also there are plenty of plugins that add shortcuts for arranging/organizing/moving within them.

Just installed this new EasyMotion plugin. Works well!

https://github.com/tednaleid/sublime-EasyMotion

Cool, didn't know about that

Thanks, glad you like it!

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

This. I'd love Sublime on a Raspberry Pi (or on my phone, once it's running Ubuntu).

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

powerful keybindings

  (global-set-key (kbd "<f2>") 'split-window-vertically)
  (global-set-key (kbd "<f3>") 'split-window-horizontally)
  (global-set-key (kbd "<f4>") 'delete-window)
  (global-set-key (kbd "<f5>") 'delete-other-windows)

and modes (plugins) in Elisp

> 3. Package Manager and the More Centralized Community

since Emacs 24 a package manager is included and there are awesome repos for all of your needs:

    (setq package-archives '((     "elpa" . "http://elpa.gnu.org/packages/")
                             ("marmalade" . "http://marmalade-repo.org/packages/")
                             (    "melpa" . "http://melpa.milkbox.net/packages/")))

after that run

    M-x list-packages

and choose from around 1000 packages

> 2. Project Sessions

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

> 1. Ctrl+P - GotoAnything:

helm is what you would use on Emacs: https://github.com/emacs-helm/helm

it's awesome

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.

> I'm a bit bitter because sometimes (often actually) I wish Emacs was multi-threaded

Tony> - Is multi-threading coming to emacs 25?

I don't know about Emacs 25, but I did manage to merge trunk to the concurrency branch today. If you're interested you could try it out.

http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg004...

it looks like Emacs should soon (?) support concurrency

Also perspective-el: https://github.com/nex3/perspective-el is fantastic for switching between multiple projects / window configurations giving you something like project sessions.

I think trying to convert vim users is pretty futile. /r/vim/ brought up a lot of issues with Sublime's vintage mode:

http://www.reddit.com/r/vim/comments/17i5ps/from_a_vim_persp...

I don't think these current features + plugins 'body bag' vim. For instance, is all of this vim 'body bagging' goodness available to you over SSH?

I agree, work over ssh or go home.

I am pretty sure I will be using Vim when Sublime goes the way of Textmate and SlickEdit.

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…

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?

No, these are not things that 'bodybag' vim at all.

But isn't it interesting that people talk like this, even if they are wrong? Whoever talked about UltraEdit or BareBones in this fasion?

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.

  Non Terminal Based UI Niceties: Use Gvim
  Cross Platform: So is vim/gvim. I use vim on Mac/Linux/Windows.

I love both vim and Sublime, so I would call 'Bodybagging' is flame-bait at best.

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.

Is the the central repository you're looking for?http://www.vim.org/scripts/index.php

I know about vim scripts, I just don't think the process is as smooth as sublime's package control

This is true. Pathogen, a vim package manager, is mentioned elsewhere in this thread.

Although not as smooth as Pathogen, installing most vim scripts is as easy as extracting the download into your .vim directory.

Vundle works nicely as a package manager:

https://github.com/gmarik/vundle

And just wait until Sublime 3 is ready.

http://www.sublimetext.com/3

Which negates all plugins until they are updated.

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.

So at least for me, vim > st2/st3.

Sorry, pico/nano.

If you are just staring with VIM, I recommend taking a look at spf13-vim (https://github.com/spf13/spf13-vim)

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.

Thanks for the tips!

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!

Sooner or later someone is going to tell you to put this in your .vimrc:

    inoremap  <Up>     <NOP>
    inoremap  <Down>   <NOP>
    inoremap  <Left>   <NOP>
    inoremap  <Right>  <NOP>
    noremap   <Up>     <NOP>
    noremap   <Down>   <NOP>
    noremap   <Left>   <NOP>
    noremap   <Right>  <NOP>

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!

[rewrite] Sadly, I stil can't be near as fast in making changes across several files as I'm in ST/Emacs...

And when I finish installing all the plugins, I can't claim that my vim works everywhere.

However "X" body bags Vim, I will never switch.

:%s/SublimeText/Sublime Text/g

Reply on news.ycombinator.com