Skip to content

Allow disabling automatic cursor color adjustment. #20789

Description

Currently cursor color is automatically adjusted to maintain minimum constrast. This means TUIs that normally control the cursor color themselves are no longer able to.
For example, I often intentionally hide the cursor when making certain TUI menus that have another position indicator, like dropdowns where only the line is relevant and the cursor becomes distracting.

It would be great if there was a setting to disable this, just like the general text lightness adjustment setting.

Some videos, where using cursor color as a mode indicator in Vim is not possible in the Windows Terminal:

20261010-1106-11.2291044.mp4

In Wezterm:

20261010-1106-59.4441578.mp4

Activity

  1. added
    Issue-FeatureComplex enough to require an in depth planning process and actual budgeted, scheduled work.
    on Oct 10, 2026
  2. added
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    Needs-Tag-FixDoesn't match tag requirements
    on Oct 10, 2026
  3. buzztouniverse commented on Oct 10, 2026

    @buzztouniverse
  4. yhdhvyfhv commented on Oct 10, 2026

    @yhdhvyfhv
  5. buzztouniverse commented on Oct 11, 2026

    @buzztouniverse

    However, if adjustIndistinguishableColors already handles cursor colors appropriately, is a new setting might be redundant?

  6. DHowett commented on Oct 12, 2026

    @DHowett
    Member

    Currently cursor color is automatically adjusted to maintain minimum constrast.

    We do not change your cursor color.

    As a compatibility fixture, #ffffff is accepted as a synonym for inverted color cursors.

    Other than that: we (and I mean the we that Lotte Visser (@yhdhvyfhv) claimed to be part of but is not (as they appear to be a spammer)) do not change your cursor color for perceptual lightness, contrast or anything else.

    (Ze Zhang (@buzztouniverse) spam us again and face the consequences.)

  7. simoesd commented on Oct 12, 2026

    @simoesd
    Author

    In the above video, the cursor is set to #ABB2BF inherited from the color scheme, but this can be reproduced using a specified color in any profile. So it shouldn't be caused by the special #ffffff behavior

    Another example, with the cursor being set explicitly to #F54E70 for the current profile only, the same color as the red lines in. The first two rows are from one screenshot, the bottom two are from another, put together to more easily show the difference in colors. Resulting cursor backgrounds are #CA1E4E for the "a" in the orange row, and #FFA3BD for the s in the red row.

    Image

    The cursor foreground colors are intentionally handled in #15283 (and also doesn't seem to respect the "Adjust lightness of indistiguisable text setting") but I haven't been able to find where background colors are handled.

    Obviously I can't comment on whether or not this is intentional, but it's the current behavior. I forgot to include it in the original issue body, but I have been testing this on version 1.25.2733.0

  8. lhecker commented on Oct 12, 2026

    @lhecker
    Member

    Dustin L. Howett (@DHowett) We do adjust it inside BackendD3D. As mentioned by David Simões (@simoesd), this was done in #15283 to specifically fix #9610:

    • A colored cursor on top of a background with identical color is still visible ✅

    In my opinion, the adjustIndistinguishableColors setting is unrelated, because it is meant to fix issues with poorly behaved terminal applications. The cursor on the other hand is drawn by the terminal and the cursor can be hard to see even if a terminal application is well-behaved. So, if anything this warrants another setting.

    But before that, I'd like to see the color nudging logic improved because in the screenshot above, the red background should IMO not get adjusted.

  9. DHowett commented on Oct 12, 2026

    @DHowett
    Member

    Argh, well color me surprised! Sorry!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-FeatureComplex enough to require an in depth planning process and actual budgeted, scheduled work.Needs-Tag-FixDoesn't match tag requirementsNeeds-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions