Beyond this, there are a series of personal overrides that I will likely be applying on top of the above that diverge from the explicit values copied from VSCode, but I think make sense for self consistency:
editor.document_highlight.read_background
This controls the background color highlighted enclosing braces relative to the cursor location. In VSCode this is rendered as a box which changes fewer pixels and is thus less visually distracting. To maintain the same level of minimal visual distraction when clicking the cursor around in the code, the brightness of this value needs to be lowered.
element.hover
This is actually a dual purpose color; it's used both for the background of the token that's hovered within the editor and the hover background for clickable menu elements within the code actions dialog. To make the hover color of the code actions dialog more natural, using an uncolored white alpha seems the most natural and matches the lightness of the hover background effect used in VSCode (it just isn't blue tinted anymore).
ghost_element.hover / ghost_element.selected
This is the shade placed over a clickable ghost item, which basically includes files in the left sidebar and entries within the right click / top / f1 menu. VSCode has a strong blue accent vibe going on in the left side with their blue remote development button in the bottom left, their blue logo in the top left, and their blue notification badges. For this reason, their slightly blue tinted hover effects look relatively natural next to the stronger blue accents. Zed, however, is missing these places to show the blue accent so the tinted blue hover effect over the pure grey background looks out of place and unnatural which is why I opted for a pure grey override. Since the other menu locations have a brighter background than the left sidebar, using a rendered grey value makes it blend in with the background too much within the menus. However, using pure white with alpha provides a subtle yet distinguishable brightened background in both places.
title_bar.inactive_background
This is the shade drawn on the titlebar when the window is not focused (newly introduced config). The default override feels fine under most cases, except when dragging the window it renders the titlebar with an unfocused color (I asked if this is intentional [here](https://github.com/zed-industries/zed/pull/14266#issuecomment-2227326566)). When it renders at a color matching the tab color, it visually indicates a complete loss of focus which is counterintuitive IMO since you are currently dragging it. So to counter this, using a color in between the two still gives some visual change when the window loses focus without making it feel unusual while dragging the window.
by @MatthewScholefield in #5:
Beyond this, there are a series of personal overrides that I will likely be applying on top of the above that diverge from the explicit values copied from VSCode, but I think make sense for self consistency:
Explanations:
This controls the background color highlighted enclosing braces relative to the cursor location. In VSCode this is rendered as a box which changes fewer pixels and is thus less visually distracting. To maintain the same level of minimal visual distraction when clicking the cursor around in the code, the brightness of this value needs to be lowered.editor.document_highlight.read_background
This is actually a dual purpose color; it's used both for the background of the token that's hovered within the editor and the hover background for clickable menu elements within the code actions dialog. To make the hover color of the code actions dialog more natural, using an uncolored white alpha seems the most natural and matches the lightness of the hover background effect used in VSCode (it just isn't blue tinted anymore).element.hover
This is the shade placed over a clickable ghost item, which basically includes files in the left sidebar and entries within the right click / top / f1 menu. VSCode has a strong blue accent vibe going on in the left side with their blue remote development button in the bottom left, their blue logo in the top left, and their blue notification badges. For this reason, their slightly blue tinted hover effects look relatively natural next to the stronger blue accents. Zed, however, is missing these places to show the blue accent so the tinted blue hover effect over the pure grey background looks out of place and unnatural which is why I opted for a pure grey override. Since the other menu locations have a brighter background than the left sidebar, using a rendered grey value makes it blend in with the background too much within the menus. However, using pure white with alpha provides a subtle yet distinguishable brightened background in both places.ghost_element.hover/ghost_element.selected
This is the shade drawn on the titlebar when the window is not focused (newly introduced config). The default override feels fine under most cases, except when dragging the window it renders the titlebar with an unfocused color (I asked if this is intentional [here](https://github.com/zed-industries/zed/pull/14266#issuecomment-2227326566)). When it renders at a color matching the tab color, it visually indicates a complete loss of focus which is counterintuitive IMO since you are currently dragging it. So to counter this, using a color in between the two still gives some visual change when the window loses focus without making it feel unusual while dragging the window.title_bar.inactive_background