After updating to `hwatch 0.3.14`, `hwatch --mouse` stopped working

[Ilya Grigoriev]

When running, HWATCH= hwatch --mouse "seq 1000" scrolling the mouse does nothing. I expect it to scroll.

hwatch 0.3.13 works fine.

Let me know if you need help debugging. Otherwise, I'll keep using 0.3.13 for a bit.

I'm using Mac OS Sonoma 14.5 on Apple Silicon.

$ uname -a
Darwin macaw.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:14:38 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6020 arm64 arm Darwin

As ever, thank you for working of hwatch! I use it every day :).

[blacknon]

thank you for issue.
I reproduced it.

Umm...I wonder how this could happen.
It looks fine at first glance in code.

[Ilya Grigoriev]

I tried out Git bisect. The commit that broke --mouse seems to be d69253e. It seems to be the squash of several commits. In PR #116, the first bad commit is:

3b36320

I'll let you know if I find out more. Just looking at the code, nothing immediately jumped out at me either.

[blacknon]

umm..

To begin with, the description method is not consistent with other flags, so it might be better to fix that together as well.

[Ilya Grigoriev]

It's possible you're already aware, but I tried #130, and it doesn't solve the problem completely.

• The --mouse command-line option no longer seems to do anything.
• The m button inside hwatch toggles whether hwatch captures the mouse. However, scrolling the mouse does not work even if the mouse is captured. (This is actually the same as what hwatch 0.3.14 does).

[blacknon]

Hmmm... what does it mean? 🤔 🤔
I thought it was ok because it scrolled in my environment (M1 Mac + iTerm2).

So far, in my environment, it scrolls when mouse capture is enabled by giving the --mouse option or by toggling with the m key.

[Ilya Grigoriev]

That's really strange.

I'm generally using tmux + Kitty, but I just tried it in on plain Iterm2 Build 3.4.23, and it did not scroll there either (same behavior as with tmux+Kitty). I'm also on an Apple Silicon Mac, Sonoma 14.5.

I'm on commit 73f7414 and I'm running HWATCH= cargo +beta run -- --mouse "seq 1000".

Update: Just tried on on iTerm 3.5.1, same result.

[blacknon]

I ran it via tmux in my environment and confirmed that mouse scrolling does not work.
The scrolling works without going through tmux in my environment, so the events may be a little different again.

[Ilya Grigoriev]

I forget whether tmux requires set mouse on to pass mouse events. You should check that scrolling can work for hwatch 0.3.13 or other programs.

I am very confused about why we'd get a different behavior with plain iTerm2. How could 0.3.13 work for both of us, 0.3.14 not work for both of us, and then the prerelease work for you and not work exactly the same as 0.3.14 for me? Are you also testing 73f7414? Could you be using much older iTerm? Here are my iTerm options (iTerm2 build 3.5.1), nothing special here.

I get the same behavior with Mac OS's built-in Terminal too.

[Ilya Grigoriev]

Also, this is a complete aside, but hwatch fails to compile on nightly Rust from 2024-06-10. This can be fixed by running cargo update.

This is not a bug, strictly speaking, and you might want to separate bugfixing and dependency updating, so I didn't want to file an issue; this is just an FYI.

[Ilya Grigoriev]

Oh, I believe the behavior on prerelease is not completely the same. I think that --mouse is backwards now: hwatch captures the mouse if --mouse is not specified, and does not capture the mouse if --mouse is specified.

Unfortunately, scrolling doesn't work for me either way. I also try toggling the mouse with m inside hwatch, which does uncapture/capture the mouse, but doesn't help with scrolling.

[blacknon]

It's still unconfirmed, but it seems like tmux isn't able to properly capture the mouse scroll down...? 🤔

[blacknon]

Oh, I think it's because of the keymap modification.

[Ilya Grigoriev]

Thank you! 0.3.15 seems to work fine so far.