[bug] edit does not respect terminal color scheme on various terminal applications

[avikalpa]

edit respects terminal color scheme on some terminals like xterm, wezterm. But not on others like ghostty (HEAD) or KDE Konsole.

I inspected why this is so using the ghostty (compiled from git HEAD) terminal inspector and guidance from jcollie https://github.com/ghostty-org/ghostty/discussions/7874#discussioncomment-13713176

It seems mode 2031 is not turned on for edit and edit has not asked to be notified of theme changes. This may be the underlying issue for edit's finicky behavior.

[IvanPizhenko]

I face this issue on Linux with:

• Built-in terminal in JetBrains IDEs (in particular, CLion, but I guess this will apply to all of them)
• Konsole (in KDE)

To compare, vim and nano work correctly in these two cases.

At the same time, it perfectly picks up color schema of the terminal in the Visual Studio Code.

[JakeSays]

To be fair, vim and nano weren't designed to emulate an 80's DOS app. :)

[j4james]

It seems mode 2031 is not turned on for edit and edit has not asked to be notified of theme changes.

@avikalpa I don't think this is your problem. Mode ?2031 is for detecting color scheme changes while the app is running. The issue with Ghostty is that the color scheme is wrong to start off with.

As for why it's wrong, that's because Ghostty doesn't handle palette queries correctly. The way edit detects your color scheme is by querying the default foreground and background colors (via OSC 10 and OSC 11), as well as the basic 16 "ansi" colors (via OSC 4). If it doesn't receive all 18 colors in response, it falls back to using a default theme.

In the release build of Ghostty, the query handling doesn't work at all, and edit will likely just hang on startup. If you've built Ghostty from HEAD, that hanging issue has at least been fixed, but the OSC 4 palette responses are still not correctly formatted, so edit won't be able to retrieve all the colors it needs.

I face this issue on Linux with:

• Built-in terminal in JetBrains IDEs (in particular, CLion, but I guess this will apply to all of them)
• Konsole (in KDE)

@IvanPizhenko As with Ghostty, these terminals also don't handle palette queries correctly. Konsole's problem is that it can't handle multiple OSC 4 queries at the same time, and JediTerm doesn't support OSC 4 queries at all as far as I know.

To compare, vim and nano work correctly in these two cases.

I think vim just queries the default background color (OSC 11), and from that it estimates whether you're using a dark or light color scheme. It can then select one of its built in themes that's either dark or light as appropriate. It won't actually use your terminal's color scheme as far as I know. I suspect nano does something similar.

There are things that edit could potentially do to work around some of these bugs, or fallback to a simpler dark/light theme detection like vim, but it would be best if these terminals could just fix their palette query responses.

[avikalpa]

@j4james Linking the discussion: https://github.com/ghostty-org/ghostty/discussions/7874#discussioncomment-13722266

[IvanPizhenko]

it would be best if these terminals could just fix their palette query responses.

What I can say?... What I'll say next will probably sound bit harsh, so sorry about that in advance, but the reality is that way - "Just dream more". Terminals are what they are. Konsole exists for ages, and for ages it has those issues, and your competitors (vim and nano) do solve it. So you have too.

[IvanPizhenko]

And please don't blame me to be unfair or "too harsh". I've used edit as my git commit editor on Linux for over the month, that's pretty frequent use, but I've finally given up and switched back to another editor, primarily due to 2 things:

• not picking up correctly terminal color schema
• missing syntax highlighting

[lhecker]

You're not the first person to represent this exact sentiment. But this time in particular it irks me, as it is directed at a person outside of Microsoft. I'm collapsing it because it does not advance the discussion in a productive manner.

I cannot stress enough that this editor is not a competitor to vim, nano, helix, or anything else. And more importantly, this project is first and foremost an editor for Windows, where it works fine.

If it's worth anything, syntax highlighting will be added in the near term. If you want to see theme detection fixed, the best thing you can do is fix it and send a PR.

[IvanPizhenko]

Well, I was a bit emotionally overwhelmed, so I again apologize for that.

And about "If you want to see theme detection fixed ..." - I'm not really that much interested, because there are working alternatives that do the thing, and I choose them. If Microsoft will do that at some point, they'll get one more user on Linux/Mac, if not... no big deal, really.

[JakeSays]

@lhecker ohh very excited about syntax highlighting!

[IvanPizhenko]

I've even seen unfinished PR, someone may be working on that...

[avikalpa]

This is resolved on the tip build of ghostty. Still unresolved on KDE Konsole.