OSC 22 support

[rockorager]

Is your feature request related to a problem? Please describe.
Both foot and xterm support OSC 22, which allows terminal applications to set the shape of the mouse. This is an xterm extension as far as I can tell, but foot has support. There is an open PR on alacritty as well.

Describe the solution you'd like
Implement OSC 22 in Kitty. Xterm doesn't have great specs for every edge case. The sequence is

OSC 22 ; Pt BEL

Where Pt is a W3C cursor name in plain ASCII.

• The terminal should only honor mouse shapes when mouse reporting is on
• The mouse shape should be reset along with the rest of the terminal state
• Terminal should override mouse shape for text selection (and restore back to whatever application has set)

Describe alternatives you've considered
Not having mouse shapes. It's a valid alternative but not as fun. Applications can provide nicer hints to user regarding interactivity (resizing of panes / fields, clickable buttons, etc)

Additional context
A demo in foot: https://0x0.st/H4Vl.mp4

[kovidgoyal]

On Thu, Oct 12, 2023 at 06:35:26PM -0700, Tim Culverhouse wrote: - The terminal should only honor mouse shapes when mouse reporting is on

There are various types of mouse reporting, only clicks, positions, pixel positions, etc. Which ones apply?

- The mouse shape should be reset along with the rest of the terminal state - Terminal should override mouse shape for text selection (and restore back to whatever application has set) **Describe alternatives you've considered** Not having mouse shapes. It's a valid alternative but not as fun. Applications can provide nicer hints to user regarding interactivity (resizing of panes / fields, clickable buttons, etc)

I can agree this is potentially useful, though I have to say I dont have a lot of personal use for it as I dont use the mouse for anything other than selections in the terminal. That said, I dont think my personal usage patterns have to control the availability of features.

[kovidgoyal]

Also does a shape set by this escape code survive having mouse reporting
turned off and on again? In other words how does this bit of state
interact with the mouse reporting state. Is it persistent, or should it
be reset when mouse reporting is turned off and also when it is turned on. What about
when mouse reporting changes the type of reporting.

Is there a set of cursor shapes a terminal is required to implement?
The CSS cursor property supports a whole passel of them, I know not all
platforms have all of them. GLFW which kitty is based on just supports a
handful. And just for the record xterm says nothing
about CSS names as far as I can see, it uses X11 names,
https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:pointerShape

Is there a mechanism for the application to query the current cursor
shape? Is 22 ? t supposed to have the terminal respond with the current
cursor? What is the response if it is unset (aka default)? kitty for
instance allows users to configure the cursor shapes. Should the
response for the default be that configured shape or just "default" or
the empty string or what?

I really wish xterm would stop creating these poorly specified things.

[rockorager]

Also does a shape set by this escape code survive having mouse reporting turned off and on again? In other words how does this bit of state interact with the mouse reporting state. Is it persistent, or should it be reset when mouse reporting is turned off and also when it is turned on. What about when mouse reporting changes the type of reporting.

These are great questions. I actually wonder if this should be tied to mouse mode at all. At first it seemed that an application would need to know *something* about the mouse state to be able to want to change the shape, but instead it could be setting it to "busy" or something - in which case it never cares about mouse reporting. I probably spoke too soon saying it should be tied to mouse mode.

Is there a set of cursor shapes a terminal is required to implement? The CSS cursor property supports a whole passel of them, I know not all platforms have all of them. GLFW which kitty is based on just supports a handful. And just for the record xterm says nothing about CSS names as far as I can see, it uses X11 names, https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:pointerShape

Sorry, I failed to mention that there is an active request (via email) to Mr. Dickey to allow for W3C cursor shapes in his sequence. xorg, wayland, and macOs certainly all interpret these values already. I think it would be safe to say a terminal should support all values defined by W3C (except the '<uri>' value), OS's should have all of these available already since it's in browsers. https://www.w3.org/TR/CSS21/ui.html#propdef-cursor

Is there a mechanism for the application to query the current cursor shape? Is 22 ? t supposed to have the terminal respond with the current cursor? What is the response if it is unset (aka default)? kitty for instance allows users to configure the cursor shapes. Should the response for the default be that configured shape or just "default" or the empty string or what?

There isn't a mechanism to do this, and I'm not certain it is required. Browser behavior is to try for what the user requested and ultimately falls back to a pointer - so I think it's already a precedent that application developers can _attempt_ to set a cursor shape, but it may not be honored. There is no mechanism in a browser to ask for the current shape - and I wouldn't expect needing one in a terminal either. Applications can attempt to set it and allow the fallbacks to happen as they will.

I really wish xterm would stop creating these poorly specified things.

I agree. I would be happy to write up a spec for OSC 22 to at least formalize the discussion.

[kovidgoyal]

On Fri, Oct 13, 2023 at 09:06:30AM -0700, Tim Culverhouse wrote: > Also does a shape set by this escape code survive having mouse reporting > turned off and on again? In other words how does this bit of state > interact with the mouse reporting state. Is it persistent, or should it > be reset when mouse reporting is turned off and also when it is turned on. What about > when mouse reporting changes the type of reporting. These are great questions. I actually wonder if this should be tied to mouse mode at all. At first it seemed that an application would need to know *something* about the mouse state to be able to want to change the shape, but instead it could be setting it to "busy" or something - in which case it never cares about mouse reporting. I probably spoke too soon saying it should be tied to mouse mode.

I dont really see why it should be tied to mouse reporting. If you have a reason happy to discuss.

> Is there a set of cursor shapes a terminal is required to implement? > The CSS cursor property supports a whole passel of them, I know not all > platforms have all of them. GLFW which kitty is based on just supports a > handful. And just for the record xterm says nothing > about CSS names as far as I can see, it uses X11 names, > https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:pointerShape Sorry, I failed to mention that there is an active request (via email) to Mr. Dickey to allow for W3C cursor shapes in his sequence. xorg, wayland, and macOs certainly all interpret these values already. I think it would be safe to say a terminal should support all values defined by W3C (except the '<uri>' value), OS's should have all of these available already since it's in browsers. https://www.w3.org/TR/CSS21/ui.html#propdef-cursor

OK, I am happy to use those as a set of basic names.

> Is there a mechanism for the application to query the current cursor > shape? Is 22 ? t supposed to have the terminal respond with the current > cursor? What is the response if it is unset (aka default)? kitty for > instance allows users to configure the cursor shapes. Should the > response for the default be that configured shape or just "default" or > the empty string or what? There isn't a mechanism to do this, and I'm not certain it is required. Browser behavior is to try for what the user requested and ultimately falls back to a pointer - so I think it's already a precedent that application developers can _attempt_ to set a cursor shape, but it may not be honored. There is no mechanism in a browser to ask for the current shape - and I wouldn't expect needing one in a terminal either. Applications can attempt to set it and allow the fallbacks to happen as they will.

OK. I dont know of a use case offhand.

> I really wish xterm would stop creating these poorly specified things. I agree. I would be happy to write up a spec for OSC 22 to at least formalize the discussion.

That would be good.

[rockorager]

> There isn't a mechanism to do this, and I'm not certain it is required. Browser > behavior is to try for what the user requested and ultimately falls back to a > pointer - so I think it's already a precedent that application developers can > _attempt_ to set a cursor shape, but it may not be honored. There is no > mechanism in a browser to ask for the current shape - and I wouldn't expect > needing one in a terminal either. Applications can attempt to set it and allow > the fallbacks to happen as they will. OK. I dont know of a use case offhand.

The one thing that would be nice is a terminfo name for this so I can query with XTGETTCAP. Whether it gets added to terminfo databases doesn't matter but a common name to query is preferred. How does that sound? It's just nice to know for sure if a terminal will support it or not. I don't see this listed in https://invisible-island.net/xterm/terminfo.html at all.

> I agree. I would be happy to write up a spec for OSC 22 to at least formalize > the discussion. That would be good.

Will post back when I have something. Thanks for considering!

[kovidgoyal]

On Fri, Oct 13, 2023 at 10:40:59AM -0700, Tim Culverhouse wrote: The one thing that would be nice is a terminfo name for this so I can query with XTGETTCAP. Whether it gets added to terminfo databases doesn't matter but a common name to query is preferred. How does that sound? It's just nice to know for sure if a terminal will support it or not.

It's fine by me, since as I said I dont have a use case for this. kitty already supports extended properties for XTGETTCAP, see https://sw.kovidgoyal.net/kitty/kittens/query_terminal/ However, putting on my spec developer hat, different terminals on different platforms will end up supporting a different set of cursors. Many of the CSS cursors don't even exist on macOS for instance as standard cursors, see the docs of NSCursor. So rather than using terminfo based properties, it would be better if you are having querying at all to query with OSC 22 ? t to which the terminal replies with a comma separated list of names, the first of which is the current shape, the second the default ungrabbed shape, the third the default grabbed shape, and the rest the other names it supports.

> > I agree. I would be happy to write up a spec for OSC 22 to at least formalize > > the discussion. > > That would be good. Will post back when I have something.

Cool.

[kovidgoyal]

And just FYI that W3C list misses out some important ones, like
the double resize, zoom and vertical text cursors. A more complete list is at
https://developer.mozilla.org/en-US/docs/Web/CSS/cursor

[kovidgoyal]

I decided to spend my weekend implementing and specing this. The spec is
in pointer-shapes.rst feel free to comment on it, it is not yet set in
stone.

[rockorager]

On Sun Oct 15, 2023 at 9:30 AM CDT, Kovid Goyal wrote: I decided to spend my weekend implementing and specing this. The spec is in pointer-shapes.rst feel free to comment on it, it is not yet set in stone.

Awesome - thanks for working on it already. I tested this out and happen to use two pointer shapes not implemented, but do exist in the CSS standard: `col-resize` and `row-resize`. These are really just aliases for `ew-resize` and `nw-resize`. I also don't see `cell`, another one I think has some cool uses. Re: the spec, this looks great to me. I had been thinking about your `OSC 22 ; ? ST` idea, and I agree this is a better way than `XTGETTCAP`, nice to see how you've implemented it. It might be helpful to explicitly state in "Interaction with other terminal features" that mode _does not require_ any specific mouse mode to be enabled for it to work. This is implicit in everything else you wrote, but may prevent some questions or sub-par implementations. Thanks again!

…

-- Tim

[kovidgoyal]

On Mon, Oct 16, 2023 at 07:50:17AM -0700, Tim Culverhouse wrote: On Sun Oct 15, 2023 at 9:30 AM CDT, Kovid Goyal wrote: > I decided to spend my weekend implementing and specing this. The spec is > in pointer-shapes.rst feel free to comment on it, it is not yet set in > stone. Awesome - thanks for working on it already. I tested this out and happen to use two pointer shapes not implemented, but do exist in the CSS standard: `col-resize` and `row-resize`. These are really just aliases for `ew-resize` and `nw-resize`. I also don't see `cell`, another one I think has some cool uses.

col-resize and row-resize dont exist on any real platform (apart from CSS). They aren't as far as I can see in any of cocoa, wayland or X11. So if I were to add them to the spec terminal implementers would need to use custom images for them or just re-use the vertical and horizontal resize cursors. Practically speaking I would imagine it's the latter. I dont want to burden terminal emulator developers with having to ship custom cursor images (there are lots of issues with this like cursor size) as it will hinder spec adoption. cell I have added.

Re: the spec, this looks great to me. I had been thinking about your `OSC 22 ; ? ST` idea, and I agree this is a better way than `XTGETTCAP`, nice to see how you've implemented it. It might be helpful to explicitly state in "Interaction with other terminal features" that mode _does not require_ any specific mouse mode to be enabled for it to work. This is implicit in everything else you wrote, but may prevent some questions or sub-par implementations.

Done.

[rockorager]

col-resize and row-resize dont exist on any real platform (apart from CSS). They aren't as far as I can see in any of cocoa, wayland or X11. So if I were to add them to the spec terminal implementers would need to use custom images for them or just re-use the vertical and horizontal resize cursors. Practically speaking I would imagine it's the latter. I dont want to burden terminal emulator developers with having to ship custom cursor images (there are lots of issues with this like cursor size) as it will hinder spec adoption.

Makes sense. I've updated my library to just use `ew-resize` and `ns-resize` Also nice touch using this in the `ask` kitten.

[kovidgoyal]

It's on my TODO list to add these shapes to the mouse_demo kitten as well.