Extreme Productivity with Screen and Vim | Hacker News Reader

Extreme Productivity with Screen and Vim

airodig.com

41 pointsfeydr61 comments

I didn't care for this video. I thought it was light on content and the narrator had some pretty annoying mannerisms.

"...cuz you know, like back in the day we didn't have fancy X-windows where we could you-know move around and play on the web and look at porn and shit... so it was uh...you know, I mean... screen... but screen is still definitely, you know.. something that is really good to use."

I do however agree with him that screen and vim are both pretty kickass, I just think he could have done a better job showing why.

I was surprised at how much the swearing and hesitating grated on me. I'm usually the first guy who wishes presenters would lighten up and joke around a little, but for some reason I couldn't stomach more than 3 minutes of this video. I just kept thinking, "Man... this is really unprofessional." I hope they don't revoke my sarcastic hippy license...

I'm actually kind of jealous that it's got 26 upvotes on the frontpage. That's a lot! I love vim and screen with all my heart; maybe I should make a video like this, too. I feel like I could do them justice better.

I would watch such a video if you made one.

yeh, apologies to anyone who finds the way I talk offensive -- this is how I talk 'normally' 24/7 -- anyone who has ever met me knows this is how I talk -- kinda surprised so many people get offended by it considering 70% of the internet...

anyways, your right, I should have organized my thoughts a bit more before getting into this -- I tried writing them down on a notecard beforehand but eventually I was like 'fuck it'

Yeah dude, I gotta say that it could have been pulled off better in that respect. It's not that I was offended--I curse all the time, depending on context. It's just that the stutters and "shits" didn't really add anything, and made it all harder to follow. I say, if you can drop the f-bomb and get an honest chuckle out of your audience, then by all means, go for it. But if it's just usual "filler" crap, avoid it.

I use Eclipse as my main development environment. I'm familiar with vi, I use it regularly for sys-admin stuff, and used it extensively a while back in college.

As far a text-editor goes, I'm 100% sure that vim/emacs power users are extremely productive (And I'll wage that this video isn't the best example of productivity vs. a GUI).

What I haven't been able to figure out though is the workflow of vim users when working on real projects, not a single source file.

I rarely spend a lot of time writing code in a single file. I often have to navigate the project folder structure to look for stuff, I need to compare files, work with the source control and so on.. all of this I feel I can do pretty efficiently from within Eclipse.

So how do vim/emacs users do? I presume it's all command line and a lot of typing. Am i wrong?

> So how do vim/emacs users do? I presume it's all command line and a lot of typing. Am i wrong?

It's not much typing, and it's definitely faster than switching to a mouse. Both vim and emacs have plugins for easily browsing file systems, and through trees of source code. I personally use a separate terminal window for source control, but that can easily be integrated as well. It's probably a similar workflow to what you're doing now, just without a mouse, and with different key bindings.

We generally use Unix as our IDE, yes, but it doesn't involve a lot of typing.

Emacs users can also do everything from within Emacs.

In Vim, FuzzyFinder (http://www.vim.org/scripts/script.php?script_id=1984) makes it really easy to flip between files.

That, and once you learn Vim frame management, you become a lot more productive on multiple files.

And NERDtree. http://www.vim.org/scripts/script.php?script_id=1658

And PeepOpen if you're on a Mac and using MacVim http://peepcode.com/products/peepopen

I prefer LustyExplorer. The only downside is that they both require ruby support in Vim (some some of our work servers vim only has perl and python scripting support).

Both vim and emacs can split (either horizontally or vertically) to show as many files as your typeface can usefully cram in. As a greybeard, I learned the vim predecessor vi, which didn't have that ability, then learned emacs, which at the time (1984) did, so my calcified reflexes use vi first (because there aren't any more Unix boxes that don't have it) but switch to emacs as soon as I'm going to want more than one file on the screen - since (in my environments) emacs is everywhere that vim is, and I haven't taken the time to learn the Vim way to do things. In my opinion, emacs and vim are both superb editors, but both need time spent to get reflexes into your fingers to operate - i.e., they're both "expert friendly", and perhaps "casual hostile".

  set wmh=0
  set winheight=1000
  map <C-j> <C-W>j<C-W>_
  map <C-k> <C-W>k<C-W>_
  map <C-h> <C-W>h<C-W>_
  map <C-l> <C-W>l<C-W>_

This is the first stanza of my vimrc. I use :sp and :vsp a lot. My capslock key is mapped to behave like left control. The result is moving between files is a matter of holding capslock and pressing hjk or l. I argue it's a lot faster than using a mouse or even control and pageup/down in a tab-based IDE. For opening new files, tab completion is a godsend, and then there's other bonuses to using vim, like :!grep "def functionImLookingFor" lib/*.py and, when I'm sifting through logfiles for patterns, :%!grep has become one of my most often used tools.

Any reason you're using :!grep rather than the built in ctags support? I've found the latter to be very useful but maybe I'm missing some functionality.

Most of the time I'm not searching for function definitions across the whole base. This is just an example.

That, and I haven't really fooled around with ctags much, though I've been meaning to for the longest time. No time like the present, I guess.

"So how do vim/emacs users do?"

vim - ctags for class/method navigation - fuzzyfinder for buffer/file system navigation

This is pretty effective, ctrl-] takes me to the definition of any symbol. And with the appropriate plugin I get the same quality tab-complete I'd get with an IDE. If you need even deeper exploration, cscope will allow you to find files which include this one, all calls to a given function, etc. But never underestimate a simple `find | xargs grep`. I'm currently learning a ~4m line code base using these methods and haven't had real problems yet.

I will agree that out of the box vim/emacs aren't set up as an IDE replacement. But since you're investing so much time in learning vim modal concept or emacs bindings, the added effort to customize your editor for what you do is a drop in the bucket.

Emacs probably doesn't have the best support out-of-the-box to navigate a project, but it can be done with speedbar and ECB [4]. Alternative ways to get around source code include using dired, the directory editor, the various grep commands [5], and some form of tags (I like to use exuberant ctags [6]).

To give examples for the things you mention, emacs has an interface for version control that works consistently with CVS, Subversion, bzr, git, hg, and others. And if you need something more powerful you can use a mode for your specific version control system, like magit for git [1] (I suggest you check this magit screencast [2]). Emacs has a built-in mode to compare files (ediff) [3], to compile programs, run interpreters inside emacs, and so on.

You can see a good overview of these features at [7]. I'm sure you can have a similar setup with vim.

[1] http://philjackson.github.com/magit/

[2] http://vimeo.com/2871241

[3] http://tech-rantings.blogspot.com/2008/12/emacs-diff-ediff-t...

[4] http://ecb.sourceforge.net/screenshots/index.html

[5] http://www.gnu.org/software/emacs/manual/html_node/emacs/Gre...

[6] http://ctags.sourceforge.net/

[7] http://www.gnu.org/software/emacs/tour/

I've been hot and cold on emacs over the years. I've used it enough that there is a lot that I really like about it and that I'm annoyed by not having in other editors. But that list of links is the reason why ultimately I have decided to spend my time in a different editor.

Yes anything is possible and people have done work that probably intersects with what you're looking to do. But rarely does anything just work.

I spend too much time try to make things work and re-implementing features that exist in other environments. I tend to use Textmate and Intellij -- although extending Intellij is such a heavy process that I pretty don't do it.

"But that list of links is the reason why ultimately I have decided to spend my time in a different editor."

Actually most of the functionalities I mentioned are available out-of-the-box. Ediff just works. Version control just works. I sent a long list of links so people could have a better idea how these features work. It's true, though, that emacs doesn't have everything out-of-the-box and you need to download and install and configure things, but the same is true for every single editor and IDE out there.

True ediff, vc-dir, and ecb are all in there. And I can only speak for my own work-flow but with each of those I needed to make modifications to have it work in a way that I liked. And ultimately never got to a place where I was totally happy (except with ediff).

I do believe that people have gotten it configured just right and that they are extremely productive with it. But for me there was just always one more thing that I needed to do from change the appearance slightly or override the annoying way that vc-dir takes over existing windows. I end up just wishing that the defaults were a little bit better.

> I often have to navigate the project folder structure to look for stuff, I need to compare files, work with the source control and so on.. all of this I feel I can do pretty efficiently from within Eclipse.

For Vim, there are a lot of plugins to deal with source trees, but I get along fine with Vim's built-in wildmenu and tab completion. Both options are nicely configurable. For emacs, I like ido-mode. I find it much faster to browse a directory and open a file with the keyboard and tab-completed filenames than to use a mouse.

There are also commands to jump to other files to find the definitions of functions and such. It depends which programming language you're using. Vim has `gd` and friends to do the same. And then there's ctags, which integrates with Vim wonderfully. Editing Lisp code in Emacs with SLIME (for example), `M-.` will jump you to a function definition in another file.

For comparing files, it'd be hard to beat vimdiff, which provides built-in, cross-platform colored diffs of buffers. Emacs has a diff mode as well.

For source control, Vim and Emacs both integrate well with Git and others. You can stage and commit files and such via a keystroke or two. But personally I use the command line for git. (Of course you can embed a shell right in Emacs too.)

Vim and Emacs let you use "windows" (panes) instead of tabs for editing multiple files; don't overlook how awesome this is. You can view files side-by-side without having to close or hide one to open another. It frees short-term memory for other things. Once you set up keybindings for opening, closing, resizing and moving between windows, you're set. I haven't found anything faster or easier to use. Finding and viewing a buffer that isn't currently visible again uses tab-completion and is very fast.

So yes, a lot of typing. But typing is more efficient than mousing, I find. That's part of the point of Vim and Emacs to begin with.

I often work on Ruby on Rails projects in Vim with 2 dozen files open, or more, and have a very easy time.

One quick, small tip about Vim's panes(/windows) that most people don't notice right away: not only can you view two parts of the same file at the same time, but you can fold/unfold the code in them independently.

I can have a bazillion files open in emacs and still switch between them easily with ido-switch-buffer (C-x b), which does fuzzy matching on the buffer name.

You may want to try http://eclim.org -- http://eclim.org/vim/cheatsheet.html

* Eclipse projects integration * Ant Integration * Dozens of language / markup integrations -- validation (at minimum) * VCS integration * and more... enhancements of vim built-ins

Something like the vim command-t plugin (https://wincent.com/products/command-t/) can make filenavigation very fast. That, the already mentioned C-j, C-k, C-h, C-l bindings, nerdtree, and bufexplorer (http://www.vim.org/scripts/script.php?script_id=42) and you're set for speedy file navigation. Then when you're comfortable with that there are things like taglist.vim to take advantage of ctags to kick it up a notch further!

I tend to have 3-4 vims open (I hate tabs/overlapping windows, I want everything I'm working on visible!)

I type very, very little and use the mouse even less (which is more important IMO) though because:

Tab completion both in vim and bash shell.

History both in vim and bash shell.

Things like CDPATH are great.

At our company, there are a lot of internal bindings for vim and emacs. You can hit a key combo, and have vim/emacs determine the base class of the perl module you're working on, and open in up in a new buffer. You can hit a key combo to open up the test module for the current module. You can hit a key combo to run the unit test that you're working on, etc.

Vim also has the 'gf' (go-to-file) keybinding while goes to the file under the cursor. It does a good job of being language specific when it needs to be. For example, if the 'file' is a perl module or java package/class it will convert "Text::Utils" or "text.utils" to text/utils{.pm,.java} and search for it in the comma separated list of paths in the &path variable (i.e. :set path). Vim auto-magically imports the perl path @INC or java path into &path (though weird local configurations aren't auto-detected, and you'll just have to write something to inject those paths into &path).

Vim also has things like NERDTree and LustyExplorer that make navigating a dev tree pretty easy.

I use a screen session w/ multiple windows at work on the server, which I attach to every morning. Then I have all of the setup that I was working on the previous day right there in front of me.

Some screen hacks:

* I use grabssh[1] so that I can get ssh-agent forwarding working again when I reattach. ssh into the server, run grabssh, then reattach the screen session. Now all of my shells in the session can source fixssh to update their environment.

* I also use a wrapper for ssh within a screen session:

  function screen_ssh_wrapper()                                                                                                                                             
  {                                                                                                                                                                         
      if [ -n "$STY" ]; then                                                                                                                                                
          HOST=$(echo "$1" | sed -e 's,[a-zA-Z0-9],,g')                                                                                                                     
          if [ -z "$HOST" ]; then                                                                                                                                           
              # Note: We need all of these vars b/c we want the ssh command to                                                                                              
              # inherit them from the current shell, and *not* from screen (for                                                                                             
              # long-running screen sessions, those values may be out of date)                                                                                              
              screen -t "$1" \                                                                                                                                              
                  env \                                                                                                                                                     
                      SSH_CLIENT="$SSH_CLIENT" \                                                                                                                            
                      SSH_TTY="$SSH_TTY" \                                                                                                                                  
                      SSH_AUTH_SOCK="$SSH_AUTH_SOCK" \                                                                                                                      
                      SSH_CONNECTION="SSH_CONNECTION" \                                                                                                                     
                      DISPLAY="$DISPLAY" \                                                                                                                                  
                      ssh "$@"                                                                                                                                              
              return                                                                                                                                                        
          fi                                                                                                                                                                
      fi                                                                                                                                                                    
      ssh "$@"                                                                                                                                                              
  }                                                                                                                                                                         
  alias ssh='screen_ssh_wrapper'

[1] http://samrowe.com/wordpress/ssh-agent-and-gnu-screen/

interesting fix to this problem!

It looks like the server just died. The post is mostly this video:

http://vimeo.com/14481789

Cache: http://webcache.googleusercontent.com/search?q=cache:http://...

If you want to learn some extremely useful tips for real productivity in Vim, I'd suggest the detailed videos on http://vimcasts.org/ over this frenetic if enthusiastic video.

I've been using tmux instead of screen lately. It's nice to have window splitting built in. http://tmux.sourceforge.net/

It's also what the OpenBSD team uses, and has been given a good security audit.

I use emacs for splitting so I don't generally need this feature. Actually most of my screen sessions only have a single window with emacs in it. I use screen mainly to attach and detach sessions.

You might like dtach -- it's a program that just lets you detach/attach sessions. It's simpler than screen, so if that's all you use screen for you might like it.

http://dtach.sourceforge.net/

If you're a vim user on a mac, try out ViKing. http://vikingapp.com

To those suggesting Vim/Emacs require less mouse usage than an IDE: I see little more than anecdotal evidence to support this. I personally use Visual Studio extensively in combination with the ViEmu pluggin, and I'd like to think that doing so is both more productive and utilizes the mouse less than a combination of screen/vim would. After configuring keyboard shortcuts, there is almost nothing I need to use the mouse for in Visual Studio. I get the benefits of using Vim plus I get the additional benefits of code completion, project management facilities, debugging utilities, and much more.

Honestly, I fail to see the advantage to this approach.

I didn't watch the video, based on some of the other responses here (I do not have time for the presentation fluff), but I hope he made mention of slime.vim. If not, I will toss in a quick plug for it --

Want to quickly send blocks or lines of code to REPLs (and sometimes the command line) in your other screen windows? slime.vim is a vim extension that copies text from your vim session and pastes it into the screen window of your choice.

I use screen sparingly (when it matters (remote long running process that I need to not die just cause Comcast Cable sucks ass and drops my internet) but would never use it "all the time" Fucking with Ctrl-A and my scroll back constantly pisses me off. And the advantages aren't worth learning how to remap Ctrl-A which I'm told is possible.

Most things that are worthwhile have an up-front cost/learning curve. To dismiss something just because you have to take the time to learn about it first is a ridiculous concept.

Personally I have the 'escape' mapped to the back-tick (`), and if I need to send an actual back-tick then I just hit it twice (``). I ripped this setup off from someone on StackOverflow.

You're missing a closing parenthesis!

I'm currently into vim/screen, but actually thinking of jumping ship to emacs/tmux [mostly due to orgmode]. Anyone ever done the same?

From the looks of it, the screen to tmux transition will be the easy part :)

I started in basic Vim and migrated to using the Vimoutliner plugin, especially for non-code text. Orgmode is a hell of a lot more fully featured than Vimoutliner, has a much larger user base, and a much more active development team. I'm able to stomach Emacs by using the Viper and Vimpulse plugins that emulate a nice subset of Vim keybindings, but it still doesn't feel as good. If you need the extra features of Orgmode it's well worth it, though. Still, Vimoutliner probably has Orgmode beat when you consider just the outliner functionality (but of course Orgmode offers much more than that).

Lately I've been witing LaTeX documents using the Vim Latex-Suite plugin. What I really should do is configure Orgmode to work with my LaTeX preamble and/or revise the LatexSuite so its outlining works more like Vimoutliner.

Either way you can't lose.

The problem of VIM is that, you need to do a lot of configuration yourself. While this is fan for me, I never recommend it to anyone who has less patience than I have. Any IDE would be much easier for them.

I found vim's configuration to be pretty natural, in that the bare editor worked fine for me, but as I became better-versed in its use, I would run into small things that made me think, "Hmm, I wish I could do this," or "Hmm, I wish this feature worked that way." Engraving each small thing into my .vimrc was a lesson in of itself that helped me learn more about vim each time; I rarely felt overwhelmed or like I had to figure everything out at once.

what's with the "big booty bitches" in the background? haha

eh... yeh. that accidently slipped by -- just random testing of the webapp I was working on.. ;)

Sounds like a badass webapp, dude! ;-P

hmm, :u to undo... who would do that?

what is "Screen"?, link please!

EDIT, ty hubb

http://www.gnu.org/software/screen/

The main selling point of screen is not actually the way he uses it in the video, to manage multiple windows, but the way you can disconnect and reconnect to any screen session from any computer using the screen daemon and ssh.

For example start a bittorrent download running in screen at home and then monitor it from work, reload X without loosing your work, or the canonical example: idle in irc all day without being disconnected.

yeh this is useful detach/re-attach, however, I usually have a screen session opened locally so when I'm doing remote work I typically open several ssh connections since they are cheap -- anything I want to put into the background I do so the typical way and not through screen -- good point though

I love it when old becomes new again.

Vim + Screen has been my "IDE" of choice for 5+ years. At this point I probably could not hack on code using any other toolset—it's so ingrained. And compiling Vim with Ruby bindings has also allowed me to whip up some very useful scripts to performs routine tasks like you'd see in Eclipse.

Vim ftw!

Link to information on vim's ruby bindings? Google doesn't say much right off the bat.

The best source of information is in the vim docs. I also found that to be true of the python bindings as well. Google doesn't do as good of a job as the vimdocs do (probably because most people the whip stuff up using the bindings publish their code as vimscripts/plugins/etc instead of writing blog posts about it).

Ruby => http://vimdoc.sourceforge.net/htmldoc/if_ruby.html Python => http://vimdoc.sourceforge.net/htmldoc/if_pyth.html

I actually don't really understand using this as an "IDE" - part of the reason I don't think I'd be able to leave Eclipse is because it's "fully loaded" so to speak - such as navigating my project's directory/structure, debugging, etc, and I don't think I could live without auto-complete (maybe I'm lazy, but I didn't see it in this video and I don't see how it'd be possible in a Vim environment?), not just auto-complete for the time saving but also for the inspection - I (unfortunately) work with a convoluted piece of technology where every instance of a class seems to inherit a gazillion properties & methods and I sometimes don't know what I'm looking for unless I can scroll down the list that auto-complete gives me.

".. and I don't think I could live without auto-complete (maybe I'm lazy, but I didn't see it in this video and I don't see how it'd be possible in a Vim environment?) .."

In insert mode the keys CTRL-P, CTRL-N complete the previous/next matching word. Instead of these keys you can use the supertab plugin, to complete a word by hiting tab in insert mode.

You can choose where vim searches for matching words with the variable 'complete'.

There's also the omnicompletion, which does language specific completes, like method names of an object, by using ctags.

Search for 'omnicomplete <language>' to find the language specific plugin.

Reply on news.ycombinator.com