I switched to Terminal.app from iterm2 almost 10 years ago because of horrific scroll and input latency for iterm2 after one of the osx upgrades (maybe Mavericks or Yosemite?). For the last few years I've been using kitty, which works well and for my setup allows me to eschew tmux. But Terminal.app still mostly just gets the job done so if it's working for you, I'd say stick with it.
Also, Terminal.app is really bad at rendering Unicode block characters correctly. It doesn't space them correctly vertically, so if you have a lot of block chars it looks like total garbage. iTerm/kitty/etc. all render it correctly.
Spare a thought for we developers of terminal emulators. The block and line drawing characters have been being bodged since the time that IBM added the extra 9th column in hardware.
I have a fairly trivial bodge for them in mine. Kovid Goyal over a period of 7 years has built up an extensive system for overriding the glyphs for block and line drawing characters that are supplied in fonts and replacing them with ones that Kitty constructs itself, all started because they just didn't line up when using what the fonts supplied.
I’m sticking to Terminal.app for the reasons stated by you in this thread. It works, it’s fast and text renders beautifully with whatever theme you fancy.
However, it could use some love from Apple. Better keyboard-only text selection, horizontal and vertical splitting, True Color (not Cyndi Lauper style)…
I love that Terminal.app, out of the box, changes the colorcheme depending on your desktop dark or light configuration. iTerm does this on new versions, but only on 10.14 and later, which my company doesn't support yet :-p
How on earth have you had iTerm use up so much memory it's given you an error? I've been using iTerm for years on some absolute crap machines, abusing iTerm with tmux and numerous customizations, and have never received that error.
Unlimited scroll buffer, but good scrollback hygiene (I clear scrollback after I don't need it), and it ran out of memory by just sitting there — I was using something else during that time and all terminals had been at the shell prompts.
Such advice is not helpful. The infinite scroll buffer is useful for some people with long lived terminal sessions, and that helps them with their respective workflows and habits. I am one of them.
The parent ran out of memory with iTerm not because of the infinite scrolling buffer but because of iTerm having memory leaks. The memory leaks in iTerm used to be a big issue, and it appears they still have not fully fixed. Other terminal apps can swell up to over 1Gb of the RSS, yet they do not crash. Provided there is sufficient RAM available, the inifinte scrolling can prove to be benefecial.
I used iTerm on a 2011 iMac with 6GB of mismatched RAM until 2018 at work, and a crappy 2012 MBP with 4GB RAM (subsequently upgraded to 8GB) from 2012-2016 without issue. This is not normal at all lol
I actually have the opposite problem. I’d like to limit terminal apps to just the 16 colours I have defined in my terminal settings (which is actually 3 colours in my case), but some apps (like the rust compiler e.g.) emit escape sequences which slightly change the shade in some places, in 256 colour space. I’d like to disable those 256 colours and limit everything to 16. I don’t think I can though.
I've tried switching this setting in Terminal.app and all it seems to do is change the value of the TERM environment variable. I haven't observed any other effect.
As a rust programmer, you can explain to us where in this source code the rust compiler is emitting these escape sequences for colours outwith the AIXTerm 16 colour set.
I don't see it here, but one example would be help messages saying "consider introducing lifetime `'bla` here", which are preceded with a source code quote saying something like:
fn foo<'bla>(...)
According to cat -v, <'bla> is preceded by ^[[38;5;10m, which, according to [1], "applies extended color value to the foreground", and further that 38;5;<s> sets "foreground color to <s> index in 88 or 256 color table".
Oh dear. You will I hope not be too embarrassed by learning that the 10 in SGR 38;5;10 (that control sequence) is colour index 10, which is less than 16, and a member of the very AIXTerm 16 colour set that you want. Thus the rust compiler is not in fact using a colour outwith the 16 AIXTerm colours.
Then I don't know how it happens, because I only have yellowish background + black and red defined in my terminal (also white, which I don't see used anywhere). And here is a screenshot from my Terminal.app, where the lifetime is gray: <https://0x0.st/HqVq.32.png>.
I've checked and the 10th colour is set to #000000 in my Terminal.app settings.
If SGR 38;5;10 is not producing green, which it isn't, then it must be following your palette. My educated guess is that for some reason it believes that it should lighten the palette-specified colours from 8 to 15, and it's lightening your black to a very dark grey.
I still stubbornly use it as my daily driver for some probably terrible reason.