Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions crates/edit/src/input.rs
Original file line number Diff line number Diff line change
Expand Up @@ -569,10 +569,13 @@ impl<'input> Stream<'_, '_, 'input> {
// I know there's an InputMouseState::Release, but that's because the internals of tui.rs
// have leaked into intput.rs. input.rs indicates release by the absence of buttons being
// held, which is InputMouseState::None. This makes it more reliable in my opinion.
} else if (WHEEL..WHEEL + 4).contains(&kind) {
let delta = if (kind & 1) != 0 { 3 } else { -3 };
let idx = if (kind & 2) != 0 { 0 } else { 1 };
mouse.scroll.as_array()[idx] += delta;
} else if (WHEEL..WHEEL + 0x08).contains(&kind) {
let scroll_mult = if (btn & ALT) != 0 { 5 } else { 1 };
if (btn & 0x06) != 0 {
mouse.scroll.x += if (btn & 0x01) != 0 { 7 } else { -7 } * scroll_mult;
} else {
mouse.scroll.y += if (btn & 0x01) != 0 { 3 } else { -3 } * scroll_mult;
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This multiplication logic should go into tui.rs. Specifically, here:

next_state = self.mouse_state;

(You need to make next_scroll a mutable variable for that.)

The reason for that is that input.rs' only concern is providing platform-independent input events. When we later add a fully customizable key binding editor, your key bindings should still have almost raw access to the input events. This allows a user to e.g. change the multiplier when Shift/Alt is held during scrolling.

Right now, all of the key binding logic is hardcoded in tui.rs, so it makes sense if these two key bindings also go there.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Would it also be a good idea to move the base scroll amounts (3 lines & 7 characters) to tui.rs as well?

I think that if fast scroll multiplication should be abstracted in the TUI layer, then the base scroll amounts should probably also be abstracted in the TUI layer.

mouse.state = InputMouseState::Scroll;
} else if (kind & !MOTION) < 3 {
match kind & 3 {
Expand Down