edit
edit copied to clipboard
microsoft
Add support for Terminal.app on macOS
We currently expect full RGB support from the hosting terminal. Terminal.app is likely the only popular terminal that doesn't support it, but it's very popular (relatively speaking), so we should add support for it. This requires downsampling the color here:
https://github.com/microsoft/edit/blob/b008570afc0c4c6cef7ba0335d407139a47c8e24/src/framebuffer.rs#L524-L555
And somehow detecting RGB support here:
https://github.com/microsoft/edit/blob/b008570afc0c4c6cef7ba0335d407139a47c8e24/src/bin/edit/main.rs#L499-L595
Detecting RGB support should not use the COLORTERM environment variable, because a) I don't like it and b) I'm quite certain there's alternatives to do it. The simplest alternative is to just assume that Terminal.app is the only terminal that doesn't support it (...given that this project doesn't aim to support old terminals).
Just to note the difference between Terminal.app and iTerm2 (which I assume doesn't have coloring issues) when ran remotely:
which I assume coloring isn't the expected but is tolerable for now more or less.
Not sure if it is helpful or not, but Terminal.app can support 256 colors, rather than just the default 16. It looks like people have had similar trouble in the past with SSHing into Windows: https://apple.stackexchange.com/questions/154907/how-can-i-get-256-colors-on-the-default-terminal-over-ssh
Note that Terminal.app on the first macOS 26 developer beta (25A5279m) now advertises itself as xterm-256color with true color support:
I'd say it is, unironically. Apple is not too interested in supporting older versions of macOS, and we're not particularly excited to add workarounds for the only terminal that can't do 24-bit colors. Seems like a win-win. 🤔
I'd say it is, unironically. Apple is not too interested in supporting older versions of macOS, and we're not particularly excited to add workarounds for the only terminal that can't do 24-bit colors. Seems like a win-win. 🤔
Apple does tend to support at least the last major release with security updates, and there are still Intel Macs in use which may not get Tahoe, so I think supporting 256-color is still advisable.
But maybe as a command line flag or environment variable instead of automatically would be better? something like --color-mode=1 or MSEDIT_COLOR_MODE=1 or something to that effect? Could even offer a monochrome mode that way too (0 = 24-bit, 1 = 256, 2 = monochrome).
This would mean that, for any fringe cases where 24-bit color is absent, whether due to terminal support, accessibility, or user choice, edit can still work.
If anyone comes along and submits a PR to add 256-color support to the Framebuffer I certainly wouldn't complain. In fact, I'd be quite happy to merge it. 😄 But I think it's fair to say that this is not as much of a priority anymore now.