Mouse pointer icon is not changed to arrow when mouse is captured

[wooster0]

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

When mouse capturing is enabled (e.g. through printf "\e[?1003h"), the mouse pointer icon is not changed to an arrow and stays the beam icon. This is inappropriate for programs that let the user click on something.

Describe the solution you'd like

The mouse pointer icon should be changed to an arrow.
I believe some calls to change the mouse icon should be inserted in places like here:
https://github.com/wez/wezterm/blob/main/term/src/terminalstate.rs#L2053
I tried to do this but couldn't quite figure out how to change the mouse icon from there.

Additional context

It feels pretty awkward to play yayagram like this

[wez]

A consequence of making this change would be that eg: vim with :set mouse=a is enabled would have an arrow instead of the I-beam cursor, which is undesirable for working with text in the editor.

Do other terminal emulators change the mouse cursor to an arrow?
Neither iTerm2 nor Terminal.app have that behavior on the mac.

[wez]

FWIW, this is the patch to change to implement the behavior if you wanted to play around with it; as mentioned above, I don't think this should go in as-is.

diff --git a/wezterm-gui/src/termwindow/mouseevent.rs b/wezterm-gui/src/termwindow/mouseevent.rs
index 345fc96a..4f3540b5 100644
--- a/wezterm-gui/src/termwindow/mouseevent.rs
+++ b/wezterm-gui/src/termwindow/mouseevent.rs
@@ -435,6 +435,8 @@ impl super::TermWindow {
                     // When hovering over a hyperlink, show an appropriate
                     // mouse cursor to give the cue that it is clickable
                     MouseCursor::Hand
+                } else if pane.is_mouse_grabbed() {
+                    MouseCursor::Arrow
                 } else {
                     MouseCursor::Text
                 }

[wooster0]

A consequence of making this change would be that eg: vim with :set mouse=a is enabled would have an arrow instead of the I-beam cursor, which is undesirable for working with text in the editor.

Do other terminal emulators change the mouse cursor to an arrow?
Neither iTerm2 nor Terminal.app have that behavior on the mac.

Yes, a lot of major terminals do, including GNOME Terminal, alacritty, VS Code terminal, kitty, Konsole and many others. I think it's pretty standard behavior.
Also I don't think it feels that weird to select text in Vim with the arrow and I'm not sure that case alone justifies not adding it. I believe the majority of programs that capture the mouse will allow you to press buttons or do stuff like in yayagram where a beam icon is particularly undesirable.
Also, I have the impression that terminal text editors are mostly used with the keyboard alone so I think this is a case that probably won't affect a lot of users.

[AaronErhardt]

I hope you don't mind me joining the discussion.

From my perspective the arrow cursor is a better default than the text cursor. I've been using neovim with various terminal emulators and all of them used an arrow cursor for selecting text and honestly I haven't even noticed until now. Especially for yayagram but also for many other tui apps an arrow is essential for accurately clicking and selecting elements.

The only use-case I see for the text cursor is for non-interactive elements. This would also help the user to distinguish applications that capture mouse input from applications that don't.

Apart from that wezterm is exceptionally great! I really hope we can come up with a reasonable solution to fix this issue :)

[wooster0]

Here's an example of this mouse inaccuracy, you can experience it on the exit screen:
(notice how the button is white as if it's hovered even though it's not, at least graphically)
This same problem exists for programs that capture the mouse and have buttons like this. With an arrow cursor, like most terminals do it, clicking would feel better and less imprecise and would probably fix this problem.

[github-actions]

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.