4 ms·

I'm still using the built in MacOS terminal. What am I missing? I mostly do webdev - maybe terminal features are more important for other types of programming?

dcre 2y ago
Built-in terminal doesn’t support truecolor. Many CLI programs rely on that to look good.
- herpdyderp 2y ago
  What CLI programs? I have yet to run into any issues after using the built in terminal for its entire lifespan.
  - oefrha 2y ago
    You wouldn’t realize because 24-bit colors are silently dropped. You don’t get the full experience but you also won’t “run into any issues”, unless you start using something that relies on 24-bit color coding for core functionality, like my own log viewer.
  - dcre 2y ago
    As an example, here is the Helix editor (neovim looks just as bad) in Terminal.app vs. ghostty (would look just as good in any other modern terminal). https://imgur.com/a/terminal-app-left-vs-truecolor-tddRL0C https://imgur.com/a/terminal-app-left-vs-truecolor-tddRL0C
    - ryanponce 2y ago
      Off topic but what Helix theme are you using here?
      - dcre 2y ago
        Some small tweaks on the built-in theme ayu_evolve.
    - xoa 2y ago
      I appreciate you making an effort to visually display things, but FWIW I don't think that (or sibling) really gets to the root issue, which is less of capability then practical convenience and compatibility. Mac native Terminal perfectly well supports 256 colors (or arbitrary 16 colors with themes), which I've used, so you could absolutely make both sides look identical there. Unless someone is regularly viewing photos inside their terminal (which some do support and can actually sometimes be handy!) then it might not be immediately clear what 24-bit would bring to the table over 8-bit, regardless of editor or shell themes. But in practice 24-bit was an easy lift for terminals under active development ages ago, and in turn made it trivial to have everyone across any platform specify exact colors more easily without any end user customization or arguments about "not quite what I wanted" in an 8-bit palette or whatever. Thus a lot of the ecosystem now makes use of it. Being able to replicate anything yourself, or get close enough, in a smaller colorspace is still extra grunt work for no particularly valuable reason, and could actually add up to be fairly significant work if one has a lot of more complex code coloring themes and such.
      - dcre 2y ago
        My example is precisely about practical convenience. If I try to do something very normal in Terminal.app, namely use a text editor with a theme, it will look like garbage.
gpanders 2y ago
Apple Terminal has a lot of problems. As others have mentioned, it lacks support for 24 bit color, enforces minimum contrast ratios without any ability to disable them (meaning you cannot set arbitrary color themes), is hopelessly bad at Unicode rendering (particularly with multi-codepoint graphemes, see [1]), and in general misbehaves in other myriad ways [2][3][4]. With both Ghostty and iTerm2 now freely available, there's really no reason to use Terminal.app. [1]: https://mitchellh.com/writing/grapheme-clusters-in-terminals https://mitchellh.com/writing/grapheme-clusters-in-terminals [2]: https://github.com/neovim/neovim/issues/26093 https://github.com/neovim/neovim/issues/26093 [3]: https://github.com/neovim/neovim/issues/28776 https://github.com/neovim/neovim/issues/28776 [4]: https://github.com/neovim/neovim/pull/28453 https://github.com/neovim/neovim/pull/28453
setopt 2y ago
Personally, my main reason to prefer Kitty over Terminal.app are (I believe Ghostty support all of them as well, so looking forward to try it out): - “Kitty Keyboard Protocol” means that a TUI app can detect all keybindings. For example, if you install kkp.el in Emacs, then Emacs running in a terminal will pick up ctrl+shift keys, super keys, etc. on par with a GUI app. I believe NeoVim supports this out of the box now as well, so if you ever felt like binding Cmd+S to :w<cr> you now can. - “Kitty Graphics Protocol” means that I can let e.g. Matplotlib show images inside a terminal, even over SSH connections. If you’re annoyed at pop-up GUI windows, or struggling with viewing remote images often, this is a nice workaround. There are even attempts at making terminal PDF viewers (like termpdf.py); IMO that’s a game changer, even though the app itself is still in a “proof of concept” stage IMO. - Terminal splits. If you work a lot in a terminal, it’s nice to be able to full-screen a terminal and view many different shells or processes side-by-side. Last I checked, Terminal.app just doesn’t have this feature. Sure, you could use multiple windows or a multiplexer like tmux, but that comes with different trade-offs; for example, a native terminal offers smooth scrolling with a trackpad whereas tmux doesn’t. Personally, I use tmux remotely, but stopped using it locally. - I see a lot of people mention 24-bit colors as a main reason to not use Terminal.app. For me, I’m actually pretending that I have a 16-color terminal, because I’m tired of having to theme every command-line utility individually, I’d rather they all just respect my 16 chosen colors instead. The only exception is my editor, just because there are unfortunately few good 16-color themes these days, so I instead change my terminal program to be consistent with my editor theme and then let every other TUI utility believe the terminal only supports 16 colors to match.

dcre 2y ago

Built-in terminal doesn’t support truecolor. Many CLI programs rely on that to look good.

herpdyderp 2y ago
What CLI programs? I have yet to run into any issues after using the built in terminal for its entire lifespan.
- oefrha 2y ago
  You wouldn’t realize because 24-bit colors are silently dropped. You don’t get the full experience but you also won’t “run into any issues”, unless you start using something that relies on 24-bit color coding for core functionality, like my own log viewer.
- dcre 2y ago
  As an example, here is the Helix editor (neovim looks just as bad) in Terminal.app vs. ghostty (would look just as good in any other modern terminal). https://imgur.com/a/terminal-app-left-vs-truecolor-tddRL0C https://imgur.com/a/terminal-app-left-vs-truecolor-tddRL0C
  - ryanponce 2y ago
    Off topic but what Helix theme are you using here?
    - dcre 2y ago
      Some small tweaks on the built-in theme ayu_evolve.
  - xoa 2y ago
    I appreciate you making an effort to visually display things, but FWIW I don't think that (or sibling) really gets to the root issue, which is less of capability then practical convenience and compatibility. Mac native Terminal perfectly well supports 256 colors (or arbitrary 16 colors with themes), which I've used, so you could absolutely make both sides look identical there. Unless someone is regularly viewing photos inside their terminal (which some do support and can actually sometimes be handy!) then it might not be immediately clear what 24-bit would bring to the table over 8-bit, regardless of editor or shell themes. But in practice 24-bit was an easy lift for terminals under active development ages ago, and in turn made it trivial to have everyone across any platform specify exact colors more easily without any end user customization or arguments about "not quite what I wanted" in an 8-bit palette or whatever. Thus a lot of the ecosystem now makes use of it. Being able to replicate anything yourself, or get close enough, in a smaller colorspace is still extra grunt work for no particularly valuable reason, and could actually add up to be fairly significant work if one has a lot of more complex code coloring themes and such.
    - dcre 2y ago
      My example is precisely about practical convenience. If I try to do something very normal in Terminal.app, namely use a text editor with a theme, it will look like garbage.

gpanders 2y ago

Apple Terminal has a lot of problems. As others have mentioned, it lacks support for 24 bit color, enforces minimum contrast ratios without any ability to disable them (meaning you cannot set arbitrary color themes), is hopelessly bad at Unicode rendering (particularly with multi-codepoint graphemes, see [1]), and in general misbehaves in other myriad ways [2][3][4]. With both Ghostty and iTerm2 now freely available, there's really no reason to use Terminal.app. [1]: https://mitchellh.com/writing/grapheme-clusters-in-terminals https://mitchellh.com/writing/grapheme-clusters-in-terminals [2]: https://github.com/neovim/neovim/issues/26093 https://github.com/neovim/neovim/issues/26093 [3]: https://github.com/neovim/neovim/issues/28776 https://github.com/neovim/neovim/issues/28776 [4]: https://github.com/neovim/neovim/pull/28453 https://github.com/neovim/neovim/pull/28453

setopt 2y ago

Personally, my main reason to prefer Kitty over Terminal.app are (I believe Ghostty support all of them as well, so looking forward to try it out): - “Kitty Keyboard Protocol” means that a TUI app can detect all keybindings. For example, if you install kkp.el in Emacs, then Emacs running in a terminal will pick up ctrl+shift keys, super keys, etc. on par with a GUI app. I believe NeoVim supports this out of the box now as well, so if you ever felt like binding Cmd+S to :w<cr> you now can. - “Kitty Graphics Protocol” means that I can let e.g. Matplotlib show images inside a terminal, even over SSH connections. If you’re annoyed at pop-up GUI windows, or struggling with viewing remote images often, this is a nice workaround. There are even attempts at making terminal PDF viewers (like termpdf.py); IMO that’s a game changer, even though the app itself is still in a “proof of concept” stage IMO. - Terminal splits. If you work a lot in a terminal, it’s nice to be able to full-screen a terminal and view many different shells or processes side-by-side. Last I checked, Terminal.app just doesn’t have this feature. Sure, you could use multiple windows or a multiplexer like tmux, but that comes with different trade-offs; for example, a native terminal offers smooth scrolling with a trackpad whereas tmux doesn’t. Personally, I use tmux remotely, but stopped using it locally. - I see a lot of people mention 24-bit colors as a main reason to not use Terminal.app. For me, I’m actually pretending that I have a 16-color terminal, because I’m tired of having to theme every command-line utility individually, I’d rather they all just respect my 16 chosen colors instead. The only exception is my editor, just because there are unfortunately few good 16-color themes these days, so I instead change my terminal program to be consistent with my editor theme and then let every other TUI utility believe the terminal only supports 16 colors to match.