Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS2022: Caret is nearly invisible while in insert mode on dark mode #2955

Open
2 tasks
mpdelbuono opened this issue Feb 9, 2022 · 8 comments · May be fixed by #3101
Open
2 tasks

VS2022: Caret is nearly invisible while in insert mode on dark mode #2955

mpdelbuono opened this issue Feb 9, 2022 · 8 comments · May be fixed by #3101

Comments

@mpdelbuono
Copy link

Describe the bug
In VS2022, the insert caret is nearly invisible in dark mode. Furthermore, settings do not appear to have an impact on the color of the caret. Disabling VsVim causes the caret to revert to the expected (visible) color.

To Reproduce

  1. Launch Visual Studio in dark mode. I have Windows High Contrast settings enabled, but I do not believe this has an impact.
  2. Open a file
  3. Enter insert mode
  4. Reposition the caret to the end of the line. Note that the color appears to be inconsistent. Sometimes it appears more visible than normal, but in most locations the caret is nearly invisible, especially when it is in between words in C# mode as the word also becomes highlighted.

Expected behavior
Caret should be visible. It is very regularly difficult to see.

Screenshots
Screenshot below shows the cursor between the "o" and "c" in "Lock".
image

Same screenshot with VsVim disabled:
image

Settings do not seem to indicate this color scheme (I have tried changing "Block Caret Background" and "Command Margin Background Color" just to confirm and they did not appear to have any impact).
image

Environment (please complete the following information):

  • Visual Studio version: VS 2022 17.0.5 64-bit on Windows
  • VsVim version: VsVim 2.10.0.5
  • Programming Language: C#
  • Check(Type 'x') any that are installed:
    • ReSharper
    • Visual Assist

Note:
The following is written about contributing.
https://github.com/VsVim/VsVim/blob/master/CONTRIBUTING.md

General Keyboard configuration problems are described below.
#2527

@mpdelbuono
Copy link
Author

I have realized that this is occurring only when my zoom level is set to 90%. At 100%, the caret is visible. There may be an issue with how the zoom level is interpreted.

@injust90
Copy link

injust90 commented Nov 3, 2022

I had the same issue but I just set my caret to a different color that allowed for the text to show through. I seems like something to be is addressed on the user's end.

caret mismatch

Can this issue be closed? @jaredpar

@giiyms
Copy link

giiyms commented May 31, 2023

I have the same issue. The block caret works fine. It is when in insert mode. The caret is so thin, it is hard to see.

@rafaeloledo
Copy link

rafaeloledo commented Mar 28, 2024

Screenshot 2024-03-27 224622

@mpdelbuono thank you for the zoom tip

it's 90% for me too, the picture above shows the issue

If u download the image and zoom in, the caret is there, but is really thin...

@nosami
Copy link
Collaborator

nosami commented Apr 1, 2024

Have you tried set vsvimcaret=100? This setting controls the opacity.

@nosami
Copy link
Collaborator

nosami commented Apr 1, 2024

invisiblecaret

OK. I can reproduce this when setting my display scaling to 100%. In the video, the caret is sometimes invisible when between certain characters.

At my usual 200%, I don't see this no matter what zoom level I use.

@nosami
Copy link
Collaborator

nosami commented Apr 1, 2024

I think I may have found a solution for this issue https://superuser.com/a/1786709

@nosami
Copy link
Collaborator

nosami commented Apr 1, 2024

I can't figure out why this happens. The width of the caret and opacity is the same in each location.

It seems like the easiest fix might be to force the use of the Visual Studio caret when in Insert Mode rather than the custom caret that VsVim renders. This would be a trivial change, but maybe there is some reason that I can't think of why this wouldn't be a good idea - @jaredpar?

nosami added a commit that referenced this issue Apr 1, 2024
@nosami nosami linked a pull request Apr 1, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants