Implement 'mouseshape' option like Vim

[sfsam]

Feature description

Neovim has a help entry for the mouseshape option, but it is currently not implemented. It is useful in GUIs for visual feedback. For example, in Insert mode, the mouse shape is typically an I-Beam whereas it is an Arrow in Normal mode. When hovering over a split or status line, it becomes a left-right or up-down shape to indicate the element can be resized.

This option is implemented in Vim and is used by the MacVim GUI for this purpose. It would be good if Neovim also allowed this option to be set by the user and provided this information to GUIs so they can set the mouse pointer shape as appropriate.

[Tmpod]

I'd like to work on this, but I'm unsure where to start. Could anyone give me some pointers? Thanks!

[justinmk]

@Tmpod this commit added the 'mousescroll' option which gives a hint about related areas: 93c8fe7

Note that "GUI options" are emitted as UI events for UIs to listen to, via "option_set" UI event:

neovim/runtime/doc/ui.txt

Lines 63 to 66 in 2dc439c

	By default Nvim requires all connected UIs to support the same capabilities,
	thus the active capabilities are the intersection of those requested. UIs may
	specify |ui-override| to invert this behavior (useful for debugging). The
	"option_set" event announces which capabilities are active.

[zeertzjq]

mode_info_set may be the actual UI event that needs change here, as 'mouseshape' is very similar to 'guicursor'.

Related #23796

[gpanders]

The TUI can support this with the OSC 22 escape sequence, which is supported by at least Kitty and a few other terminals https://sw.kovidgoyal.net/kitty/pointer-shapes/

The list of cursor shapes supported by that protocol is here. Vim has a different list of names. The list in kitty's document is based on the cursor property from the CSS standard.

I think we should not enforce a static list of names, but allow users to specify whichever shape name they want (linking to the kitty document above for examples). That way GUIs can implement their own shapes if they want to. But the TUI would only support the shapes listed by the kitty protocol.

[fredizzimo]

mode_info_set might not be is good enough for a GUI, due to the lag. The cursor needs to respond quickly on mouse movements, when hovering over links or splits for example. And especially if nvim is running on a remote server it can take relatively long for the roundtrip needed. Furhermore it would depend on mousemoveevent being enabled all the time which causes a lot of RPC traffic.

That was one of the motivations for the rejected ext_elementtype, #28016. But I still think that something similar is needed.