Alt+<nr> shortcuts do not work as expected
Closed this issue · 4 comments
Tested from cmd.exe, powershell and bash (cygwin and bash for git, with and without mintty.exe), on Windows 10, Windows 7 and Windows XP, with mc.exe version 4.8.28 build 227 (but I can also reproduce with older mc.exe releases) on different PCs (I wanted to be very sure that it does not depend on my environment, I used the installer available on GitHub).
Alt+1 does not open help, AFAIK it does nothing
Alt+2 opens the help pane (should be alt+1)
Alt+3 opens the user menu pane (should be alt+2)
Alt+4 opens the view pane (should be alt+3)
Alt+5 starts the edit operation (should be alt+4)
Alt+6 opens the copy operation (should be alt+5)
Alt+7 opens the renmov operation (should be alt+6)
Alt+8 opens the mkdir operation (should be alt+7)
Alt+9 opens the delete operation (should be alt+8)
Alt+0 closes mc (the only one that works correctly)
Note that using the mouse or Fn keys everything works as expected (F1 opens help menu, F2 opens user pane, ...), thus only the alt+n shortcuts are not mapped correctly.
Also note that the cygwin port, or the mc executable available in WSL and WSL2, does not have this issue.
Shall review the mapping, possible off-by-one; recent feature to the key-board handler.
win32, cygwin and wsl are very different environments/builds, and can not compared that simply.
Shall review the mapping, possible off-by-one; recent feature to the key-board handler.
Thanks.
Exactly my thoughts.
Some time ago I tried to look for myself if it was possible to change the keybindings as configuration, but without luck.
win32, cygwin and wsl are very different environments/builds, and can not compared that simply.
Of course.
I wanted to imply that it was specific of this port of mc.exe, and not something related to the environment, or the upstream implementation.
build-228: as suspected alt mapping was off-by-1; other issues shall review, inc pr
released