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

can not control cursor color in nvim using guicursor option #2635

Closed
jdhao opened this issue Oct 16, 2022 · 26 comments
Closed

can not control cursor color in nvim using guicursor option #2635

jdhao opened this issue Oct 16, 2022 · 26 comments
Labels
bug Something isn't working

Comments

@jdhao
Copy link

jdhao commented Oct 16, 2022

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20221015-164502-7b904f05

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

setting the guicursor option for nvim can not change the cursor color when opening nvim inside wezterm.

To Reproduce

Content of test.vim:

set termguicolors
hi Cursor guifg=black guibg=red
set guicursor=n-v-c:block-Cursor/lCursor

Run nvim inside wezterm using following command:

nvim --clean -u test.vim test.vim

Configuration

no config

Expected Behavior

The cursor should be changed to red in normal mode, but instead it is not changed to red.

If I use the above config in kitty, the cursor is changed to red when opening nvim inside kitty.

Logs

No response

Anything else?

No response

@jdhao jdhao added the bug Something isn't working label Oct 16, 2022
@wez
Copy link
Owner

wez commented Oct 16, 2022

I think you may want to install and enable the wezterm terminfo for this to work.
https://wezfurlong.org/wezterm/faq.html#how-do-i-enable-undercurl-curly-underlines has information about this

@wez wez added the waiting-on-op Waiting for more information from the original poster label Oct 16, 2022
@jdhao
Copy link
Author

jdhao commented Oct 16, 2022

I have already done this (for the curly underline stuff). This does not work.

image

This is my cursor color after running env TERM=wezterm nvim --clean -u test.vim test.vim

image

@github-actions github-actions bot removed the waiting-on-op Waiting for more information from the original poster label Oct 16, 2022
@wez
Copy link
Owner

wez commented Oct 16, 2022

In #1625 it sounded like you already had this working?

Per my comments in #1073, I think this class of issue is more a question for the neovim folks: the terminal supports this functionality, but it's not clear what neovim uses to decide to use it. If you can go and find out, we can figure out what to do next.

@wez wez added the waiting-on-op Waiting for more information from the original poster label Oct 16, 2022
@jdhao
Copy link
Author

jdhao commented Oct 17, 2022

yeah, it once works, now wezterm and neovim both have a lot of updates, it stops working. If it is an neovim issue, I suppose kitty would also break? I do not know the internals, so do not know how to proceed.

@github-actions github-actions bot removed the waiting-on-op Waiting for more information from the original poster label Oct 17, 2022
@wez
Copy link
Owner

wez commented Oct 17, 2022

Using printf "\x1b]12;#ff00ff\x1b\\" in the shell does change the cursor color, but I think there is a cache invalidation issue that makes it not immediately appear.
If you use ctrl-+ or ctrl-- to change the font size, does the color get corrected in nvim?

@jdhao
Copy link
Author

jdhao commented Oct 17, 2022

No, using ctrl-- and ctrl-+ change the font size, but the color is not changed.

image

@txtyash
Copy link

txtyash commented Oct 25, 2022

I'm facing the exact same problem. In neovim, wezterm's cursor overrides neovim's colorscheme specific cursor.

Another problem is that the cursor doesn't have a foreground so in neovim I can't see the text under my cursor.

@jdhao
Copy link
Author

jdhao commented Nov 4, 2022

Related issue opened: neovim/neovim#20706.

The neovim dev said this is a problem of wezterm terminfo file. I am not sure which is right since I do not know the internal source code.

wez added a commit that referenced this issue Nov 7, 2022
nvim uses these to set the title string; really, it is setting the
status line, but it has an assumed fallback for xterm that redefines the
status line update operations in terms of setting the title of the xterm
window.

Let's ensure that our terminfo has these entries defined, as the nvim
fallback currently looks for `xterm` in the value of $TERM to decide
whether the fallback is appropriate, and that test does not pass when
the user has set term=wezterm.

refs: neovim/neovim#20706
refs: #2635

See also: https://codeberg.org/dnkl/foot/pulls/243/files,
https://codeberg.org/dnkl/foot/issues/242,
alacritty/alacritty#1636
@wez
Copy link
Owner

wez commented Nov 7, 2022

@jdhao that other issue is for the title string, which is now resolved by updating the terminfo file in main, however, this issue is about the guicursor, which wasn't discussed in neovim/neovim#20706

@jdhao
Copy link
Author

jdhao commented Nov 7, 2022

okay, assume i use wezterm as TERM, What should I do to make guicursor work?

@wez
Copy link
Owner

wez commented Nov 7, 2022

I think we need to ask the nvim folks about this explicitly!

@jdhao
Copy link
Author

jdhao commented Nov 7, 2022

okay, if this issue is not related to title, I will open a separate issue in neovim repo.

wez added a commit that referenced this issue Nov 13, 2022
Things like compose cursor and dynamically changed cursor colors
were not factored into our cache keys, making the cursor color
"sticky" in the wrong ways.

refs: #2708

Might possibly also help with #2635
@wez
Copy link
Owner

wez commented Nov 13, 2022

I fixed a cache invalidation issue with the cursor color in main just now; it may affect this issue, but I'm not sure.
Could you try a nightly build in about an hour (once it builds out), or build from source and try that?

@jdhao
Copy link
Author

jdhao commented Nov 14, 2022

I tried latest version (commit 36f215c03e6fef26e841df20e880c695de0358a2), the cursor color still does not work.

@ratheesh
Copy link

@jdhao , I just tried with latest commit(a7332ba9b429f9676723eb88cffb2068f5a95c9b) from Neovim and cursor color settings through guicursor works fine.

@janislaus
Copy link

I'm still having this issue. Can reproduce it with the stable and nightly build of wezterm on ubuntu 22.04 and windows 10. The guicursor color is set properly in all other terminal emulators I've tried (Kitty, Gnome and Alacritty).
Are there any updates on this?

@bugabinga
Copy link

bugabinga commented Oct 14, 2023

I can reproduce this issue, but only when cursor_thickness = '1cell' is set in my wezterm.lua.

The symptom seems to be that with above setting the cursor is always* a 1cell block of in wezterm configured color, regardless of the guicursor option or Cursors highlight in neovim.

*: not really always. It is complicated. Foreground color set in neovim seems to always be ignored by wezterm. Background color can be changed in some mode (normal, visual) but not in others (insert).

It is possible, that we have a beautiful interplay of 2 bugs in wezterm and neovim, but I think it is safe to assume we have an issue in wezterm in regards to the cursor_thickness = '1cell'-setting.

@david-haerer
Copy link

david-haerer commented Dec 26, 2023

I also experience this issue. Here are some relevant infos

  • NeoVim version v0.10.0-dev-1956+gec7453804.
  • Wezterm version 20230712-072601-f4abf8fd.
  • Wezterm color scheme Ayu Dark (Gogh).

I'd like to get it fixed, so I'm thankful for any hint for debugging.


Edit 1: The cursor settings work fine in Alacritty.


Edit 2: Here is a minimal example of a NeoVim config. In Alacritty, the cursor is the reverse of the syntax highlighting colors. In Wezterm this is not the case.

highlight Cursor gui=reverse guifg=NONE guibg=NONE

Edit 3: It seems like it is a problem with my Wezterm color scheme. With an empty config in my wezterm.lua it works as expected.


Edit 4: It does not work entirely as expected. In Alacritty, the cursor color in NeoVim is actually the reverse of the font color, depending on the syntax highlighting. In Wezterm, without any color scheme, the cursor has the same color independent of the font color / syntax highlighting.


Edit 5: I can set the cursor color in Wezterm with

config.colors = {
  cursor_bg = "#000000",
  cursor_fg = "#FFFFFF",
  cursor_border = "#000000",
}

This is also used as cursor color in NeoVim.


Edit 6: This is basically what I have settled on :)

wez added a commit that referenced this issue Feb 1, 2024
@wez
Copy link
Owner

wez commented Feb 1, 2024

I fixed a different invalidation issue just now that may relate to this issue.
That should be available in nightly builds within about an hour; please give it a try and let me know if that was really it this time!

@kuznetsss
Copy link

Hi @wez, thanks for trying to fix it!

I downloaded the artifact from https://github.com/wez/wezterm/actions/runs/7748751221, unpacked and run WezTerm-macos-20240201-155814-aa94a983/WezTerm.app/Contents/MacOS/wezterm.

Unfortunately the cursor stays the same color in neovim 0.9.5. I have terminfo installed and I tryied to start nvim with TERM=wezterm.

The interesting thing is that for both the latest release and this nightly build cursor does change color in the command window of noice.nvim. But this happens only there, maybe that window has a different cursor color implementation.
Screenshot 2024-02-02 at 13 16 03

@wez
Copy link
Owner

wez commented Feb 2, 2024

Looking at this again: printf "\x1b]12;#8000ff\x1b\\" works to immediately set the cursor color, so the fundamental capability works.
If nvim cannot set it, then we need some to ask the nvim folks how it decides whether the cursor color can be changed, then we can figure out how to close that gap.
I do not use nvim and do not have time to do this.
I asked previously in this issue for someone to reach out to the neovim folks explicitly about this, but I don't know if that happened.

@kuznetsss
Copy link

kuznetsss commented Feb 3, 2024

I think the issue is related only to inversed cursor color. And I just realised it happens not only in neovim.

Zsh syntax highlighting in Alacritty:
Screenshot 2024-02-03 at 10 55 14

Zsh syntax highlighting in WezTerm:
Screenshot 2024-02-03 at 10 55 30

EDIT:
I thought there is a terminal escape sequence which is responsible for reversing cursor color but I didn't find it.
So I think the answer is very simple - different default behaviour.

By default Alacritty has reversed cursor on. While WezTerm by default has specific cursor color.
If I force Alacritty to use specific cursor color:

[colors]
cursor = { text = "#121212", cursor = "#aa0000" }

It starts to behave exactly like WezTerm. Cursor color stays the same in neovim and in zsh with syntax highlighting.

And if I turn on force_reverse_video_cursor = true for WezTerm it starts to show inversed cursor like Alacritty by default.

@david-haerer
Copy link

Thanks a lot for the insight! For me that solves the issue. 🎉

@kuznetsss
Copy link

@wez, could you please review this issue and the related one in Neovim?
I think the problem was only in different defaults and setting force_reverse_video_cursor = true solves the probem.
If you agree I assume we could close this issue.

@wez
Copy link
Owner

wez commented Feb 4, 2024

I looked at it the other day; it seems like the color isn't being changed at all in nvim, so guicursor is a red herring and that the problem is just that the expectation was that the cursor be in reverse video mode, which is not the default mode in wezterm.

I'm happy to close this.

@wez wez closed this as completed Feb 4, 2024
Copy link

github-actions bot commented Mar 6, 2024

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

8 participants