I must say however that things are looking a bit better in iTerm2 when switching the Metal renderer on. It's just a shame that an Nvidia GPU on OSX is necessary to compete with my $1000 Lenovo with its crappy Intel chip on OpenBSD when it comes to text editing latency.

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.

With tmux control mode it's already very good and now with faster rendering coming...

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?

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://github.com/MisterTea/EternalTCP/issues/79

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

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.

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

$ defaults write org.vim.MacVim MMUseCGLayerAlways -bool YES

This was the developers' suggestion and it solved my issue. There's an informative discussion of the root causes here: https://github.com/macvim-dev/macvim/issues/557.

    brew cask install iterm2-nightly

    brew tap caskroom/versions

I also recall finding Terminal.app to have lower CPU consumption, matching postit's experience.

    ~ % exit 
    
    [Process completed]

3. Comes with terrible defaults like the screen color.

1. Settings > Profiles > Shell > When the shell exits: [Close the window|Close if the shell exited early|Don’t close the window]

2. macOS standard for all applications is the following.

  - next tab: ⌃⇥ or ⌘⇧]
  - previous tab: ⌃⇧⇥ or ⌘⇧[

3. Settings > New window with profile: Pro

I prefer to open a new Terminal only when I need it instead of keeping one open all day (even if that sometimes happens) and I’ve never noticed an increase in CPU usage that’d made me want to check.

Panes.

- Cmd-W closes the window, not the pane. (I get why they do this. I feel that it is wrong.)

- I can't send input to all panes, which is a pretty useful feature I probably use once a week.

- iTerm2 happily maps my panes to tmux. This is by itself perhaps a killer feature.

Well, if your requirements are low and the defaults are OK, sure, Terminal.app can do it. But iTerm2 does so many more things it's not even funny.

https://github.com/arximboldi/ewig/blob/master/README.md

This is an area where Rust ends up feeling different than many languages: xi's rope uses https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#metho... like this: https://github.com/google/xi-editor/blob/422948d62688dcc2ee0... , which gives you both options. This code uses Rc, not Arc, so it's not currently sharable between threads, but Arc has the same API.

Rust cares about sharing more than immutability.

As Ralph and others have pointed out, their rope is fundamentally a persistent data structure.

I think that one of the fundamental differences between how Rust and C++ deal with value and reference semantics make the two approaches look more different than they are. The C++ API is allowed to look a bit more "immutable", where one can always use the same functional looking API even though sometimes the performance of an operation is gonna depend on the category of the reference you are operating on (l-value, r-value). Rust forces the user to be explicit about everything all the time, making it very explicit when intend to "branch" or "snapshot" the persistent data structure and where do we wanna allow "in place" updates.

I am still undecided about which approach I like most, and I do think that there merits to each approach. But maybe just because I never really wrote anything serious in Rust. The C++ approach has the problem that it becomes unsafe once you introduce `std::move` (but if the C++ type system was not a crazy evolutionary monster one could imagine a similar approach with moves being inserted automatically and safely by the compiler.)

[1]https://danluu.com/term-latency/

There is also a plan[1] for making Alacritty's latency best-in-class.

[1]: https://github.com/jwilm/alacritty/issues/673

> When people measure actual end-to-end latency for games on normal computer setups, they usually find latencies in the 100ms range.

And in that very sentence link to a latency test for a game that is notorious for being laggy, and even then it reaches 59.4ms latency. The same video they link, even says (at 1:32) that Overwatch has a button-to-pixel-change latency of about 15 ms! So where is this "usually 100ms" coming from?

Just because of this I don't really trust the rest of the article.

I've actually been using nvim as my terminal multiplexer instead of using tmux.