Hacker News Reader

Comment by JdeBP | Hacker News Reader

I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-:

There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly, and some do, almost everyone tries to support this colour system now.

See the screenshot of the old syscons FreeBSD kernel built-in terminal emulator at https://tty0.social/@JdeBP/110424206935120790 for what I mean by really badly. It still does understand the control sequences, though.

View on HN

Apple didn’t get the memo it seems. Terminal.app has been unchanged in many, many years.

I still stubbornly use it as my daily driver for some probably terrible reason.

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.

I've tried a gazillion terminals but I always come back to the built-in Terminal.app. I appreciate that it has no bugs (that I know of).

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.

Have you tried messing with the line height in preferences? The font panel will allow you to set whatever you please

Yes, but I shouldn't have to do that, particularly when it works correctly in most other terminals.

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.

* https://github.com/kovidgoyal/kitty/issues/16

* https://github.com/kovidgoyal/kitty/blob/28b84a2d5b2720b88fd...

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

With iTerm.app, getting a message that "your system ran out of application memory" is a reason for me to stick to the Terminal.app.

It's a 96 GiB of RAM machine, for chrissake! That ought to be enough for everybody!

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 + compiling something large with verbose logs non-stop?

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.

Well just limit the scroll buffer then

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've never had that issue before, but I switched awhile back to wezterm.

That sounds very wrong to me, I used iTerm fine for years on 8GB

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 think you can set how the terminal presents itself in both tmux and regular Terminal.app

If the app doesn’t check for support and simply spills the control characters, there may be garbled output.

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.

It’s that value that apps should check. I know vim does.

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.

* https://github.com/rust-lang/rust/blob/master/compiler/rustc...

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

[1]: <https://learn.microsoft.com/en-us/windows/console/console-vi...>

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.

Did anyone actually send Apple a memo? At https://github.com/termstandard/colors#not-supporting-trueco... there are pointers to where people have asked, when they have. There's nothing for Terminal.App.

(That's the big push that I mentioned. Going since January 2014.)

I don’t know where or who we would address it to. “Feedback” is such a black whole.

Is Apple making Microsoft look good by comparison, again? (-:

Microsoft Terminal has a whole open GitHub issues system to itself.

* https://github.com/microsoft/terminal/issues/

Microsoft is all warm and fuzzy towards developers. Developers, developers, developers, and some old CEO used to say.

Apple seems to have forgotten we exist.

I think the reasons are often good: https://lobste.rs/s/fikvmn/farewell_macos#c_swz7p7

256 colors ought to be enough for anybody.

That’s like 254 too many.

Sounds like writing code in notepad.

Sounds like terminals as they existed for most of the life of computing. Honestly I’ve never found color added that much to my experience with a terminal and often ended up with poor contrast for certain things and a bunch of time tweaking color palettes.

Since eMacs and vi has been two color for a lot of its life, I’d say it’s more like writing code with pretty bog standard code editing tools.

Reply on news.ycombinator.com