Expose hollow-block in DECSCUSR

[rockorager]

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Extend the DECSCUSR enum to include

...
7 = blinking hollow block
8 = hollow block

Describe alternatives you've considered
None.

Additional context
@dnkl is investigating extending the DECSCUSR enum to include blinking hollow block, and hollow block. Kitty currently allows setting the unfocused shape as hollow, but not the focused shape - nor is it available for TUI applications to set explicitly.

In kitty's case, I think this should also be exposed as a configuration option for cursor_shape (I don't know why anyone would use this...but if it's available in DECSCUSR may as well make it available to users).

foot pr adding configuration option
ghostty discussion

[kovidgoyal]

Yes, I have reserved hollow as the shape for unfocused cursors. I don't
think I want to encourage TUI apps to start using this shape. For a
multiplexing terminal like kitty it is particularly important to have
multiple focus indicators to make it easy for users to know when a
window is focused or not. What's the use case for hollow cursors in TUI
apps? Do you know of any actual app that wants to use this?

[rockorager]

I don't know of anyone asking for this, but I do know a couple use cases where I would find it helpful. Mostly in floating windows which have a pick list and an input field. For example, fzf could have a modal option which allows "focusing" the pick list, enabling vim style navigation, but keeping the "cursor" shown in the input box as "unfocused".

Here, the input is focused and my keyboard input goes there.

But you could imagine a world where I "unfocus" that and focus the list instead, where vim bindings "just work"

This particular situation happens a lot in TUI's, so I think it could be a valuable pattern to follow.

[kovidgoyal]

Why not just hide the cursor in that case if it's unfocused?

[rockorager]

Why not just hide the cursor in that case if it's unfocused?

That would work, and is the accepted pattern - yet kitty (and basically every other terminal) don't do this and instead render a hollow block cursor to indicate loss of input focus. I think that pattern is valuable within a TUI as well.

[kovidgoyal]

On Wed, Feb 19, 2025 at 06:58:39AM -0800, Tim Culverhouse wrote: rockorager left a comment (kovidgoyal/kitty#8353) > Why not just hide the cursor in that case if it's unfocused? That would work, and is the accepted pattern - yet kitty (and basically every other terminal) don't do this and instead render a hollow block cursor to indicate loss of input focus. I think that pattern is valuable *within* a TUI as well.

Yeah and since they do, if terminal UIs start doing it as well it becomes very confusing. A hollow cursor in kitty means that the key presses dont go to the kitty window at all. If a TUI app sets the cursor to hollow, keys are still going to that window, so for instance, pressing ctrl-c or the close window shortcut and so on will all take effect. Making the hollow cursor essentially useless as an indicator of lost focus. TUI *apps* as opposed to terminals themselves should hide the cursor if no input field is currently accepting input.