4 ms·
iTerm2's design is saddled by some history. At the time I took it over, everything was done in a single thread. By the time I realized I was going to stay with
by gnachman 9y ago
iTerm2's design is saddled by some history. At the time I took it over, everything was done in a single thread. By the time I realized I was going to stay with the project and how bad the design was, it was too late to change it. I've moved as much work as possible off the main thread (parsing the bytestream and now rendering). I think Terminal gets very nice performance without resorting to Metal by doing only UI work on the main thread. I think the Metal renderer will prove to be worthwhile, even though it was a lot of work to create that could've been avoided (kinda) if the design had been fixed 8 years ago.
As for using CPU when idle, there was a bug where a background thread was doing the equivalent of running `ps` over and over. That's been fixed in the last few versions, but please file issues for such things and I'll get to them as soon as I'm able.
- wll 9y agoThank you for your work on iTerm2, George!
- jarpineh 9y agoI'll add my thank you. I'm also backer at Patreon. With tmux control mode it's already very good and now with faster rendering coming...
- acoard 9y agoI've got an unrelated question about tmux/iTerm2 - hope you don't mind me asking. I'm a heavy iTerm2 user and always been curious about tmux. Is there any reason to try out tmux integration if I'm already comfortable with iTerm2's features and panelling? I kind of got the impression tmux integration was largely for people who love tmux and are migrating to iTerm2, so it just makes it more familiar. Or is it something I should take another look at?
- AceJohnny2 9y agoI use tmux with iTerm regularly, and it's my killer feature in iTerm. I don't think there's much benefit to using tmux integration for a local shell, other than possibly long-lasting sessions that will survive iTerm itself crashing (and maybe you logging out? I'm not sure), which isn't enough of a problem for me to have to work around. The awesome benefit for me is when using a remote tmux. Tmux integration works over SSH, so thanks to this I can have native-looking tabs and windows that are actually terminals on a remote machine. And if I get disconnected (frequent, with a laptop, as I'm moving around), I can reconnect and get all the remote windows just fine. Gone are all the usual tmux C-b prefixes to managing windows, non-integrated scrolling, etc. Everything behaves like a normal iTerm window. I can even split/move panes like normal iTerm panes (though that crashed iTerm until about a year ago). I have the following alias defined: ssh -t elf.example.com /opt/local/bin/tmux -u -CC attach The -t is the SSH option to force pseudo-terminal allocation, which some versions of ssh fail to do when passing a command (in this case tmux) rather than starting a shell. I'm specifying the /opt/local/bin version of tmux, because that's an updated one I've installed from MacPorts. Unfortunately Apple continues to bundle old versions of tmux in macOS, and last I checked the one that was bundled didn't actually support the Control Channel required by iTerm integration. -u is a tmux option to force it in Unicode mode, required by iTerm's Tmux integration -CC tells tmux to start a control channel and disable echo (required by iTerm's tmux integration) `attach` attaches to the default session that I created prior.
- hultner 9y agoI’d say it’s the opposite as an die hard tmux-user. I don’t really use the integration since I’m more comfortable with my terminal in full screen and my own tmux config. The integration services seems more appropriate for someone who doesn’t already have their tmux-bindings and workflow stamped into muscle memory but rather just want the benefits of detaching their terminal sessions from their terminal application while retaining iterm native tabs, windows and panes. I’ve tried out the integration mode a few times but it just doesn’t fit my workflow (often switching sessions, highly customized tmux configuration, etc).
- Myrmornis 9y agoExactly. For people who already use tmux heavily, and use it on linux as well as macos, the iterm2 integration isn’t going to be an attractive direction. Partly because it will lose the uniform experience across OSs, and partly because they’re happy with session/window/pane management using tmux’s UI.
- kokey 9y agoI'm the same, but with screen. I usually have an iTerm2 tab for each screen session. I have a screen session on a work machine and one on a personal machine, each usually with close to 10 virtual terminals. I connect to both with mosh. I haven't seen a compelling reason for me to switch to tmux, yet.
- jarpineh 9y agoNot at all, if only to tell about virtues iTerm2 and tmux to wider audience! Short version: iTerm with tmux control mode (tmux -CC flag) is still iTerm, only now with tmux benefits like persistent shell sessions. iTerm translates regular commands like new window and split pane into tmux commands and acts otherwise like regular iTerm. Mac might crash or SSH get disconnected and tmux stays running to save you from losing anything (well, if it's running on a server..). In addition you tmux gives you shell sharing and allows using different devices alltogether. I sometimes use iPad or iPhone with Blink.app to connect to my always running sessions. You can connect to existing tmux session attaching with CC mode and iTerm will open windows and panes to accommodate. One caveat if you require Mosh for network issues: it and tmux control mode aren't compatible. Also, I'd like to open tmux windows as tabs instead of separate iTerm windows, but that's a minor thing. This page on iTerm's wiki explains things in detail: https://gitlab.com/gnachman/iterm2/wikis/TmuxIntegration https://gitlab.com/gnachman/iterm2/wikis/TmuxIntegration
- wingspan 9y agoRegarding Mosh and control mode, Eternal Terminal https://mistertea.github.io/EternalTCP/ https://mistertea.github.io/EternalTCP/ provides the same resumable session, and works flawlessly with tmux control mode.
- AlexCoventry 9y agoET may be insecure. It was recently possible to segfault it with corrupted network inputs. https://github.com/MisterTea/EternalTCP/issues/79 https://github.com/MisterTea/EternalTCP/issues/79
- bronxbomber92 9y agoDid you hit any pain points using Metal?
- wincent 9y agoSo looking forward to the Metal renderer. Any idea when it will makes into a release?