minimap theme colors off since 0.189.5 `minimap.thumb.hover_background`

[andirsun]

Summary

It looks bad after last update.

Description

Expected Behavior:
Actual Behavior:

{
  "icon_theme": "Catppuccin Latte",
  "features": {
    "edit_prediction_provider": "copilot"
  },
  "minimap": {
    "show": "always"
  },
  "agent": {
    "default_model": {
      "provider": "copilot_chat",
      "model": "gpt-4.1"
    },
    "version": "2"
  },
  "show_edit_predictions": true,
  "ui_font_size": 15,
  "terminal": {
    "font_size": 12
  },
  "buffer_font_size": 12,
  "buffer_font_family": "Cascadia Code",
  "theme": {
    "mode": "system",
    "light": "One Light",
    "dark": "Github Dark Dimmed"
  },
  "code_actions_on_format": {
    "source.fixAll.eslint": true
  },
  "format_on_save": "on"
}

Zed Version and System Specs

Zed: v0.189.5 (Zed)
OS: macOS 15.5.0
Memory: 16 GiB
Architecture: aarch64

[SomeoneToIgnore]

"dark": "Github Dark Dimmed"

Seems to be the theme that has some extra variables/Zed's defaults are not good?

#30785 had added the thumb coloring, and presumably the theme has to do something like JacobCallahan/monokai-nebula-zed#4

[MrSubidubi]

...and presumably the theme has to do something...

It is exactly that, in this case the scrollbar hover color, which we use as a fallback, is no good, and dedicated properties for the minimap are missing in that theme (as for most themes). #32182 was another report of this and this needs to be fixed upstream for each theme. See #32182 (comment) for some more details.

[MrSubidubi]

Personally, I would argue we can close this though. The colors are not actually off, the color is just not set by themes currently.

As the fallback color that we use, scrollbar.thumb.hover_background, we have the slight issue that this was also just recently made use. Theme authors could not test this previously, hence this is also not always the most suiting color for the job.

However, I do not really think there is an alternative for that: These properties previously did not exist and support for them has to land eventually in themes that want to support this. For themes that had no scrollbar.thumb.hover_background, nothing actually changed. For the other themes which had that color, we just use basically the same fallback for the hover state that we use for the idle state - scrollbar.thumb.hover_background and scrollbar.thumb.background. Is this optimal? Not really, but that is why we decided adding these new properties in the first place. Personally, I would then argue it is better to not have these optimal colors for the time being, so support (hopefully) eventually lands slightly faster in these themes.

Alternatively, we could remove the hover fallback and run another extension survey to ask themes to add these new properties. This might have the advantage that we do not break as much for users of abandoned themes. Yet, I do slightly fear this might lead to slower adaption for the new properties or no adaption at all. But I can also see some advantages with this approach, so if you'd prefer that, feel free to let me know.

---

For your specific problem here though @andirsun , you can add

    "experimental.theme_overrides": {
        "minimap.thumb.hover_background": "<color-of-your-liking>"
    },

which should resolve the issue for you. Then, you could issue a report in the theme that you use and ask them to have this fixed.

[github-actions]

Hi there! 👋
We're working to clean up our issue tracker by closing older bugs that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and it will be kept open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, it will close automatically in 14 days.
Thanks for your help!

[duytbp]

FYI I opened PR to improve minimap bg colors in upstream theme repo PyaeSoneAungRgn/github-zed-theme#35