Look into getting Emacs in one of its native OS X incarnations rather than using it in the terminal. Emacs is going to have a lot more options for colors (font locking is the Emacs-speak, I think) in its own app than when it's boxed into a terminal. You also get support for multiple "frames" (windows); Vim can't do this at all and I still miss that from Emacs. I use Linux rather than OS X but if you are parked in Emacs for a long time there's no reason to do it in a terminal. I always used the GTK or the Athena version.

Vim can absolutely do multiple "frames". They're called splits.

No, it cannot. An Emacs "frame" is a separate editor window, managed by the window manager. Different Emacs frames running the same Emacs session talk to each other--they share the buffer list, etc. Within the Emacs "frame" you can have split "windows".

One Vim session can live only in one window that is managed by the system window manager. You cannot have multiple windows that talk to each other. You can split a single window manager window using ":split" and the like. Vim calls these "windows". You can have multiple tab pages, each of which holding multiple Vim windows, but all these tab pages must reside in a single system window-manager window.

Vim has a help file somewhere saying that Bram Moolenaar knows this is a problem and it's on the todo list.

You can also run Emacs as a daemon, and connect to it from both graphical and tty sessions. So you could ssh into your desktop and (with emacsclient), work with the same instance running on your X desktop.

I did this back in college with XEmacs (90's). I'd leave gnus running at school and open a new frame from home to check mail and news. (You can use this to have two people editing at once too, but you have to avoid avoid opening a minibuffer.)

Although it is not exactly the same, what you can do is start a `screen' session (which can be split with ^a S), and then split your `vi' instances.

A frame in Emacs terminology is actually a top-level window.

So MacVim does have this functionality then, yes? You can have multiple top-level windows, each having multiple tabs, each having multiple splits.

I was curious so i just tested this to see if it did. It does not. Yes you can have multiple tabs and splits, but in emacs each frame shares the same buffer list as well.

They don't share anything. Different buffers, registers, and I think even different extensions loaded.

unless you are remote, then the terminal emacs + tmux are a good combo.

emacs in daemon mode can manage both tty and window manager sessions, and lately, it's started working on OS X! I build git HEAD every week or so and this feature is fantastic. I can ssh into my main work machine and be right back in ENSIME where I was when I left off.

> - Install iterm2. <snip> The main reason to use it >instead of the default Terminal application is that It just works©.

What's wrong with the default Terminal application? I use it daily and have been for close to a decade. I never found myself wishing it did anything than what it already does.

> -Use tmux.

Meh. For most people screen works just as well. Perhaps more importantly, you can rely on screen being available pretty much anywhere. Just like vim. Speaking of which: vim is great. Use vim. The world needs more vim.

Been loving vim for several years. Finally decided to learn emacs, partially spurred by interest in clojure.

It seems that as more languages are created that include native repl experiences, emacs becomes more appealing to me because it fits nicely with editor+repl, where in other editors a repl seems more of an afterthought or nice-to-have.

I would say definitely learn vim first, but it's great to know both vim and emacs. It just opens up more doors.

iTerm2 does vertical and horizontal splitting better than Terminal.app.

tmux does vertical and horizontal splitting better than screen.

That's my rationale for using iTerm2 and tmux instead of Terminal.app and screen.

(yes, I'm aware that screen has improved its splitting recently, but I switched to tmux in 2011, after seeing a presentation about it by Nicholas Marriott)

Why split your terminal if you have screen / tmux?

iterm has special integration with tmux. The big advantage is that you can quickly scroll the history with the mouse which is way faster and more convenient that going back up screen by screen with a shortcut.

Also with some work you can synchronize the OSX clipboard with tmux's one.

I scroll using the mouse in tmux all the time in any mouse capable terminal (aka not Terminal.app, also regular linux terms).

I have a toggle to turn it on off in my tmux.conf, have a looky: https://github.com/mitchty/src/blob/master/dotfiles/tmux.con...

You can scroll in Terminal.app too, use the MouseTerm SIMBL plugin

Well, once you're bolting on plugins for features that come with iTerm2, why not use iTerm2?

Because I find iTerm to be a pile of crap on most of my systems

Out of curiosity iTerm or iTerm2? If the latter what is crap about it?

I have one huge gripe that I haven't been able to fix but its not that huge a deal. Every so often the terminal will lose its mind and start displaying mouse escape sequences. Nothing resets it out of this state, have to close whatever window I have open and start anew. Not a huge deal due to tmux but annoying enough to frustrate.

> The big advantage is that you can quickly scroll the history with the mouse...

I've not found that to be faster than <CTRL+F> or <CTRL+B>. Same keys as in vim. I haven't found the value in using iTerm over terminal + tmux (same could be said for those that are more comfortable in screen).

Copy and paste support mostly.

TMUX provides this.

How do you get it working? I've never been successful

I encountered some problems with command-line emacs control sequences not being captured correctly, though the last time I tried was a while ago.

iirc Terminal has some preferences for properly handling special keys like Ctrl and meta. Does that help our was your problem something different?

tmux seems to choke on tons of console output far earlier than screen.

Another trick I learned from an older HN comment is to create a .marks directory in your home directory and then add the following to your .zshrc

  export MARKPATH=$HOME/.marks

  function jump {
      cd -P $MARKPATH/$1 2>/dev/null || echo "No such mark: $1"
  }

  function mark {
      mkdir -p $MARKPATH; ln -s $(pwd) $MARKPATH/$1
  }

  function unmark {
      rm -if "$MARKPATH/$1"
  }

  function marks {
      ls -l $MARKPATH | sed 's/  / /g' | cut -d' ' -f9- | sed 's/ -/ -/g' && echo
  }

  function _marks {
      reply=($(ls $MARKPATH))
  }

  compctl -K _marks jump
  compctl -K _marks unmark

Now to remember a directory you type

  % mark <any_string>

and to jump to that directory you type

  % jump <any_string>

To list all your shortcuts

  % marks

Depending on the version of ls you might have to change the -f9 parameter to -f8 for marks functions

Or just install autojump and be done with it ;-).

https://github.com/joelthelion/autojump

You can use hop to similar end, and it's got support for shortest unique name and tab completion. https://github.com/Cue/hop

I have a minimal take on this: j <project> to jump to any directory below ~/Projects. Supports tab completion, as it should.

https://github.com/mattgreen/dotfiles/blob/master/zsh/jump.z...

I prefer using z, which is purely written in bash.

https://github.com/rupa/z

I'd add installing zsh+oh-my-zsh. Impressive autocompletion, fuzzy matching, shortcuts, themes (I think agnoster is great), plugins... It's really great and I wouldn't go back to bash. Some resources:

https://github.com/robbyrussell/oh-my-zsh/wiki/Cheatsheet http://www.quora.com/zsh/What-are-the-cool-features-of-zsh-t...

I'd also install autojump https://github.com/joelthelion/autojump to jump quickly between directories instead of using symlinks. Instead of cd ~/project, you just do j project, or maybe j proj is enough for autojump to know where you want to go.

> You can make the terminal start instantaneously instead of it taking several seconds.

Terminal has started instantaneously on all my Macs for years, since the advent of SSDs. A tiny fraction of a second.

If it is taking several seconds to launch, I think something must have gone haywire somewhere.

A friend of mine was experiencing multiple-second launches for Terminal. When he looked, he saw that it was occupying about 1 GB of memory.

Turns out the option to maintain ALL HISTORY EVER as scrollback was turned on. So he had the last year of compiler output and whatnot stored in a file somewhere, getting loaded into memory the first time he launched Terminal after a boot, and then eating a big chunk of his laptop's memory. Turning off the option was a major improvement.

Holy crap.

I leave Scrollback limited to "available memory", which I assume is what you're referring to, but I also compulsively hit ⌘K to clear my scrollback.

It might be parsing through logs to find out last login information.

So, like any unix os, ensure you do this:

touch $HOME/.hushlogin

That will short circuit that stuff. Like you said I've not had issues with terminals opening fast but it can't hurt. I don't give a rats when I last logged in on any unix os I log into.

Don't need symlinks. Just set the CDPATH environment variable!

Also set up case insensitive completion, saves the extra shift press for all those Mac paths.

Does that really not work by default? I would figure it's only an issue if you have your disk formatted as case sensitive, which is usually a bad idea because a lot of devs don't test on it.

No, case-insensitive auto-completion doesn't work by default on OS X. For example, `cd /appli <tab>` does nothing by default (it's not finding `/Applications/`) even though my disk is formatted case-insensitive. However, after adding `set completion-ignore-case on` to my `~/.inputrc` file, I can now type `cd /appli <tab>` and it will auto-complete to `cd /Applications/`.

Any idea why Apple has it set up that way? I don't spend much time in the terminal, but case sensitive auto-complete just doesn't sound helpful.

By default OSX's HFS+ volume is configured to be case-insensitive, but case-preserving. So, the filenames will preserve the case, but the filesystem doesn't distinguish based on case. It makes for interesting bugs.

You sir just changed my life. I never knew about CDPATH..

Case-insensitive auto-completion: brilliant!

To set this up, add `set completion-ignore-case on` to your `~/.inputrc` file (create it if it doesn't exist).

Be careful with CDPATH, it can result in some mind-boggling build script bugs.

Instead of doing the sym link think manually there is a great script that is stupid simple to use and only a few lines in your zshrc/bashrc file.

It's called jump/mark. I aliased j to jump and added tab completion to zsh and it's made all the difference.

Usage

Mark .

Marks the current directory to be in the jump list.

Jump <dir name>

Jumps to that directory.

Zsh is a much nicer shell than bash too and there are no glaring incompatibility issues I have seen in daily usage.

Specifically for jump, from my .bashrc:

    export MARKPATH=$HOME/.marks
    function jump {
        cd -P $MARKPATH/$1 2> /dev/null || (echo "No such mark: $1" && marks)
    }
    function mark {
        mkdir -p $MARKPATH; ln -s $(pwd) $MARKPATH/$1
    }
    function unmark {
        rm -i $MARKPATH/$1
    }
    function marks {
        ls -l $MARKPATH | sed 's/  / /g' | cut -d' ' -f9- && echo
    }
    _jump()
    {
        local cur=${COMP_WORDS[COMP_CWORD]}
        COMPREPLY=( $(compgen -W "$( ls $MARKPATH )" -- $cur) )
    }
    complete -F _jump jump

More information on jump and mark available at: http://jeroenjanssens.com/2013/08/16/quickly-navigate-your-f...

Basically there is a jump oh-my-zsh plugin, but be sure to add the auto-completion mentioned in this article too...

I wholeheartedly agree that it's a good investment to spend time learning your way around the shell. And I've been quite successfully proselytizing it at home: the terminal and the UNIX toolset has been part of my sons' introduction to computing. I actually wrote it down in form of a (free, online) book. It began with my sons in mind, but it soon became a more serious endeavor:

http://juanreyero.com/hacker-ways/index.html

HN is not the target audience, but it might be helpful for somebody.

> Go fullscreen. Not so much for the real estate but for the mental switch. Fullscreen mode is a way to immerse yourself into your productive development world. No browser, no mail, no application notification. Only code.

This is an excellent point and one that's not nearly as appreciated as it should be. Fullscreen mode was written off in Lion as an example of Apple dumbing down the platform and making it more like iOS, but it's the perfect mode for writers, coders--and really just about any kind of creator who needs to focus.

I wish fullscreen mode didn't switch to a different desktop. Tabbing out causes this weird "whoosh" animation to play which is so annoying.

your welcome :) http://totalspaces.binaryage.com/transitions2

Check out iTerm2. Full-screen iTerm2 doesn't switch to a different desktop and tabbing to another app is instantaneous.

I use sizeup[1] to maximize the terminal (or any other app) with a keystroke, instead of native full screen. It works across all applications that allow window resizing, and has handy shortcuts for "half" full screen, which is great to position, say, a browser and editor next to each other across the whole screen.

Which reminds me, I really will go and pay my 13 bucks for it now, it's more than worth it. But the free version is fully functional with just an occasional nag screen.

[1] https://www.irradiatedsoftware.com/sizeup/

Sounds very similar to Spectacle [1] which is open-source with a github repo [2].

[1] http://spectacleapp.com/ [2] https://github.com/eczarny/spectacle

+1 to this. I use CTRL+ALT+CMD+M many times per day.

I do front-end web development and full-screen doesn't work for me. I never spend that much time just coding. I switch to test in the browser often so switching between full-screen windows is jarring.

Also great if starved of screen space.

Quicksilver is similar to Alfred in intent and quite featureful/customizable. It is open source. https://github.com/quicksilver/Quicksilver

Quicksilver used to be great, but then the main developer went to work on some dead end project for Google and abandoned Quicksilver. Is the project still alive?

It's too late for me anyway - I have moved to Alfred, the new kid on the block at the time, and like it much more (much less clutter). Plus, I can't trust the QS developer anymore after he's abandoned the project once.

As far as I know, Quicksilver has been taken over by another team, and is in constant development at the moment.

I know because I regularly see "Quicksilver has been updated" messages ;)

Thank you very much for this write-up and post. I am in a similar boat you are -- every month that passes as a developer makes me hungry to automate those repetitive tasks I do every time I develop something.

I also think this sentiment will be growing. I think there's a large disconnect between "traditional" UNIX users and people entering from the web / Rails / other kinds of worlds, and that gap is slowly shrinking. That's why we are seeing things like npm tools (bower, grunt) replacing makefiles, Docker replacing traditional sysops, the whole idea of "DevOps" as a thing vs "IT".

I'm very very excited about this transition and want to help be a part of it. I think I'm going to write a similar tutorial outlining my current mac / terminal workflow.

The killer for using iTerm2 is the ability to drop another split in with Cmd+D/Cmd+Shift+D. That's pretty much the only iTerm2 feature that I use with any level of regularity, but it's awesomely handy when you're working.

Being able to save and restore the window arrangement is also awesome. I keep iTerm2 in full-screen mode and I have it split into 4 terminals. If I need to restart iTerm2, I simply choose Window -> Restore Window Arrangement and my split terminals are restored.

As for symlinks from your home: I prefer to add aliases for directories I move to a lot. For example:

alias cdss='cd /Users/username/somewhere1/somewhere2'

then I just go 'cdss' to get there from anywhere.

> You can make the terminal start instantaneously instead of it taking several seconds.

You can fix that properly in two steps:

1. Create a symlink to your preferred shell. E.g. `sudo ln -s /bin/bash /usr/bin/bash`

2. In Terminal Preferences, use /usr/bin/bash as your shell, instead of the default login shell.

To confirm that you've fixed the problem:

- Open a new terminal window.

- "Last login" should NOT be displayed.

- Hit Command+I to show the inspector. The command should read: login -pfq username /usr/bin/bash.

The -q switch on /bin/login is what speeds things up. (.hushlogin does not solve the problem)

In order to get Terminal to pass the -q switch to /bin/login you have to use a non-standard shell, hence the symlink.

> Make a few symlinks from your home directory to the directories you use frequently. Instead of doing cd this/that/code/python/project/ you just do cd ~/project

If you are using ZSH, you can just append paths to the $cdpath environment variable. This will allow you to "cd name-of-project" (assuming you've added your project directory to $cdpath). No need for a mess of symlinks in this case.

Or you can use "cdargs" [1], available in Homebrew [2]

[1] http://www.skamphausen.de/cgi-bin/ska/CDargs

[2] brew install cdargs

I have my current git branch display as part of my command prompt when I'm in a project directory.

parse_git_branch() { git branch 2> /dev/null | sed -e '/^[^]/d' -e 's/ \(.*\)/(\1)/' }

export PS1="\u@\h \[\033[32m\]\$(parse_git_branch)\[\033[00m\] \W $ "

You might want __git_ps1. Similar idea, but more functionality & maintained by someone else!

I noticed your main editor is emacs? I consider myself a Terminal Native as well, but why dont you like using GUI Emacs and Eshell/m-x Shell instead?

In practice I find Terminal/tmux/emacs a more pleasant experience to me than GUI emacs/frame and window/shell.

GUI emacs does brings nice features: -multiple fonts / font sizes at the same time (nice for minimap http://www.emacswiki.org/emacs/MiniMap !) -more shortcut possibilities with s- added to the usual C- and M-- -more colours

Shell/ansi-term modes don't work well enough. There's always problems with shortcuts/encoding/escape sequences/Ncurse.

It doesn't seem to work properly. It doesn't pick up my .bashrc, it doesn't have colors, etc.

Where did you find a GUI Emacs that doesn't have colors? I use http://emacsforosx.com. To set a color theme: M-x customize-themes.

You might want/need to install more themes, you can do that with the package manager (M-x package-list-packages)

If you want your ~/.profile to be sourced, a quick fix is to open the GUI app from the command line. Apps launched by finder don't source your profile.

my emacs does have colors. It's M-x shell that doesn't have colors.

And this goes to the point of why emacs users like myself use iTerm. Because it works. The only thing I had to setup in iTerm was my color scheme. And even that wasn't required! (iTerm is launched by finder and finds my profile just fine.)

Why don't you just exclusively use something like Arch Linux