far2l
far2l copied to clipboard
[macOS] Both Ctrl keys are interpreted as `RCtrl`, making the `LCtrl` bindings impossible to use
Update: As explained below, https://github.com/elfmz/far2l/issues/2761#issuecomment-2928007674, in the wxWidgets UI, Ctrl is mapped to RCtrl and Cmd is mapped to LCtrl. Mac keyboards do not have a right Ctrl key. Unfortunately, this mapping does not seem to be documented except in the source code, nor does it exist when using the Kitty keyboard protocol UI.
I'm using far2l 2.6.3-beta installed from nixpkgs in the fully-graphical mode on ARM Mac OS. Update: I also tried far2l 2.6.5-beta from Homebrew, it behaves the same.
I'd like to be able to change the display mode of the left/right panel with a binding. Unfortunately, the bindings for this (LCtrl+1, LCtrl+2, ...) do not work.
(I'm also not sure whether the commands for the right pane are meant to use RCtrl or LCtrl. They are labeled with LCtrl for me, which might be intended or a bug)
I tried to record a macro, and I can assign Ctrl-1 and similar keybindings to a macro. However, it seems that whichever Ctrl key I use, it's recognized as RCtrl.
I'd be interested in either a fix (I'd love it if these commands could be rebound) or a workaround. E.g., I thought of maybe recording a macro and then trying to edit it so that it does LCtrl+1, but I don't know if that's practical.
Thanks for making far2l! It's a wonderful tool to explore and modify archives on MacOS. Also, it evokes lots of pleasant nostalgia; I learned it around the turn of the century, don't use Windows anymore, haven't used it for more than a decade, but the keybindings still feel natural and familiar once I ran it again. I could never get used to Midnight Commander.
You may add macros manually to ~/.config/far2l/settings/key_macros.ini
[KeyMacros/Shell/RCtrl0]
Sequence=Ctrl0
[KeyMacros/Shell/RCtrl1]
Sequence=Ctrl1
# etc.
Save the file and restart far2l.
Note: that way you won't be able to use folder shortcurs RCtrl0 ... RCtrl9.
Thanks! This seems to have worked. Here's what I ended up with:
[KeyMacros/Shell/RCtrl1]
DisableOutput=0x1
Sequence=Ctrl1
[KeyMacros/Shell/RCtrl2]
DisableOutput=0x1
Sequence=Ctrl2
[KeyMacros/Shell/RCtrl3]
DisableOutput=0x1
Sequence=Ctrl3
[KeyMacros/Shell/RCtrl4]
DisableOutput=0x1
Sequence=Ctrl4
[KeyMacros/Shell/RCtrl5]
DisableOutput=0x1
Sequence=Ctrl5
[KeyMacros/Shell/RCtrl6]
DisableOutput=0x1
Sequence=Ctrl6
[KeyMacros/Shell/RCtrl7]
DisableOutput=0x1
Sequence=Ctrl7
[KeyMacros/Shell/RCtrl8]
DisableOutput=0x1
Sequence=Ctrl8
[KeyMacros/Shell/RCtrl9]
DisableOutput=0x1
Sequence=Ctrl9
[KeyMacros/Shell/RCtrl0]
DisableOutput=0x1
Sequence=Ctrl0
Of course, if FAR properly distinguished between RCtrl and LCtrl, that'd be even better.
I think this bug is specific to the wxWidgets backend, which I think I'm using (according to the result of running about:far inside FAR). The Kitty terminal backend (running far2l -m --tty inside Kitty or Ghostty terminals) distinguishes between LCtrl and RCtrl just fine.
Unfortunately (and unsurprisingly) this breaks when running far2l --tty inside tmux, which doesn't speak Kitty's fancy keyboard protocol. But, perhaps, I could run something like kitty far2l --tty instead of using the graphical mode of far2l. The kitty protocol might also have some disadvantages compared to the graphical mode, though, I'm unsure.
I could run something like
kitty far2l --tty
iTerm2 also supports kitty's kb protocol (older versions use it's own, fortunately far2l suports it also) and also supports OSC 52 for clipboard just like kitty
@ilyagr seems that under Mac the "left control" is represented by the command key, see this comment, and the "right control" functionality is given to the usual control key which is the only one on the magic keyboard on its left side :)
So try with ⌘+1,2,3 without macros
Indeed, that works, thank you very much! Now I know.
I hadn't noticed that there is no RCtrl on my Mac because 1) I'm mostly using an external Windows keyboard and 2) I needed LCtrl for what I wanted to do.
So, under Kitty there's no way to do RCtrl without an external keyboard. As you said, under wxWidgets there's the crazy undocumented (but useful) mapping that Cmd/Super means LCtrl, while the only Ctrl key on a Mac keyboard (which is on the left) means RCtrl, and either Ctrl key on an external keyboard means RCtrl.
I an not sure how to improve the situation, but at least there's an issue about it now. The best way IMO would be to change all the labels in the menus to the correct key, but I'm not sure that would be practical.
Perhaps there could be a "key remapping" settings UI, where you could toggle the association of what key maps to LCtrl and what key maps to RCtrl.
As an aside, I think if I was doing this from scratch, my first instinct would be to map the (only) Ctrl key to LCtrl and to map the right Cmd key to RCtrl. Or, for a more Mac-like approach, Ctrl+LOption could map to RCtrl. But in any case, the real problem here is the lack of discoverability and the inconsistency.
Another thing that would be useful is a command like fish_key_reader from the fish shell. Say, if I could run far:keydebug, and it would open a window that shows which keys it sees me pressing. Currently, the best way I found for that is to use macro recording by pressing Ctrl-Shift-. twice, but that's not convenient.
Thanks! Following your inputs some info on Mac keyboard specifics is being added to the F1 Help, section "FAR2L features - Getting Started" in the PR #2760 with the hope that it will help newcomers with these Ctrl quircks. As for the current implementation, it appears to originate at the wxWidgets framework level leaving little room for decision within the app code.
Keyboard events debug logging already exists, you can enable it and see keypresses.
macOS keyboard features are now briefly described in help in section "FAR2L features - Getting Started". @ilyagr and @exkrexpexfex please give feedback if it need any corrections.
Nice! It looks pretty good, and should be helpful, thank you!
This is minor, but the first list item has an "и" instead of an "and".
I've also never heard of a "Grey" key. I guess it means "AltGr" (which I have seen on some keyboards, maybe European ones? Is not present on the external US-Windows keyboard I'm currently using).
Thank @ilyagr . Help corrected.
This is minor, but in the first entry, it should now be "maps" (singular) instead of "map". Perhaps,
The
Optionkey maps toAlt
would be even better.
@ilyagr thank you for spelling. Now all corrections in master. If all is ok, please close this issue.
I'll just close it now. I'm not sure I'll try it out until it gets released to nixpkgs, hopefully I'll test it out then.