page_up and page_down only respond to their default key (pgup / pgdown)

[jto6]

Describe the bug

page_up and page_down only respond to their default key (pgup / pgdown). Any additional/alternate key listed for these two actions in hotkeys.toml is silently ignored — the keypress reaches superfile (confirmed via a separate working binding on the same key), but the page-up/page-down action never fires.

All other actions I tested correctly honor a second key in their array (e.g. copy_path = ['alt+w', 'Y'] — both keys work). page_up/page_down appear to be the only actions where this breaks.

To Reproduce

Starting from the default hotkeys.toml (where paste_items = ['ctrl+v', 'ctrl+w', ''] already claims ctrl+v):

1. Remove ctrl+v from paste_items, so it no longer competes for that key:

   paste_items = ['ctrl+w', '']

2. Add ctrl+v and alt+v as secondary keys for paging:

   page_up   = ['pgup', 'alt+v']
   page_down = ['pgdown', 'ctrl+v']

3. Restart superfile.
4. Navigate into a directory with enough files that the list overflows the visible panel (so paging has somewhere to go).
5. Press alt+v — nothing happens. Press pgup — works as expected.
6. Press ctrl+v — nothing happens. Press pgdown — works as expected.

To rule out the key itself being unsupported/intercepted by the terminal, I also tried a key already confirmed to work elsewhere in the same config:

copy_path = ['Y', '']           # alt+w temporarily removed from here...
page_up   = ['pgup', 'alt+w']   # ...and reassigned here instead, for testing

(alt+w had separately been confirmed to reach superfile fine when bound to copy_path — pressing it copied the file path to the clipboard as expected, with no terminal interception.)

With copy_path's alt+w binding removed first (so the two actions wouldn't both try to claim the same key at once), pressing alt+w while it was assigned to page_up did nothing. This shows the keystroke itself is not the problem — it's proven to reach superfile via copy_path — and the issue is specific to how page_up/page_down handle their hotkey array. They appear to only ever check the literal default key in the array (index 0: pgup/pgdown), ignoring any additional key (index 1+), regardless of what that key is.

Expected behavior

page_up and page_down should fire on any key listed in their hotkey array, the same way every other action does (e.g. copy_path, list_up, list_down).

Environment

• superfile version: superfile version v1.6.0
• OS: Ubuntu 24.04
• Terminal emulator: Ghostty
• Installed via: bash -c "$(curl -sLo- https://superfile.dev/install.sh)"

Additional context

• ctrl+v is a commonly terminal-intercepted combo in many terminal emulators in general (superfile's own tutorial notes this for paste_items on PowerShell specifically). To control for that possibility, I also tested with alt+v, and then with the already-proven-working alt+w (see repro steps above). The result was the same in all three cases — only the original default key (pgdown/pgup) fired. This indicates the bug is not about a specific key being swallowed by the terminal, but about page_up/page_down not consulting any key beyond index 0 of their hotkey array.
• This may be related to page_up/page_down having special-cased dispatch logic separate from the general hotkey-matching path used by other actions (possibly related to the panel-context handling discussed in Page Up/Down is not context-aware #966, where page up/down don't respect the currently focused panel either — that issue and this one may share a root cause in how paging hotkeys are wired up).
• Relevant snippet from my hotkeys.toml while testing (note paste_items had to be edited first to free up ctrl+v):

  paste_items = ['ctrl+w', '']        # ctrl+v removed so page_down could use it
  page_down   = ['pgdown', 'ctrl+v']
  page_up     = ['pgup', 'alt+v']

[github-actions]

👋 Hi there, and welcome to superfile!

Thanks for opening your first issue. We really appreciate your interest and involvement.

A maintainer might ask you for more details or clarification to better understand the issue.
That’s totally normal and helps us solve the problem more effectively.

If you plan to submit a PR, make sure to check our Contribution Guide