Use crossterm cursor when terminal loses focus

[hnorkowski]

All but the documents block cursor change their shape to a box outline if the terminal loses focus. I am missing that feature because (depending on your window manager) it can be hard to tell which editor has focus if you have multiple open at the same time. Because the custom rendered block cursor is just the background color of the respective char it is no possible to achieve the same behavior (display as outline).

Therefore I created a proof of concept for the custom block cursor to change its color when the terminal window loses focus.

If the theme does not define a color for the unfocused cursor (e.g. ui.cursor.primary.unfocused) it should calculate the color by faking transparency of the cursor. Therefore it tries to get the background color and the cursor color and mix them.

Currently I have 2 main problems with the color calculation:

• I do not know how to get the RGB values of a named color (e.g. yellow) but I need those to calculate the "transparent" cursor color
• Some themes (e.g. default) do not define a cursor color (Style.bg is None). There are default colors defined but I do not know how I can query them.
• I also tried to use the DIM modifier but it did not seem to have any effect (atleast in alacritty). I forgot to create a commit for that but if desired I could reimpl. that to analyze why it did not work.

The current implementation works well with some themes, e.g. gruvbox, catpuccin_*, emacs.

Another questions that should be discussed:

• If the feature gets accepted, should it be the default?
  • I think yes because all other cursors have this behavior

[the-mikedavis]

Named colors (cyan, yellow, red, etc.) are defined by the terminal (for example https://sw.kovidgoyal.net/kitty/conf/#the-color-table) and there's no way to query their value from a terminal application. I don't think we should be blending colors anyways though: all colors should be written out explicitly in a theme

[archseer]

Hmm this is probably a better idea than what I had: I simply hid the cursor. But that makes it a bit confusing when the window is out of focus since no other editor would behave that way

[pascalkuthe]

This looks good to me. It would be nice if you could define an unfocused color for the default theme tough (the rest of the themes can be changed by their author but it's nice if the default works)

[hnorkowski]

This looks good to me. It would be nice if you could define an unfocused color for the default theme tough (the rest of the themes can be changed by their author but it's nice if the default works)

Yeah I am trying to but I cannot figure out the default theme keys. The cursor has different colors depending on if its on a char or a whitespace and cannot figure out where this behavior is defined the theme.toml. With my current impl. the cursor will always have the same color when out of focus.

[pascalkuthe]

This looks good to me. It would be nice if you could define an unfocused color for the default theme tough (the rest of the themes can be changed by their author but it's nice if the default works)

Yeah I am trying to but I cannot figure out the default theme keys. The cursor has different colors depending on if its on a char or a whitespace and cannot figure out where this behavior is defined the theme.toml. With my current impl. the cursor will always have the same color when out of focus.

That's default theme uses "ui.cursor" = { modifiers = ["reversed"] } which just swaps foreground and background color. Even if you keep reversed changing the bg color would involve overwiting the fg color so defining different colors for whithespaces is not possible. I think that's ok this distinction isn't that important if the editor isn't focused.

[hnorkowski]

But this creates the problem that I need to chose a color that works well for all colors the cursor can have. This is kinda tricky. I will try to find a good one.

[pascalkuthe]

I marked this as ready for review as we are already reviewing. If you feel this is not ready yet feel free to change the status again. There seem to be some problems with the default theme and lints that need fixing (see CI)

[hnorkowski]

I think this is ready. I updated the catppuccin mocha theme to support this feature aswell.

The only thing that could need work is the default theme. You guys might wanna check it out and maybe even try if you like other colors more.

[the-mikedavis]

This is looking good, just a minor comment. We'll also want to get @archseer's review since this touches the default theme

[hnorkowski]

This is not ready yet. I think we should go back to draft. I want to try this idea:

So my idea is: Why not just change the cursor type to bar while helix has no focus and back to block when its in focus again?

However I am a bit lost in the code base. I was yet not able to find the correct place to overwrite the cursor. I found how to overwrite the cursor when the crossterm cursor is in use but I could not figure out how to switch between crossterm cursor and custom cursor. Unfortunately I didn't had much time recently. Maybe you have a hint for me?

[the-mikedavis]

helix/helix-term/src/application.rs

Lines 1152 to 1156 in 8c68074

	use helix_view::graphics::CursorKind;
	self.terminal
	.backend_mut()
	.show_cursor(CursorKind::Block)
	.ok();

is a good example of explicitly setting a block cursor

[hnorkowski]

I finally managed to impl. the behavior. It seems to work flawless.

The only point left to discuss: Should we also do something about secondary cursors? Currently only the main cursor is changing when losing focus. I think for me thats ok. What is your opinion?

[the-mikedavis]

I think we can leave secondary cursors as-is. We can't make them bars (we just fill in a background to make them look like blocks normally) like the primary cursor. We could add theming for them when unfocused like the original change in this PR if the bar cursor isn't clear enough. That could probably be a follow-up though

[hnorkowski]

Yeah I think you are right that it could be a follow-up after using this for some time and see if it would be helpful.

With that I think the PR is ready. Should I update the initial PR message?

[the-mikedavis]

Just a minor nit about a comment.

I like this behavior - it looks nice to me on Kitty for single panes and splits