You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plain PageUp/PageDown scroll the focused pane's scrollback by a full page, and copy mode offers line-precise movement, but there is no way to scroll the scrollback line-by-line without entering copy mode.
Coming from terminal multiplexer setups where e.g. shift+PageUp/PageDown scroll by a single line, this is a habit that's hard to replace — entering copy mode just to nudge the view a couple of lines feels heavyweight.
Proposal
Would you consider either of these?
Optional [keys] actions like scroll_line_up / scroll_line_down (unset by default), or
Treating shift+PageUp/PageDown as 1-line scroll in the existing page-key interception.
Currently modified page keys are intentionally forwarded to the pane app (src/app/input/terminal.rs, "Modified page keys are pane shortcuts"), so an opt-in binding would not break existing behavior.
Environment
herdr 0.7.3 (stable), Linux (WSL2) and macOS
(Originally filed as #1283; moved here per the issue policy.)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Problem
Plain PageUp/PageDown scroll the focused pane's scrollback by a full page, and copy mode offers line-precise movement, but there is no way to scroll the scrollback line-by-line without entering copy mode.
Coming from terminal multiplexer setups where e.g. shift+PageUp/PageDown scroll by a single line, this is a habit that's hard to replace — entering copy mode just to nudge the view a couple of lines feels heavyweight.
Proposal
Would you consider either of these?
[keys]actions likescroll_line_up/scroll_line_down(unset by default), orCurrently modified page keys are intentionally forwarded to the pane app (
src/app/input/terminal.rs, "Modified page keys are pane shortcuts"), so an opt-in binding would not break existing behavior.Environment
herdr 0.7.3 (stable), Linux (WSL2) and macOS
(Originally filed as #1283; moved here per the issue policy.)
All reactions