Issue with remapped keys on MacOS

[sinelaw]

From https://news.ycombinator.com/item?id=46138380

I'm on MacOS and I have remapped the fn and command keys so it can be more like Windows (I can't undo 20+ years of muscle memory, and also I just don't wanna)

Anyway, Fresh seems to ignore the remapping - it's back to the command key for copy/paste and the command palette.

[sinelaw]

Need someone who owns an actual Mac to try this and explain if there's a workaround / instructions

[ronyhe]

I'm having similar issues. I don't think I have a remapping on my mac. However, cmd and ctrl seem to have been replaced somehow. For example, when prompted to open the command palette with cmd+p, it doesn't work. But ctrl+p actually launches the palette.

Moreover, I'm having issues with terminals intercepting the keyboard shortcuts. This is true for Warp, iterm2 and even the built-in mac terminal.

I'd like to help here because I like the project, but I'm not sure how to proceed.

[sinelaw]

Since I don't have a Mac myself I depend on your input. If you can suggest a change that will make the shortcuts work out of the box on vanilla Mac, that would be awesome

[JCKodel]

Since I don't have a Mac myself I depend on your input. If you can suggest a change that will make the shortcuts work out of the box on vanilla Mac, that would be awesome

Also [Home] and [End] are not working (in my keyboard settings).

Most of people who came from a Windows or Linux world into Mac usually uses Karabiner Element to remap the keyboard to a decent configuration (Ctrl+C to copy, etc.).

I don't know if I have a Karabiner Element remapping or a Terminal setting that maps [Home] and [End] to actually go to the beginning/end of the line, as that keys are meant to. (Mac don't use those keys, such as home, end, pg dw, etc.)

Doing that in Fresh, [Home] selects all text and [End] opens the Explorer (which is marked as ⌘E, but I think, in MacOS terminal, ˆE is [End] and Fresh doesn't seem to recognize ⌘ (it treats as Ctrl)). Just to be sure: ⌘ is the [Windows] button in any PC keyboard.

What you could do to make this work flawlesly:

Implement a Key Binding editor just like VSCode.

For example, I want to change what ^C does. Fresh then allows me to pick the "Copy" command and then listen to a keystroke. That keystroke (as it recognized) is then set to the "Copy" command. I say "as it recognized" because, for MacOS, my ^C is ⌘C (Karabiner does the remapping). So it must be set using a real keyboard listener, so the actual codes that the OS sees when you press ^C is used by Fresh). Even if you don't use Karabiner, you can set certain keys in MacOS terminal.

Example:

I guess this is where it maps Home to ˆA (\001) and End to ˆE (\005). I cannot change that because this is the only way that bash/zsh/etc. recognizes home and end. If I unset this so Fresh works, then the terminal doesn't work anymore (i.e.: I lose the ability to home/end my command line).

If that configuration is saved in a JSON, people could create and share their vim bindings, nano bindings, Windows bindings, etc. and, as a bonus, this kind of issue (I would not even call it a bug), could be easily fixed.

[dwt]

I have a Mac and might be of assistance, I think that most keyboard shortcuts involving alt/option do not work by default in terminals on Mac. The problem here is that option is used by the operating system to write all sorts of symbols on international keyboard layouts.

Some examples: @€[]{}~ are all symbols that have to be typed using the alt key on a german keyboard (but there are many more, like œ≤¥≈ç√∫~µ√∫~µ∞…å‚∂ƒ©ªº∆@œæ«∑€®†Ω¨⁄øπ•± - most of which are rarely used. But that means that if the terminal application wants to listen to alt/option keyboard shortcuts, you can either

• listen to these locale dependent characters to provide a consistent feeling shortcut.
• get all users to remap the option key in their terminal - at the cost of not being able to type characters like @€[]{}~ which are often very crucial to programming. One workaround is often to switch to an english keyboard layout, but that can be very painful
• Be very careful which keybindings are used with alt/option to avoid problems with these composable characters.

Some more observations about key bindings:

• alt-$number these produce these symbols on Mac: ¡“¶¢[]|{{}≠¿` (1-0) so are ill suited for shortcuts
• F$X keybindings are often relatively hard to access on Macs, as they require pressing the FN key and adding a number key. This key by default also shows the smiley overlay, so these keyboard shortcuts can be hard to use. Also: At least the standard Terminal as well as Ghostty do not seem to forward function keys to the TUI app (at least shift-fn1 does not seem to work for me)
• Mac has various standard shortcuts which are not currently used / approximated. For example
  • cmd-e copy selection into the find pasteboard (shared system wide)
  • cmd-f open search interface (all changes here are automatically placed on the search pasteboard)
  • cmd-g search next occurrence of current content of search pasteboard
• ctrl-y is very untypical for redo on mac, it is usually cmd-shift-z which would translate to ctrl-shift-z in a TUI app (as of course cmd is intercepted by the terminal / the GUI as far as I know.
• alt-leftarrow moves a word to the left, but alt-rightarrow switches to the menu - very surprising for a Mac user

There is more for sure, but maybe that's a start? I would love to answer specific questions or provide results of experiments, as I really like the idea behind this editor.

Oh: and thanks for all the hard work that went into this!