Fig defeats fish shell's Ctrl+F shortcut

[jab]

Description:

Please include a detailed description of the issue (and an image or screen recording, if applicable)

One of the most useful and frequently used keyboard shortcuts offered by all shells out-of-the-box is Ctrl+F, which is mapped to "move cursor right". In fish shell, this keyboard shortcut combines beautifully with fish's built-in auto-completion support to enable the user to easily accept fish's currently suggested auto-completion.[1]

However, after upgrading to the latest version of Fig, Fig has now taken over Ctrl+F in fish shell, so users can no longer use it to move the cursor right or accept fish's current auto-completion. Instead, Ctrl+F now trigger's Fig's "Create new Workflow..." UI. Here's a screenshot where you can see I had typed "./u", then fish suggested an auto-completion ("./upgrade-dev-dependencies.sh"), then I tried hitting Ctrl+F to accept that completion, but rather than working as expected, Fig instead took over my shell with its "Create new Workflow" UI (but somewhat confusingly, still left fish's suggested auto-completion visible):

I searched in Fig settings for any sign of a Ctrl+F keybinding I could hopefully disable, but couldn't find it there.

Could you please fix this in the next version of Fig? And in the meantime, is there any workaround to get Ctrl+F working in fish again with the current version of Fig? This bug is killing my productivity so much I might have to uninstall Fig until this is fixed, but I'm hoping it won't come to that.

Thanks for the great work on Fig!

[1] You can also use right arrow, but Ctrl+F is preferable for touch typists because there's no need to take hands away from the home row, especially when the Control key is in a convenient place, e.g. when Capslock is mapped to Control.

Details:

macOS	Fig	Shell
10.15.7	Version 1.0.58 (B472)	/usr/local/bin/fish

fig diagnostic

Version 1.0.58 (B472) [U.S.] 
UserShell: /usr/local/bin/fish
Bundle path: /Applications/Fig.app
Autocomplete: true
Settings.json: true
CLI installed: true
CLI tool path: /Users/jab/.fig/bin/fig
Accessibility: true
SSH Integration: false
Tmux Integration: false
iTerm Integration: true [Authenticated]
Hyper Integration: false
VSCode Integration: true
Docker Integration: false
Symlinked dotfiles: false
Only insert on tab: false
UNIX Socket Exists: true
Installation Script: true
PseudoTerminal Path: /Users/jab/.local/google-cloud-sdk/bin:/Users/jab/.local/bin:/Users/jab/.fig/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
SecureKeyboardInput: false
SecureKeyboardProcess: 
Current active process: fish (72629) - /dev/ttys003
Current terminal session: w0t0p0:C6E49E3E-371D-4A47-B621-24E9FCAA47CC
Current working directory: /Users/jab/src/bidict
Current window identifier: 154878/% (com.googlecode.iterm2)

[clo4]

Closing as duplicate of #1605 -- you can run set -Ux FIG_WORKFLOWS_KEYBIND to disable this behavior in fish 🙂

[jab]

Awesome, thanks! And sorry I missed the existing issue.

Given other users are hitting this too, Fig should consider additional changes:

1. set a different default shortcut for FIG_WORKFLOWS_KEYBIND (one that does not conflict with a popular shell shortcut) to avoid requiring users to change Fig’s shortcut
2. make it easier for users who need to change this shortcut to figure out how (both I as well as users in #1605 looked in Settings but couldn’t find this there)

Reopen this issue for the followup work?

[clo4]

Both of these suggestions are already being implemented! We're... definitely aware of the problems binding to ^f caused, now 😬

[jab]

Good to know, thanks!