ITerm is great. It really is. But I wish more time was spent on optimizations. People these days seem to forget that terminals are often used for displaying huge amounts of rapidly scrolling text and that speed is of paramount importance.
To put this in perspective, my computer has two CPUs with 4 cores each, 24GB RAM, a graphics card with 1600 Stream Processing Units (engine running at 850MHz) and 1GB of RAM, and yet it scrolls text in a terminal slower than my 386 machine 20 years ago.
I did a lot of work on performance which you can see in the nightly builds; it was too risky for the 2.0 schedule. We now parse the input stream in a separate thread from where it is rendered. That being said, while the refresh rate is probably lower than it was on your '386, the throughput is undoubtedly higher. If you'd like a higher refresh rate, it's a trivial tweak to a single constant, but in general throughput is more useful.
Yes, throughput is what I'm really after, refresh rate is secondary (still nice, but secondary).
It's great to hear that this work is happening, thank you! And also thank you for all the work, because gripes aside, iTerm2 is the best tool out there.
Not just fast scrolling text. For some reason there is a noticeable delay when just typing text into a shell in iTerm. I didn't notice it until one day I started Terminal.app for no reason at all, and typing in it gave me that feeling that it was predicting my keystrokes, meaning of course that my brain expected a lag that wasn't there.
I had the good (?) fortune to come into OS X at the end of the 10.3 days (in fact, my Powerbook didn't come with an OS install so I put Debian on it for a week until Tiger was released), so I suppose I missed this phase. When I got Tiger on, Terminal was more than sufficient, and iTerm felt immature and impractical for daily use.
I never understood why so many people used it, but reading this, it makes a lot of sense now.
i had the same beef with it and i went back to using xquartz with dwm and urxvt.
The reason why it's so slow is very simple. It's basically an nstextview derivate.
To be fast it needs to fill the buffer and render it offscreen in fixed intervals. a lot of osx programs share this problem. there was an ancient vnc viewer called vncthing that easily beats every osx vnc viewers performance, because of that.
I've tried iTerm and a few other alternatives periodically over the years and I keep coming back to Terminal.app for performance and stability. It'd be interesting to see how far a performance sprint could take iTerm…
Performance actually seems to be much better in the new version! My standard test is to open a split-screen tmux session and try scrolling man pages.. New version doesn't jump around the page.
This might be an unrelated problem, but I find that when I copy a large amount of text and paste it into iTerm, it takes a long time to paste. This often happens when pasting into Vim, so it could be a vim issue. For example, copying the code of a Javascript library. When I do this in a text editor outside of iTerm, it's nearly instantaneous.
Vim will type every character you paste, one by one.
F12 should switch you to paste mode and paste it as a block, though on my new Mac this was already mapped to some GUI function so I had to disable that for it to work.
Pasting into a buffer in insert mode is not the best idea. I've remapped <leader>p and <leader>P to paste from the system buffer and it's just as fast as yanking and putting text in Vim.
That doesn't work as well over SSH sessions though, which is where pasting into vim really starts showing its limitations. Vim's normal inefficient behaviour plus a link with latency is an unfortunate circumstance.
Try turning off syntax highlighting and any plugins like jshint that try to operate on a buffer realtime in vim before pasting (or just paste it to an temporary buffer instead of an existing js file) if it's still slow then it's probably iterm and not vim.
Did you try out the new iTerm? I was having issues like this, and started using the iterm nightlies about 8 months ago. I've seen considerable performance improvements, and now prefer it over Terminal.app.
While text performance is important, when I have to scroll through huge amounts of text it's usually because I made a mistake. If the output of my "fgrep -ri" is too long, it's also useless and I'd better pipe it to another grep or use a better regex.
I have tail -f on various logs running, I often run processes that spew massive amounts of debug output (which I then search through), and even ls -al can sometimes be fairly long. There are lots of use cases where you want lots of text. And in this day and age I really want to just dump it all into my terminal, without planning ahead how to work around the slowness.
tmux is my main use-case for a fast terminal. Even something as simple as resizing a split in my main 266x188 session while nothing else is happening makes Terminator (VTE-based) into a juddering laggy mess.
urxvt's nice and responsive even while catting a million line file into one of the splits - I can use other terms and resize splits without a problem, hitting ^C stops cat instantly, and it's done displaying the lot inside 12 seconds.
Terminator takes 5 seconds just to respond to a ^C, and is otherwise completely unusable for over a minute.
It's responsive and fast for you in a single fullscreen 2560x1600 term while catting a large file in a split? Performance is a lot more reasonable if you're using more traditionally-sized terms and let Terminator manage the splitting.
Perhaps it's depending on some hardware acceleration feature not provided by VirtualBox.
One feature I really wish iTerm2 2.0 would have introduced was better session restoration support. With Terminal.app, you can issue a command like 'ls' and then quit and re-open Terminal.app and the previous output from 'ls' shows up. This is incredibly useful when you have to restart or if your system crashes and you have some output that you wanted to preserve.
I see from the changelog that some type of restoration has been included: "Support for OS 10.7 features including fullscreen, retina graphics, and window restoration"... but upon actually trying it out, it doesn't do what Terminal.app does.
As others have pointed out, it's just an inappropriate comment.
Yes it's open source, and yes, anyone can hack on it themselves. But 99.99999% of the time it's not realistic.
Nearly every piece of software on my computer could be enhanced to fit me personally, but there's no way I could justify the time and energy to work on it. Also, in most cases I have no desire to learn the stack/underpinnings for a particular enhancement.
Lastly, the comment comes off as condescending. Are we really not allowed to wish for things? Must we personally fix everything we find an inconvenience or problem with?
Though I agree with you, where is the stick in the ground? The OSS community's theme song has always been "you can do it yourself", even though that has long been not realistic for many people. So, nothing here is different as far as I can tell.
> The OSS community's theme song has always been "you can do it yourself"
In my experience over the last 15 years, that theme song can often veer from "you can do it yourself" (empowerment) to "do it yourself" (dismissal); replying to a reasonable feature request, in any context, with 'fix it yourself' is one of the things that turned a lot of people off OSS around the time of the first 'year of linux on the desktop'.
The GIMP was the best example of this, with professional graphics editors, illustrators, etc. requesting features and being told 'no one needs those features' and 'if you want it so much, do it yourself', and it hurt their image a lot with many potential users, both technical and non-technical.
Personally, I'm glad that attitude has largely disappeared (though apparently, not entirely).
> Wow, being downvoted for suggesting to hack something yourself on Hacker News ... that's a new one. I guess I'll take a time out.
You'll also get downvoted for complaining about being downvoted. That's almost verboten here, and explicitly mentioned in the guidelines.
When you get downvoted, accept that possible your comment detracts from the conversation. It doesn't just not add anything, but takes away. It's noise.
If your first reaction is to edit your comment and complain, then that's a clear sign you aren't in the right frame of mind to contribute meaningfully.
Your original comment was, if I may be so bold, cliche. Maybe that's the wrong word, but it comes up by someone with your attitude generally every time a thread about an open source project comes along. It literally is something that can go without saying.
His original comment didn't lack originality because he posted something that he did that was quite interesting. I, for one, believe that anyone is capable of anything they set out to complete. I don't think noticing a polarized reaction from a community you participate in is always a transgression. No ruleset rationalizes the community's reactions 100% of the time.
I agree with your sentiment and it is depressing to see you downvoted. On HN I would have hoped your comment would stimulate those familiar with the code base to offer hints of where to start hacking, rather than rapid down arrow clicks.
He was downvoted for the dismissive and condescending attitude, which helps no one. The idea that anyone can work on iTerm is fantastic, but when someone posts a suggestion/request/wishlist item and is essentially told to 'do it yourself' that just comes across as hostile and unwelcoming.
The exact same sentiment could have easily been posted in a friendly and welcoming manner, but that didn't happen and that's why he's getting downvoted.
Errr are you running the Yosemite beta? I love the dark menu bars.
How do you find it? Do you find the kindergarten icon colours irritating? What about the blurriness? Do you feel like you've switch to varifocal lenses and are constantly rubbing your eyes?
What about the lack of Maximise/Zoom button? I don't want everything fullscreen - the menubar has MenuMeters running in it and a clock which you can't see in Fullscreen mode. I use ShiftIt to maximise the window when Zoom is being dumb and fear for my future with this insane "maximise" button removal.
The open source community cannot simultaneously use "anybody can fix bugs and add features" as one of their loudest pitches and then get offended when people suggest doing so. Either being able to dive in and fix it yourself is an edge case or it is not.
Being able to dive in and fix it yourself is definitely an edge case. Even among people who use terminals, I don't know that many who are able or willing, or who have the time or energy, to learn the codebase enough to add a feature.
'The open-source community' isn't pitching this idea and also rejecting it. 'Tone-deaf open-source proponents' are pitching it (or, in this case, suggesting it, and rudely) and regular, well-socialized people are criticizing it as a good idea poorly said.
I can see it being a performance issue if you need to fsync session updates to disk constantly, but personally I'd be pretty much happy if the session was only saved at normal shutdown. Maybe saving it after a certain idle period would also be useful.
Would that mitigate your performance concerns, or did I not guess the source of the issue correctly?
The history is a property of the shell (bash, zsh), not the terminal.
Edit: I wrote a thing here about the difficulty of carrying history across terminal sessions and how can you associate a tab you open now with a tab you had open in a previous session, but then I realised that I misread your post.
I would expect the answer in the posted link to work. The 'share_history' option, when set, tells zsh to reread the history file before performing history lookups.
Maybe try the set-local-history option documented here?
I assume it pertains to Lion-style window restoration. Before 10.7, when you restarted your computer, you had to open each and every app (and every window!) again.
Since 10.7, system (assuming the app cooperates, that is) does that for you and reopens everything.
Agree. Session restoration is really great. I would go further, though. I use `source` for virtualenv and it would be awesome if terminal could restore that as well.
One problem I have with this is that its a massive security hole. Where does the output get stored? If its in an encrypted file, okay .. but if not: deal breaker.
1. If you regularly have passwords, keys, PII, etc. in terminal windows, your workflow should change.
2. If you care about security in any way, you should be using FileVault rather than cargo-culting it into apps (there's no way for that "encrypted file" to be secure unless you have to type in a password every time you shut down the system). If you do that, anyone who can read that file has already compromised your account and there's no additional exposure from this.
>1. If you regularly have passwords, keys, PII, etc. in terminal windows, your workflow should change.
Security is not just about passwords. Its about operational knowledge of procedures and habits at the console, too. Knowing that a certain command is always used, or some such operational administration occurs, definitely assists attack.
>2. FileVault
FileVault is not always available, nor is it always allowable.
But history files are not only about password, as I said.
You can disable it system wide. But it also works on a per-app basis: if you don't want the UI state restored, then just quit the app with Cmd+Option+Q (instead of the regular Cmd+Q) and OS X will not save the application state.
I wish that there would have been a setting in the program options ("Preferences"... I don't know why, but that word annoys me in this context) so that the user wouldn't always have to do cmd-opt-q. Maybe the best option would be to have a checkbox that swaps the behavior ("don't save the output unless I press cmd-opt-q").
THANKS for letting us know about cmd-opt-q! I'll have to start using that all the time since it does seem like a potential security hole.
You can disable window restoration system wide (System Preferences -> General -> "Close windows when quitting an app").
So you don't have to use the shortcut at all in that case.
Personally I prefer getting used to using it on a case-by-case basis. For example, when I leave work I tend to quit most apps on my laptop with Cmd+Option+Q, so that when I get home they don't re-open with work and I can start working on personal projects.
tmux doesn't help you in this scenario, because the tmux process is lost during a system reboot. I concur with the parent - Terminal.App's ability to restore the previous sessions output after a system crash (which on my macbook Air ranges from daily to weekly - FTDI USB Drivers and Display Port cable being to the two major reason) really make me appreciate that feature.
"FTDI USB Drivers", if it's the VCP ones the very latest ones have been reasonably stable for me. I've not had a system crash for quite a while now, whereas I was having them weekly with an older version.
Nope - I'm on the latest 2.2.18 drivers still flakey as can be - This has been an ongoing issue for me for about two years - it's a pain when you are working on a Cisco Router, and you unplug the cable and kernel panic. I guess on the (weirdly?) pro side, it's at least fairly consistent - about 20% of the time, the Macbook (two generations now for me, 2010, and 2013) kernel panics.
This is where Terminal.app (or possibly OS X 10.9 + Terminal.app) ability to show you your terminal history on recovery from Kernel Panic is really appreciated.
If only there was a reliable USB-Serial cable/controller/interface for the Mac. Unfortunately, RS-232 is so rare (except for consoling into Cisco Routers?) that there is no incentive for any vendor to actually write a half stable driver.
I don't know what sort of serial adapter you're using, but I've used a number of the PL2303-based ones over the years (currently a Trendnet TU-S9), and have never had them cause any sort of instability. Weird.
I've never found any one particular USB-Serial Adapter to be any more reliable. Currently using the Tripp Lite Keyspan, Model USA-49WG, SKU CU8037. Appears on the USB chain as: Product ID: 0x0131, Vendor ID: 0x06CD. Still kernel panics when I pull out the USB Cable.
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
I've never found any one particular USB-Serial Adapter to be any more reliable with the FTDI drivers on the Mac. Currently using the Tripp Lite Keyspan, Model USA-49WG, SKU CU8037. Appears on the USB chain as: Product ID: 0x0131, Vendor ID: 0x06CD.
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
Well, I started working at a place where I was regularly juggling 2-4 SSH sessions, 2 programs running and dumping logs in other tabs, plus a few more open terminals, and after a coworker introduced me to the wonderful zsh[1], I wondered what other great tools I was missing. That's what led me to iTerm2.
I stuck with iTerm because of the many, many little features and conveniences that make working with the terminal easier.
Tabs can be put at the bottom of the screen, which solves that pesky issue where changing tabs on a fullscreened terminal.app causes the OSX topbar to slide down and intercept your click. Tab titles change color depending on the kind of activity that's going on within. Hotkey mapping is a lot more powerful, and lets you send arbitrary hex/escape codes with hotkeys. There's a drop-down mode, like Tilda or Visor. This might just be placebo, but I'm pretty sure it also glitches out less often than Terminal.app.
All in all, everything is just a little bit nicer than the stock terminal.
* 256-color support. This was added in Lion I believe.
* There's a really weird bug with word-wrapping that only manifests itself in Terminal.app: http://superuser.com/q/46948/5966 As of 10.9, I believe it remains unfixed.
FWIW, I've tried switching to iTerm about 3 times and I've always to come back to Terminal.app because it feels more
"solid or "native" and it minimizes the installation + configuration I need to do on a new machine to feel comfortable.
Likewise - I live in Terminal.app all day long, 4-6 hours at least, and for some reason I always return back to Terminal.app - particularly now that I can auto-rename tabs when I ssh into other other hosts (PROMPT_COMMAND='printf "\033]0;remote_host\007"').
With that said, I'm going to give iTerm another try - the tmux support is intriguing...
One of the nice (newish) features if iTerm2 is the ability to store your config in Dropbox (or other arbitrary location). This means that all the machines I use have an identical configuration.
What converted me to iTerm was using Vim with a decent color scheme (e.g. Solarized or Base16). Even though supposedly it's possible in Terminal.App, I could not get it working (Mavericks). After hours upon hours of trying, and retrying, I gave up (in?) to iTerm because it just worked.
I do prefer Terminal.App. To me it feels more polished and stable and I'm used to it and it comes with the OS. I appreciate iTerm and the work put into though and it's what I currently use, but if I could get my Vim setup working in Terminal.App I would switch back.
Similar experience. I could never get Vim color schemes to work properly in Mavericks, despite many attempts.
I've been using Terminal on Yosemite, and for what it's worth, the Solarized theme works properly. I'd forgotten how much trouble it was in the past.
My current setup is to run tmux inside Terminal, with the 'Option as Meta key' flag enabled. Then configuring tmux to use Option-A (instead of Control-B) preserves the standard emacs shortcuts. So Control-A and Control-B still work to move to the beginning of the line and back a character. Mapping Control to Cap Locks, and using Option-A for tmux has served me well so far.
I agree that Terminal seems more polished (start up time and ability to keep up with typing speed - iTerm seemed slightly laggy compared to Terminal). But I'll give iTerm another try - the configuration options are impressive.
I use Terminal almost exclusively in full-screen mode, and iTerm allows me to do just that.
And no, Terminal.app does not have full-screen mode that is useful. Lion-style fullscreen apps are absolutely useless to me, since you can't bind them to ctrl-[1-9] hotkeys to switch between spaces.
I might have a workaround for you! I use a launcher for OS X called 'Quicksilver'. It's free and absolutely changed the way I approach computing (at the speed of thought, not the speed I can aim and click icons on my screen) and one of the handiest features Quicksilver let's you configure is called 'triggers'. Triggers are system-wide shortcuts that run a quicksilver command. So I have a quicksilver trigger for EVERY application I use.
Any time I hit my special trigger key combination, it will 'launch' that app. If it is open it gives it focus, and if it is not running it opens the app. This means I can rearrange my apps and desktops however I like and I always instantly travel to the app I want next.
Terminal is command-shift-I anywhere. Chrome is command-shift-c for example. Firefox is command-shift-f. Let's say I'm editing an HTML file over ssh and I want to test it. It doesn't matter whether chrome or Firefox are running, full screen, on the same virtual desktop, if I strike command-shift-c Chrome is instantly in front of me. I flip between programs all day and don't use my dock except to empty trash (and yes I know command-option-shift-delete but that is living on the edge!)
I do the same with spaces and Divvy. I have 8 spaces.
Space 1 is full screen browser.
Space 2 is full screen terminal.
Space 3 is full screen music app.
Space 4 is full screen mail.
Space 5 is full screen code editor.
Space 6 is IM/Twitter.
Spaces 7-10 are used as needed.
It works just fine, I know where every app is, so I just go directly to that space with ctrl-$SPACENUMBER
Now, note that I say full-screen, I mean "with menu bar visible, maximized using Divvy." I can't use system-provided full-screen API, because I lose ability to use only keyboard to navigate around.
Yes! This is almost exactly what I do, except s/command/control/, and I'm using Alfred instead of Quicksilver.
Not sure if Quicksilver has this, but one nice feature is that if, say, Chrome is currently active, and I hit its key-combo (control-shift-c), Chrome is hidden (the equivalent of command-h). This is great if you're installing something in the background and want to see if it finished without reverting back to the dark ages of command-tab.
It's especially nice on a laptop, because I can expand all my windows to fill the screen while still having near-zero overhead when switching between apps.
> Any time I hit my special trigger key combination, it will 'launch' that app. If it is open it gives it focus, and if it is not running it opens the app. This means I can rearrange my apps and desktops however I like and I always instantly travel to the app I want next.
What if I have 6 full-screen Terminal windows (connected to SSH servers, tmux sessions, and so on), and I need to switch between them? Your comment prompted me to install Quicksilver, but it doesn't seem like it can handle that. I'd be glad to hear if I'm wrong.
Smarter "dobule-click to select" logic. iTerm seems to highlight exactly what I want when I double-click in the area. Last I tried Terminal, it missed the mark.
Select to copy. I know some people can't understand why anyone would want this, but I've become accustomed to it. One thing that does still annoy me, even with iTerm, is that I find after I select something I need to move my mouse for it to copy.
I imagine 256 color support was a deal breaker before Lion, but I'm still an iTerm guy because of those reasons above.
Yes, select to copy a thousand times. If you're used to xterm, this is invaluable, especially if you're then just pasting the selection into another terminal with middle click. It saves many mouse/keyboard transitions.
I second this. I'm using Terminal.app for years now, dabbled with iTerm from time to time, but just couldn't see any advantage; since Terminal.app allows me to save window layouts and customize colors - so far, it's all I need from my Terminal emulator. The rest is the shell's job.
Mouse reporting. You can scroll text with mouse wheel, you can click on text and move the cursor there, so you can have say vim essentially behave like graphical vim (silly example I know, but still it's useful to some people). You can resize vim split windows with a mouse.
iTerm exports its color profile as shell variable, so you can have vim adjust its color theme to match the terminal theme.
It has better full screen support.
It has support for foreground/background color of the text the cursor is over, which Terminal.app does not have at all. This is why in vim if you cursor is over syntax highlighted element whose color is similar to the cursor color, it become incredibly hard to tell where the cursor is (esp. on large screen).
iTerm has "highlight cursor feature", to quickly show you where the cursor is (CMD+/). This is useful if you went away from the screen for a while and you come back, and can't immediately spot the cursor.
iTerm has better font rendering (more like GUI Vim) because it is a Cocoa view.
iTerm allows you to split terminal windows both horizontally and vertically.
The list goes on, but these are some highlights. Essentially, you have more control over your terminal.
> Deep tmux integration. iTerm2 can speak directly to tmux and display its virtual windows as native windows or tabs, making tmux much easier to navigate.
I actually prefer Terminal.app otherwise, but the tmux integration is so good it's worth it just for that.
- Good fullscreen support. Normal terminal can only go into "Lion fullscreen" which means it will be on a separate workspace and you can't have other windows besides it.
- Configurable keyboard shortcuts
There is a bug in terminal.app that manifests itself when you ssh to remote servers, launch something like tmux, disconnect, and try to resize the window[0]. The bad part for me is that this happens every time I leave my desk (the terminal resizes to the laptop screen size, and my usb ethernet dongle gets disconnected).
* search starts from the bottom of the buffer (most recent result).
* I can cmd+click filenames with line number (in error messages) and have them open in my text editor with cursor on the right line.
* notifications when background tab becomes idle - notifies about finished long-running builds/installations, etc.
* much better, customizable keyboard shortcuts. Supports meta keys properly. I have keyboard shortcuts for opening a tabs connected to my servers, disabled annoying "Print" shortcut, etc.
It was a very basic thing that caused me to switch: Being able to use Cmd-1, Cmd-2, Cmd-3, etc to switch tabs (Terminal.app only does this for windows, not tabs).
The built-in tmux session stuff is fabulous. Makes me never want to use normal tmux again.
I also quite like that iTerm allows non-Lion full screen mode. That combined with some tasteful transparency lets me see stuff happening while I'm poking around at the command line. It's nice to visually see the result of a Control-C or the relaunching of a web server.
I use it exclusively for the visor mode. Which I have set up to be like full screen mode on a laptop, but is limited to half the screen when I plug into an external monitor. It's also bound to show/hide on ctrl+`.
Unlike most others it seems, I don't utilize the tmux integration, despite using tmux heavily.
I found that iTerm provides a slightly better experience with Vim: colorschemes were rendered more accurately and redraw performance was improved (most noticeable when scrolling the window line-by-line with CTRL-E and CTRL-Y).
However, MacVim improves again on those two points, so I end up using that.
I switched to iTerm.app at the same time I switched to Vim only because Terminal.app didn't support 256 colors at the time. Although Terminal.app now supports 256 colors (it's been 3 years) I got used to iTerm.app and just keep using it out of habit.
I switched because of the Yakuake/Guake/Quake 3 console like functionality it has. I don't live in the terminal but need it constantly, hitting <C-`> is easier than ⌘-Tab-ing until I find the right window.
> I switched because of the Yakuake/Guake/Quake 3 console like functionality it has.
I made the switch from Terminal.app myself when iTerm finally added the feature, but Terminal.app had this functionality available via a SIMBL plugin (oh man, remember those?) called "Visor" for several years, but it was always a hack that would stop working for a few weeks/months whenever a new version of OS X was released.
It looks like Visor has now been replaced with TotalTerminal, another hack in the form of a wrapper application bundle: http://totalterminal.binaryage.com/
Small things like a sane full screen shortcut and easily turning off those godawful window animations that make you feel like your mind has been trapped in someone else's powerpoint presentation.
This has always kept me coming back to iTerm. (The configurable word separators is handy too. Obviously the people that work on Terminal.app don't have many files with hyphens in them, but I seem to have loads.)
The developers seem to really be promoting their deeper support for tmux integration. I'm probably what you'd call a tmux noob, but after a few months of using it on its own with minimal key remappings, I feel like my efficiency with the keyboard-only UI has already surpassed any gains I might get from sticking tmux integration with mouse support and tmux shortcuts. It's not that I'm opposed to this integration, but that I don't think it goes deep enough.
Ideally, I think tmux would be inseparably integrated with the terminal emulator, with no shims to add complexity to the UI. For instance, it irks me that the workflow for integrating iTerm with tmux is running `tmux -CC` and then leaving that window open in the background for as long as it runs. I'm bothered by the fact that I have to run a command to begin the integration in the first place. Wouldn't it be better to check a box in preferences that says "Integrate with tmux if tmux is installed" and then from then on make sure that the tmux concepts of sessions, windows, and panes deeply align with corresponding concepts with iTerm?
Besides Firefox, iTerm2 is my most used app, by far. I love the customizability of it, the Visor mode, and how stable it it to work with. I've used it so long, I don't even remember why I don't use Terminal.app any more.
So did everyone here just download this piece of software over HTTP (no HTTPS)? Why is it that large projects like this cannot spend 15 minutes setting up hosting over HTTPS-only using a $10 (or even free) SSL cert? I love me some iTerm but yikers.
Yes it's technically interesting but am I alone in thinking that it sort of defeats the purpose of using tmux in the first place?
I use tmux partly because I come from a background of low resources, but also because I want my essential tools to use as little resources as possible so that they always work as well as possible on any system.
Yet iTerm proposes that you use their GUI tabs, split their GUI terminals instead of drawing it all with tmux in one text console.
I guess you sacrifice some resources for usability.
If your main purpose for using tmux is sparing resources, then sure, but I think most people use tmux for session management, persistence and multiplexing. If I can use these features in a way that is better integrated with the windowing system, and still be able to attach to the session from a plain terminal remotely, I'm not going to complain.
The issue I've always had with the tmux integration is that it doesn't support multiple sessions simultaneously. I am typically moshed into several hosts and running tmux on each of them. I'd love to have one window per session with tabs corresponding to tmux windows.
I'm a little surprised more people don't run into this more often. I've never seen the benefit in running tmux locally. Do most people only ever use tmux on one remote host?
Edit: it's been a while since I've tried it; apparently tmux integration doesn't work over mosh at all. So s/mosh/ssh/g above and it still applies.
Does tmux integrate with itself? That is, does this solve the problem of needing different prefix keys when nesting tmux sessions (whether using iTerm2, or using a terminal emulator that doesn't itself integrate with tmux)?
I thought that, when nesting tmux instances, you just press the prefix key a number of times depending on how deep you need you need your next keystroke to propagate?
For me personally, I use ctrl-a instead of ctrl-b so I have this line in my ~/.tmux.conf:
#send prefix to nested sessions with C-a
bind-key C-a send-prefix
Lastly, iterm2 uses it's own keystrokes for it's tmux integration. (i.e.: cmd-D to split vertically)
I have tmux set up so that pressing the prefix key twice switches to the previously selected window. I don't remember whether it was like that out of the box, or whether I had to configure that when I switched from gnu screen.
I take it with nested tmux sessions, cmd-D would split the outer tmux window? How would you split the inner tmux window?
> I don't remember whether it was like that out of the box, or whether I had to configure that when I switched from gnu screen.
It's worth checking your config file out.
And I'm not sure how to answer your question because the way iterm integrates with tmux is that it allows you to create split panes with their own bash sessions. If you want to run tmux in those sessions, it would be tmux running in that pane, but textually instead of graphically. Here's a screenshot to make things more clear: http://i.imgur.com/0hmw62I.png
I love iTerm, couldn't live without it.. To me Terminal.app isn't much better then PuTTY on Windows.
That said I'm a bit worried when I read stuff like "manipulate the pasteboard remotely" and "performed when text matching a regular expression is received". Are these potential security concerns and/or what is the performance impact of regex'ing every single line of text etc?
Naive question, but I keep trying iTerm and not being able to quite figure out why I should switch. In the mid-2000s it was a much better program than Terminal.app, but that doesn't seem to have been true for quite some time. Terminal.app has tabs, 256-color mode, themes, full screen support, and as people have mentioned in other comments, session recovery and much better performance. The only things I can think of offhand that that leaves in iTerm's court -- at least in the 1.x series -- is tmux integration and autocompletion. The latter I've never seen the point of (my shell does that pretty well, thanks) and after trying the former it seemed like it was more bothersome than just letting tmux handle everything on its own.
Okay: iTerm can put borders around its windows, which one of my friends says Terminal.app's inability to do makes it unusable for him. But beyond that, I just haven't been sold. (If that's the right phrase for free software. You know what I mean.)
[Edit: I think the tmux integration was a 2.x-dev feature, so I must have been using that. IIRC, I actually preferred tmux's own "window" handling.]
The most important benefit for me is the "Hot key" feature. I used to have Kuake back in my Linux days, and loved it. It's so much more convenient that having many different screens, and switching between them via "Cmd-Tab". It's gotten to the point where I very rarely open dedicated windows, unless I'm doing some serious debugging or so.
For those who don't know about the hot key; I press "Ctrl-~" to have a terminal screen dropdown from the top of the screen. You can have any number of tabs and splits there. Pressing the same combination again closes it.
The neat thing is I know I can access the terminal with the same single keystroke, no matter which app I am using. Does Terminal.app has this feature?
There is a tool named TotalTerminal (formerly "Visor") for the Mac which extends Terminal.app and does exactly this. I even have control-~ mapped to the behaviour. It seems pretty configurable, and hooks nicely into the prefs window of Terminal itself. You can hit cmd-opt-F to temporarily switch the current Terminal into full-screen mode, in case you need to delve into a particular task.
Yes, I also used to have TotalTerminal. But I found that using iTerm from the ground up was somehow more convenient than using TotalTerminal with the regular Terminal. Don't quite remember what was the particular reason.
This is exactly why I started using iTerm. You and I even use the same key combination! It is so convenient that whenever I use others' machines, I try to bring down the visor and get frustrated when nothing happens.
Terminal.app can do this with the help of TotalTerminal. I used to use that, but switched over to iTerm for the greater degree of customization.
I'm in a shell most of my day when not in meetings. I love being able to have a nice full screen with vertical and horizontal splits (Cmd-D or Shift-Cmd-D) with thin lines between each split. Also iTerm helps me keep my hand off my mouse and when I do use my mouse iTerm makes my usage very efficient (double click to copy text .. Cmd-V paste, right-click lots of stuff right in your face on the spot..)
I'm less about tabs and more about splits, with two 24" monitors and my 13" MBP on my desk I can have lots of text space to work with and very little window distraction from window chrome.
Maybe it's just because I'm old fashioned and I love to live on the command prompt (vim -vs- sublime all day long) and I grew up in the era of TTY's and 300 Baud modems.. iTerm feels more natural then Terminal.app, it feels like a terminal someone would use all day long -vs- something you hop in for 20 seconds to type some obscure OSX command you cut-paste'd from some site.
In the past I ran into dumb emulation issues with Terminal.app like wrapping and stuff that didn't work right. iTerm seems to be a "programmers" terminal more then a simple utility to get to the command line.
I have a terminal open nearly all the time, too! I suppose I tend to just open multiple terminal windows, and resize/organize them with Moom (or just the mouse). I can cycle between them on the keyboard, and Terminal lets me paste with middle click, has context right-click menus, etc. (I only recently noticed it has man page lookup in the right-click menu, and learned that if you option-click anywhere in a Terminal.app window it sends that as a mouse click to the app running inside it!) If I absolutely want panes within the same terminal, I run tmux locally.
Terminal.app used to suck, certainly. I suspect a lot of iTerm users are long-term users who really haven't seen how much better Terminal.app is today than it was five or six years ago.
If I could ask an unrelated question, what are you using to power 2 external monitors on your MBP? I have a 30" monitor at $work, but a pair of smaller monitors would be even better.
Modern MBP's have two thunderbolt plugs.. Thunderbolt to DVI to two Dell U2412M's makes for a nice dev environment if you spend a lot of time in terminals.
Not less then one column character borders.. It has to burn a column to create borders.. And a couple of other laggy issues.. I need to play with tmux more but when on a bunch of different machines going iTerm straight to the box and using splits makes for a more enjoyable experience.
IMHO Arguing about terminal emulators is almost as religious as arguing about languages. Pick what works for you and I won't judge you if you don't judge me.. Now can we get back to solving real problems.. LOL :-)
Interesting, I've been using iTerm for so long that I didn't realize that Terminal.app added themes and tabs. That was the primary reason I used iTerm in the first place.
Remote pasteboard twiddling is guarded by an off-by-default preference (prefs>general>allow clipboard access to terminal apps). Triggers are user-defined; while most people use them to change text colors, you are given enough rope to hang yourself, so be careful when creating a trigger that runs a command.
Booting a Linux install disk is my favorite way to use a Windows machine.. ;-)
Just kidding, I love PuTTY in windows but it's not my favorite emulator. I actually enjoyed Centry Term's TinyTERM [1] but I have a feeling that is WAY before most people here's time. I still have a couple 3" floppies with TinyTERM on them and a copy of the activation codes.
You might be kidding, but I actually run VMWare Player with full-screen linux at all times to have a terminal. It's free, switching to VM is simple alt-tab. You can share folders/drives, copy/paste works, it's even accelerated so I can use any "modern" window manager. Only things missing are snapshots, but I don't have those on hardware either. If I need to reboot the host, I can just pause the VM.
I like the idea of triggers.
auto-highlighting the following regex's makes life a bit better whille reading logs and traces.
.[eE](rror|xception). highlight error lines
:\d+ highlight line numbers in ruby (captures bits of time stamps though...)
[lL]ine \d highlight line numbers in python
I bet there are more creative uses. please enlighten me.
Is there a good tiling window manager for OS X that has a feature like iTerm2 where I can drag and drop a tab on top of another to split it, and keep those windows together?
I use Moom (previously Divvy) but they only really give you hotkeys for moving windows around. Xmonad for OS X seems difficult to setup, and I'm not even sure if it does what I want.
First, thanks for releasing this! Second, silly question, but what is the recommended way to navigate long commands? Is there a way to click my cursor to a specific point, or a keyboard shortcut to navigate large blocks of words? I tried OPTION+LEFT-CLICK, but sometimes it will have the effect of moving my history to the current command.
Just tried out the tmux integration. Seems to be extremely buggy. The tmux session would randomly detach and you have to have an extra window open the entire time you are using the tmux integration. Nice idea but the execution seems pretty hacky.
So, I have this bash script that runs AppleScript that I use to start up a bunch of servers at once, each in their own Terminal tab. At the heart of it is this 'new-tab' function[1]. I don't really like AppleScript, and would like to not use it.
Can I duplicate this functionality using iTerm, without using AppleScript?
I'm still using version 1 of iTerm because it has the side dock menu, which allows me to maintain a list of the various servers I'd want to connect to, and allows me to close sublists I don't need to see.
The last time I looked at iTerm2 it had a separate window where you had to TYPE the name of the server you wanted, which is WAY more work than pointing and clicking a single name in a side list.
The developers seemed to think the old side dock was bad and refused to add it back in.
Yeah, hierarchical tree-views suck. In the nightly builds (soon to be betas for v3) tags can define a hierarchy by including slashes in their names. They're also browsable in the toolbelt, which is just like 0.10's side-window. It's mighty close to what you were used to.
I see the Toolbelt - I'll try it out and see if it gives me similar functionality. iTerm 1 has a ton of bugs that bother me so upgrading would be nice.
Dang, looks like there/s still no preference to disable creating a new window when iTerm launches or is clicked on in the Dock. I only ever use iTerm via system-wide hotkey (i.e. Quake-style HUD mode), and it's kind of annoying that it automatically creates a duplicate window whenever it launches that can't be hidden via the hotkey.
You need to create a saved window arrangement (Window -> Save arrangement) with no windows open, then set this as the default arrangement in Preferences -> Arrangements, and finally change the Startup preference to "Open default window arrangement" (on the General tab).
Wow, this is great: it still creates a new window when clicking on the dock, but it no longer creates one on startup. That's still a lot better than before. Thanks!
Ah, I work with iTerm hidden from the dock and purely in "Visor" mode. If I actually want a regular window to keep around, I can create one by bringing up the visor and then hitting Cmd+N.
It doesn't do that for me. Whenever I click on the dock icon or fire it up via spotlight, iTerm goes in the foreground, but there is no duplicate windows created.
It appears so. Probably worth filing a bug about this, but I suspect that something about mosh's terminal emulation filters out the VT100 command sequences tmux uses to perform the handshake with iTerm2.
iTerm looks nice, but is there a reason to switch from Terminal.app? The "jobs" sidebar looked great until I discovered that it only works for local processes, for example.
Generally, it seems there is a lot of room for improvement in terminal apps these days:
- Probably upwards of 90% of my terminal work involves SSH, and it seems like a huge missed opportunity not to integrate with SSH in any significant way. iTerm doesn't even bother, whereas Terminal.app's "New Remote Connection" is pretty useless. (It should at least be able to infer my commonly used hosts from OpenSSH's known_hosts file.)
- A terminal should be able to discover the currently running remote process, or at least what host I'm connected to. Neither Terminal nor iTerm do this. My tabs always say "ssh", and so I have to hunt for the right tab to find my shell.
- Persistent shells. Today, when I want to open a remote shell on a host, I open a Terminal tab and do "ssh <host>". If something goes wrong with my connection, I have to go back in manually, and the shell state is lost, and any interactive program not running with "nohup" will probably have terminated. If I close a tab and ssh back in, my state is also lost. If I want multiple shells on the same box, I have to either use multiple tabs, or a kludge like screen or tmux that tries to be a terminal within a terminal. I want to ssh to a server and be exactly where I was.
- No I/O integration. Why can't I cat a file into my terminal app in order to copy or download the contents? Why can't I pipe a local file into a remote shell?
- Grepping. It would be swell if I could tell the terminal to filter its current window contents by a pattern. I don't mean highlighting results, I mean only showing lines matching a pattern. Often I end up doing "tail -f some.log | grep foo", then "...grep bar", "...grep -C10 bar" because I'm not quite what I'm looking for. With this built-in grepping feature, I could do "tail -f some.log", set up a pattern in the terminal app itself, and I could watch it display different matches interactively as I change the pattern.
For grepping you can use tmux's search back/up. It's ctrl-o ? I don't know how people live without it. There is probably a way to dump the stdout history, but a quick google on mobile didn't find it.
For managing SSH connections have you tried the profiles on iTerm ? It's not exactly what you are looking for but might at least save you from repetitive typing.
That doesn't solve the problem of having to create each one manually, when there is a perfectly good list (known_hosts) lying around. I have several dozens hosts I connect to almost daily.
(Yes, I do use tools like Puppet and dsh for configuration management, and probably should use them more, but sometimes you have to get your hands dirty.)
Unfortunately iTerm's solution is even less useful than Terminal's remote connections, since in iTerm each profile have associated settings like colours and cursor type, things which should be the same across all connections.
On the downloads page, the link text for the stable release says "iTerm2 2.0 (OS 10.6+, Intel-only)" but the description below it says "It requires OS X 10.7+ and an Intel CPU."
If anyone else is wondering where the toolbelt is, once you enable toolbelt with "Toolbelt" -> "Show toolbelt", you'll have to resize the iterm window.
To put this in perspective, my computer has two CPUs with 4 cores each, 24GB RAM, a graphics card with 1600 Stream Processing Units (engine running at 850MHz) and 1GB of RAM, and yet it scrolls text in a terminal slower than my 386 machine 20 years ago.