Handle horizontal scrolling on macOS touchpads

[barkure]

Fixes vertical scroll jitter when using a macOS touchpad.

Validation

• Release build completed successfully locally
• Verified manually on macOS with a touchpad

Co-authored-by: Leonard Hecker leonard@hecker.io

[barkure]

The same underlying issue may also affect touchpad input on Linux or Windows, but I was only able to reproduce and verify it on macOS because I do not currently have a Linux or Windows device with a touchpad available for testing.

[lhecker]

xterm describes encoding for additional buttons which my original code (and also your changes) would confuse for scroll events: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Other-buttons
I'll try to fix this.

[lhecker]

@DHowett I have tested this PR on macOS using Ghostty. The behavior is rather bad, if I'm honest. Ghostty simply doesn't implement "dominant axis scrolling".

I consider this a flaw of the terminal, however, as applications should not be made to implement such algorithms. Ghostty does appear to want this behavior too: https://github.com/ghostty-org/ghostty/blob/853183e911b70ff7b61057f52fc7b47ea4934238/macos/Sources/Ghostty/Surface%20View/SurfaceScrollView.swift#L33-L36

However, they did a whoopsie because if you disable both hasVertical/HorizontalScroller the entire machinery is disabled. They need to either make full use of the native scrollbars without programmatic scrolling or implement dominant axis scrolling themselves in the scroll event handler.

Yay/nay?

[DHowett]

Unfortunately, there's only one edit and 30,000,000 terminal emulators. I'm sure we'll be stuck working around quirks in one or more of them before too long.

[lhecker]

So, if we never start working around quirks, we never have to worry about it. 🙈

In this case, what are we expected to do? Ignore valid inputs? But with what heuristic? What if the user does want free bidirectional scrolling? And so on...