Shift + mouse wheel does not send shift

[otomn]

Issue Description

I have the following vim config

noremap <s-up> <cmd>exe "normal! \<c-y>"<cr>
noremap! <s-up> <cmd>exe "normal! \<c-y>"<cr>
noremap <s-down> <cmd>exe "normal! \<c-e>"<cr>
noremap! <s-down> <cmd>exe "normal! \<c-e>"<cr>

Which allows me to scroll the content up and down using mouse wheel without enabling mouse mode (whereas regular mouse wheel moves the cursor line).

Expected Behavior

In iTerm2, holding shift while scrolling down does trigger <s-up> and move the content up and down.

Actual Behavior

Ghotty appears to be just sending <up> unless mouse mode is enabled.

Reproduction Steps

Use vim config

noremap <s-up> <cmd>exe "normal! \<c-y>"<cr>
noremap! <s-up> <cmd>exe "normal! \<c-y>"<cr>
noremap <s-down> <cmd>exe "normal! \<c-e>"<cr>
noremap! <s-down> <cmd>exe "normal! \<c-e>"<cr>
set mouse=

Open help doc and hold shift to scroll.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 26.4 (25E246)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

// none

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[rhodes-b]

Im not sure what behavior you expect to see but on linux I see no difference with scroll-wheel up and shift scroll-wheel up using your vim config (I assume thats what you are reporting)

I believe this is because shift actually overrides mouse reporting in the alternate screen and lets ghostty handle mouse events (even for programs that don't have mouse events)

This lets you select text from ghostty instead of in vim for example, or do link detection

This is currently not configurable
#3848
#11210

[rhodes-b]

Shift is captured by ghostty in the alternate screen that is why its not encoded this allows ghostty full control over the mouse in the alternate screen as a method to override programs which do capture the mouse.

Rebinding mouse actions would let you either change it from shift or remove it entirely

[jcollie]

Yes, shift in the alternate screen has a special meaning to Ghostty: it disables any mouse reporting that the TUI has requested while the shift key is held down. That way you can click on links or use Ghostty's 'native' select.

[otomn]

Oh, ok. So that's what Mouse Capture modifier is mentioned in #11210 ? Which is not configurable at the moment.

[rhodes-b]

yes that is specifically requesting to allow it to be alt instead of shift
while #3848 is more general for all mouse actions

[otomn]

Hmm, but if shift is the mouse capture bypass key, then wouldn't it conflict with vim's <S-ScrollWheelDown>? That keybind works perfectly fine though.

[otomn]

I looked into the source code myself. This has nothing to do with Mouse Capture modifier.

ghostty/src/Surface.zig

Lines 3505 to 3533 in 63372f8

	if (self.io.terminal.screens.active_key == .alternate and
	self.io.terminal.flags.mouse_event == .none and
	self.io.terminal.modes.get(.mouse_alternate_scroll))
	{
	if (y.delta != 0) {
	// When we send mouse events as cursor keys we always
	// clear the selection.
	try self.setSelection(null);
	const seq = if (self.io.terminal.modes.get(.cursor_keys)) seq: {
	// cursor key: application mode
	break :seq switch (y.direction()) {
	.up_right => "\x1bOA",
	.down_left => "\x1bOB",
	};
	} else seq: {
	// cursor key: normal mode
	break :seq switch (y.direction()) {
	.up_right => "\x1b[A",
	.down_left => "\x1b[B",
	};
	};
	for (0..y.magnitude()) |_| {
	self.queueIo(.{ .write_stable = seq }, .locked);
	}
	}
	return;
	}

This code sends raw up and down key code to the terminal without encoding the modifiers at all. The modifiers are correctly set in the program at this stage, and is able to forward it to the application.

[mitchellh]

PR from @otomn here: #12273

But unclear from my side if this is intended or incidental xterm behavior, and we need a very overwhelming reason to break xterm compatbility. Key points:

• From me, our compatibility spec we've had since private alpha: fix: send modifier when scrolling in alternate window #12273 (comment)
• From @otomn, a compelling argument for breaking with xterm: fix: send modifier when scrolling in alternate window #12273 (comment)

I'm on the side of thinking this is a good idea, but want to make sure that xterm is not doing this incidentally before we break from that behavior, since for better and worse it defines how Ghostty behaves for legacy stuff like this.

[otomn]

@mitchellh From Email conversation with Thomas E. Dickey (author of xterm):

In the function you're pointing to, there's no key-events which would
provide modifiers, anyway.
(where would modifier information come from?)
...
There's a lot of ways to connect X events. The AlternateScroll function
is called from functions which normally aren't handling key events,
because they're "actions" with parameters:
...
I suppose it's possible that inspecting the event parameter and if it
happened to be a KeyPress, etc, that it might be possible to infer
modifiers. It would be a lot of work, though.
But take a look at input.c to see how involved that would be.
The modifiers don't come for free in the XEvent structure.

I think that confirms xterm's behaviour is a limitation of the program architecture and not an intentional design decision. I think Ghostty, having a better architecture that makes modifier information easily available, should break from the xterm behaviour and encode the modifier key when possible.

I can provide full email conversation if needed.